Beiträge von Velted

  • HP Bioseinstellung mit WMI ändern

    Moombas


    Ok, dann ergibt sich für mich daraus:

    AutoIt
    If IsObj($colItems) Then
    For $objItem In $colItems
        $strReturn = $objItem.SetBiosSetting("TPM Activation Policy", "No prompts", "<utf-16/>" & sPwd2) ; drei Parameter
    Next
EndIf

    Edit: Überzähliges ' entfernt!

  • HP Bioseinstellung mit WMI ändern

    Moin!


    Code
    objItem.SetBiosSetting oReturn, _
                       "TPM Activation Policy", _
                       "No prompts", _
                       "<utf-16/>itrepair"

    Wenn mich meine VBS-Erinnerungen nicht täuschen, sehe ich da oben 4 Parameter:

    1. eine nicht im eingestellten Scriptcode definierte Variable oReturn
    2. den String "TPM Activation Policy"
    3. den String "No prompts"
    4. und den String "<utf-16/>itrepair"

  • Editfeld updaten

    Zitat von BugFix

    Steht doch eindeutig drin:

    Na ja:

    Zitat von AutoIt Hilfe

    Function FileWrite

    Write text/data to the end of a previously opened file.

    Ok, das trifft für mich erst einmal nicht zu, weil ich die Datei nicht vorher geöffnet habe. Wenn man aber das noch berücksichtigt

    Zitat

    Function FileWrite

    If a filename is given rather than a file handle, the file will be opened and closed during the function call.

    und beide Aussagen zusammenführt, ergibt sich eine klare und eindeutige Aussage. Es scheint kaum möglich, das eindeutiger zu formulieren. ;)

  • Editfeld updaten

    Zitat von Moombas

    2. Wird nur Filewrite genutzt, wird an das Ende der Datei der Text angehängt anstatt ihn mit dem neuen Inhalt zu ersetzen.

    Das hatte ich nicht mehr im Hinterkopf. FileWrite() ersetzt also das gute alte FileAppend (wie es in AutoHotkey noch immer existiert). ;)


    Es wäre nicht falsch, wenn die Hilfe-Datei darauf hinweisen würde. :rtfm:

  • Editfeld updaten

    Moombas


    Ich habe nicht gesagt, FileOpen() würde dann nichts finden. Ich habe gesagt FileRead().


    Und noch was:

    AutoIt
    Func _Form3()
    local Const $Filename = @ScriptDir & "\test.txt"
    local $file = FileOpen($Filename)
    ...
    global $iEdit = GUICtrlCreateEdit(FileRead($file), 0, 0, 500, 400, $ES_WANTRETURN + $WS_VSCROLL + $ES_AUTOVSCROLL + $ES_MULTILINE + $WS_TABSTOP)
    ...
    FileClose($file)

    ist identisch mit

    AutoIt
    Func _Form3()
    local Const $Filename = @ScriptDir & "\test.txt"
    ...
    global $iEdit = GUICtrlCreateEdit(FileRead($Filename), 0, 0, 500, 400, $ES_WANTRETURN + $WS_VSCROLL + $ES_AUTOVSCROLL + $ES_MULTILINE + $WS_TABSTOP)
    ...

    FileOpen() mit Standardwerten bringt hier keinen Vorteil, erfordert aber ein FileClose().


    AutoIt
    Case $hButton
    $file = FileOpen($Filename, $FO_OVERWRITE)
    If FileWrite($Filename, GuiCtrlRead($IEdit)) Then
        ...
    Endif
FileClose($file)

    sollte in der Funktion FileWrite() $file benutzen oder (wie oben) die Funktionen FileOpen() und FileClose() weglassen.

  • Editfeld updaten

    Zitat von FileWrite() -> Remarks

    If a filename is given rather than a file handle, the file will be opened and closed during the function call.

    Zitat von FileOpen()

    $FO_OVERWRITE (2) = Write mode (erase previous contents)

    Moombas, wenn Du die Datei mit $FO_OVERWRITE öffnest, wird der anschließende Aufruf von FileRead() nicht viel finden. ;)

  • Editfeld updaten

    Moin Moombas,


    das Zitat aus Deinem lBeitrag #25 gilt meiner Meinung nach auch für FileWrite().


    FileOpen() ist für mich nur da wichtig, wo wiederholt auf Teile der Datei zugegriffen werden soll oder die Codierung vom Standard abweicht.

  • Editfeld updaten

    Moin,


    in diesem Fall wird die Datei ja immer komplett gelesen bzw. geschrieben. Es macht für mich deshalb nicht viel Sinn, per FileOpen() ein Dateihandle zu erzeugen, das dann doch gleich wieder geschlossen werden muss.


    FileRead() und FileWrite() akzeptieren auch den Dateinamen. Das scheint mir hier die bessere Option.

  • Zugriff auf COM Methode

    BugFix:

    Code
                        $tXYZ = DllStructCreate($tagXYZ)
                    $tXYZ.X = $X
                    $tXYZ.Y = $Y
                    $tXYZ.Z = $Z
                    $aXYZ[$i-1] = $tXYZ
                    Return $aXYZ


ConsoleWrite($aResult[0].X & @CRLF)

    Wo ist diese Syntax (ohne DllStructGetData()) beschrieben?

  • Outlook Mail mit eingebetteten Bildern im Body Text als versteckte Anhänge

    Moin,


    ich habe absolut keine Ahnung und habe Outlook auch noch nie benutzt. Aber ich habe ein Beispiel und einige vielleicht hilfreiche Links gefunden:

    PidTagAttachContentId

    Property Types

    OlAttachmentType Enum


    Den Tag ContentId gibt es als ANSI (0x001E) und als Unicode (0x001F) Typ. Vielleicht funktioniert Unicode besser.

  • Ip Aktualsierung funktionieert nicht

    Moin,

    wie schon gesagt, wenn keine IP-Adresse ermittelt wird, passiert meiner Meinung nach gar nichts.


    Versuch mal das:

    Wenn der Adapter beim Verbindungsverlust die letzte IP-Adresse hält, nützt das allerdings auch nicht.

  • GUI flackert

    Zitat von Oscar

    Und damit die Prozessorlast noch etwas runtergeht, ...

    Dazu ist mir nach längerem Herumprobieren wieder eingefallen, dass es auch ohne GDI-Bitmap geht, wenn man anstelle der GDIP-Bitmap eine GDI-DIBSECTION verwendet. Diese Technik habe ich aber nicht selbst erfunden:

  • Zeichensatz-Probleme beim Schreiben in MariaDB

    Für die Consolenausgabe werden die AutoIt-Strings intern nach ANSI konvertiert. Mit dem 'falschen' Format klappt das, weil sich alle Zeichen in ANSI abbilden lassen. Das 'richtige' Format enthält aber Unicode-Zeichen, für die es in ANSI keine Entsprechung gibt. Die werden bei der Konvertierung mit ? ersetzt. Und weil Deine SCIte-Konsole auf UTF8 eingestellt ist, werden anscheinend für bei UTF8 nicht zulässige ANSI-Zeichen die Hex-Werte angezeigt.