Beiträge von Bitnugger

    Woran könnte das liegen?

    Hast du das überprüft?

    Überprüfe aber auch, ob der User "Administrator" auf dem Server aktiviert ist.

    Denn wenn der User Administrator deaktiviert ist, schlägt RunAs natürlich fehl... aber das kannst du ja leicht überprüfen.

    Local $iPID = RunAs($sUserName, $sDomain, $sPassword, $RUN_LOGON_NOPROFILE, $sProgram, $sWorkingDir, @SW_SHOW)

    If Not $iPID Or @error Then MsgBox(16, "Error", "$iPID --> " & $iPID & @CRLF & "!@ " & @TAB & "#Error: " & @error & @TAB & "#Extended: " & @extended & @CRLF)


    If Not FileExist("\\" & $sDomain & $sProgram) Then Exit MsgBox(16, 'Error', 'MailStoreOutlookAddinSetup... nicht gefunden!' & @CRLF & @CRLF & "\\" & $sDomain & $sProgram)

    Hier fehlt bei FileExist noch ein s... also FileExists! Anderfalls bricht der Interpreter die Ausführung des Scripts sofort ab und SciTE präsentiert einen Fehler: error: FileExist(): undefined function.


    Evtl. aber läuft das Programm einfach nur nicht auf dem Betriebssystem des Clients.


    Wenn du auf dem Server eine Eingabeaufforderung öffnest und dort den Befehl net user administrator eingibst, kannst du sehen, ob das Benutzerkonto des Users Administrator aktiv ist und ob ein Passwort gesetzt wurde.

    Local $sAusnahmeDatei = FileOpen("ausnahmen.txt")

    Hier auch... FileOpen gibt ein (Pseudo-) Handle zurück und kein String.

    Local $hAusnahmeDatei = FileOpen("ausnahmen.txt")


    Wobei FileOpen/FileClose hier gar nicht nötig sind.

    Ich hab das jetzt grade versucht aber es passiert nichts. Die Exe für die installation wird nicht aufgrufen.

    Klar, weil du den UserName falsch angegeben hast... das Domäne\ muss da weg - die gibst du mit dem zweiten Parameter an.


    Desweiteren könnte noch der Pfad zur Exe falsch sein. Überprüfe aber auch, ob der User "Administrator" auf dem Server aktiviert ist. Wenn es dann immer noch nicht will, gib mal für WorkingDir @TempDir an.


    Local $sUserName = "Administrator", $sDomain = "Daten-01", $sPassword = "Passwort", $sWorkingDir = @TempDir, $sProgram = "\Install\MailstoreAddIn\MailStoreOutlookAddinSetup-9.1.0.10258.msi"

    If Not FileExist("\\" & $sDomain & $sProgram) Then Exit MsgBox(16, 'Error', 'MailStoreOutlookAddinSetup... nicht gefunden!' & @CRLF & @CRLF & "\\" & $sDomain & $sProgram)

    RunAs($sUserName, $sDomain, $sPassword, $RUN_LOGON_NOPROFILE, $sProgram, $sWorkingDir, @SW_SHOW)

    Um ohne Anmeldeinformationen auf den Server (\\Daten-01) zugreifen zu können, muss der Benutzername und auch das Passwort des angemeldeten Users auf dem Client identisch mit dem auf dem Server sein.


    Müssen Anmeldeinformationen angegeben werden, kannst du das nicht mit ShellExecute machen, da hier keine Möglichkeit besteht, die Anmeldeinformationen mit zu übergeben. Mit RunAs geht dies aber.


    ShellExecute("\\Daten-01\Install\MailstoreAddIn\MailStoreOutlookAddinSetup-9.1.0.10258.msi")


    #include <AutoItConstants.au3>

    Local $sUserName = "Username", $sPassword = "Password", $sWorkingDir = ""

    RunAs($sUserName, "\\Daten-01", $sPassword, $RUN_LOGON_NOPROFILE, "\Install\MailstoreAddIn\MailStoreOutlookAddinSetup-9.1.0.10258.msi", $sWorkingDir, @SW_SHOW)


    Die Berechtigungen auf das Netzlaufwerk habe ich auch schon geprüft diese stehen auf jeder.

    Mit Berechtigungen = Jeder sind übrigens nur lokale User gemeint, nicht die, die sich via Netzwerk anmelden. Du musst auch differenzieren zwischen (NTFS-) Berechtigungen und (Netzwerk-) Freigaben.

    Dateien

    • li.zip

      (1,26 kB, 4 Mal heruntergeladen, zuletzt: )

    Könntest Du bitte mal einen Blick in meinen Beitrag Sammelthread "AutoIt Interne Funktionen : Erwartetes Ergebnis -> Tatsächliches Ergebnis" werfen - falls Du es nicht bereits getan hast. Ist das einigermaßen verständlich ?

    Das ist sehr gut verständlich, nur mit "ignoriert/übergangen" bist du mindestens einen Millimeter von der Wahrheit entfernt - denn die erste Sektion wird schlicht und einfach nicht erkannt, weil der BOM mit in dieser Zeile steht und somit das erste Zeichen keine öffnende Klammer "[" ist. ;-)


    GetPrivateProfileString(A) zu erwähnen ist gut, dadurch bekommt man zumindest einen Einblick, warum es mit BOM zu Problemen kommt.



    Zitat von Musashi
     Wer dieses Verhalten der Standard IniRead* Funktionen aber nicht kennt wird sich ggf. wundern, warum Einträge nicht eingelesen werden ;).

    Nicht "Einträge", sondern nur "der erste Eintrag"...

    Auf jeden Fall extrem interessant.

    Dann findest du dieses Verhalten sicher auch interessant:


    Wird Zeit das ich in Zukunft standardmäßig irgendein _IniRead verwende

    Besser du überprüfst IniFiles einmalig beim Start deines Scripts mit einer speziellen Funktion.

    Z.B. so:

    Dateien

    • IniFile.zip

      (83,49 kB, 7 Mal heruntergeladen, zuletzt: )

    IniRead geht davon aus, dass die Datei als ANSI gespeichert wurde und kennt zudem auch keinen BOM, weshalb dieser als Inhalt der Datei mit eingelesen wird.


    Aus Sicht von IniRead steht der BOM () dann nicht in einer eigenen Zeile, da dieser ja ohne Zeilenendekennung (CRLF) vorangestellt wird.

    [Pfade]CRLF

    Dadurch kann die Sektion "[Pfade]" nicht mehr erkannt werden, weil als erstes Zeichen in der Zeile die öffnende Klammer nicht gefunden wird.


    Fügt man hinter dem BOM bzw. vor "[Pfade]" eine Zeilenendekennung ein, dann funktioniert es auch mit "UTF-8 mit BOM".

    CRLF

    [Pfade]CRLF


    FileReadLine macht hier keine Probleme, denn es erwartet kein ANSI und kann einen BOM erkennen.

    Teste dieses mal:

    Leider wird er nicht nach ganz links oben geschoben.

    Erst fängt nun bei x = 7 an.

    Run("explorer.exe /N,/E," & $sPfad_explorer_tmp, "", @SW_MAXIMIZE)

    Das Fenster wird somit maximiert angezeigt, wodurch der Rahmen nicht sichtbar ist... aber nach deinem WinMove ist es nicht mehr maximiert und auch nicht innerhalb eines Bereichs, in dem es automatisch von Windows angedockt wird, wodurch der Rahmen wieder sichtbar wird.


    Versuche es mal hiermit:

    Jetzt verstehe ich es... sehr tückisch!


    Ich denke aber, so kann man es fixen...

    Besonderheit :

    Microsoft hat es etwas schwierig gemacht, vor der Spalte 0 eine Spalte nativ einzufügen.

    "etwas schwierig" ließe sich sicher mit "etwas Aufwand" meistern... wobei ich nicht verstehe, was daran schwierig sein soll.


    "nativ einzufügen" - was soll das denn bedeuten?

    In seinem Script sehe ich nichts von nativ beim Einfügen einer Spalte... denn das macht er ja mit:

    _GUICtrlListView_InsertColumn($g_idListview, $iCol_Insert, $sHeader_TextNew, 100)


    Wenn $iCol_Insert = 0 ist, wird die neue Spalte doch vor der bereits vorhanden ersten Spalte eingefügt. Und wieso schreibt er ein paar Zeilen darüber als Kommentar: "never insert a column before 1st column !"? Warum nicht?

    Hier ein Bsp. ohne UDF...

    Autoit liefert in den meisten Fällen nur so genannte Pseudo-Handles, die eigentlich nur Open-Counts sind. Die bekommst du z. B. auch bei OpenDll. Werden mehrere Dateien/Dlls geöffnet, erhöht sich der Counter jeweils um 1.

    Ich denke mal du suchst dies hier...


    Age (Alter) muss mindestens 18 sein, Male (Geschlecht) muss 1 (Mann), 2 (Frau) oder 3 (Zwitter) sein - erst wenn beide Bedingungen erfüllt sind, kann bei ShowXXX ein y|n eingegeben werden.