Beiträge von Velted

    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!

    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"

    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. ;)

    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:

    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.

    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. ;)

    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.

    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.

    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?

    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.

    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.

    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:

    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.