Beiträge von ahe

Eine weitere umfangreiche Quelle für Schalter und Tipps ist hier: Appdeploy Package Knowledge Base

mfg
Axel

So wie es aussieht habe ich ein Tool gefunden, es ist ein BartPE Plug-In

"keyboard.exe"

Einzige Voraussetzung ist, dass die entsprechenden Keyboard-DLL's im System32-Verzeichnis vorhanden sind (mit den kopierten DLL's von XP hat es auch unter PE geklappt).

Allerdings muss ich nach der Sprachumstellung meine Anwendung erneut starten.
D. h. ich muss wohl ein Startfenster machen, in dem die Sprache ausgewählt wird und anschließend erst meine Anwendung von dort automatisch starten (was hoffentlich kein Problem darstellen sollte...).

mfg
Axel

Sorry, dass ich mich so spät zurückmelde und danke für Eure Hilfe.

Ich hatte wohl die Mailbenachrichtigung abgeschaltet ...

@Valvepro: Nun die Einträge habe ich in die Registry eingetragen, allerdings gab es keine Änderung... (bei meiner MUI XP Installation ist das ohnehin der Fall )

franzp: Funktioniert das auch unter PE? Werd' ich 'mal testen... Schöner wäre, wenn man ein Auswahlmenü dafür basteln könnte...

mfg
Axel

Danke für die schnelle Antwort,

aber leider hilft dies nicht, das Layout ist immer noch EN-US ...

mfg
Axel

Hallo,

gibt es eine Möglichkeit das Tastaturläyout per Knopfdruck auf ein Anderes zu stellen und dieses im Anschluss dann auch ohne Reboot zu verwenden?

Ich habe eine GUI erstellt, über die eine Anmeldung duchgeführt wird. Die GUI soll nicht nur in DE verwendet werden, sondern auch in anderen Ländern.
Jetzt gibt es aber nicht nur ein Tastaturlayout, sondern "n".
Wenn jetzt der Anwender die Anwendung startet, soll er als erstes sein Tastaturlayout angeben (default ist EN-US), damit es bei der Eingabe dann nicht zu Suchaktionen kommt...

Um das Ganze noch zu erschweren, läuft die Anwendung unter Windows PE... (vermutlich muss ich dort auch noch ein paar layouts einfügen...)

Vielleicht habt Ihr ja noch eine Idee...

mfg
Axel

Danke Xeno,

probier' ich morgen direkt 'mal aus...

mfg
Axel

Hallo,

ich muss an eine EXE Parameter übergeben, dass funktioniert eigentlich auch, aber in diesem Fall braucht der Parameter selbst ebenfalls Anführungsstriche.

Im Hauptprogramm rufe ich eine Funktion auf mit dem Parameter $msg, der irgendeine Nachricht (Fehlermeldung, Fortschritt, etc) enthält.
Leider wird der Text immer nur bis zum ersten Leerzeichen übertragen. In meiner Funktion habe ich jetzt vier (4!) Anführungszeichen vor und nach dem $msg Parameter gemacht und diesen dem Parameter $ldmsg zugewiesen.

func LDEcho ($msg)
$ldmsg="""" & $msg & """"
RunWait (@ProgramFilesDir&"\diedeldum\diedeldum.exe /msg="& $ldmsg,"")
endfunc

Der Workaround scheint zu funktionieren (zumindest in den ersten einfachen Tests, allerdings frage ich mich, ob es nicht eine andere, sichere, bessere, schönere Möglichkeit gibt...

mfg
Axel

Hallo Ben,

der Schlüssel muss angelegt werden, dann wirkt er. Du kannst das auch für einzelne Benutzer im HKCU Zweig machen, wenn Du dass nicht für alle Benutzer haben möchtest (s. Links zuvor...).

Hier ist übrigens eine Umsetzung dazu, allerdings auch dort mit direktem Registrypatch, ohne den "Umweg" über das Menü...
http://www.autoitscript.com/forum/index.php?showtopic=57074

Hast Du eigentlich schon einmal den ScriptWriter 3.1 ausprobiert ("C:\Program Files\AutoIt3\SciTE\ScriptWriter\AU3Record.exe")?
(ok, ok, ist unsportlich... )

mfg
Axel

Hallo,

ich möchte ja Deinem Ehrgeiz nicht bremsen, aber es geht auch einfacher per Reg-Patch:

Windows Registry Editor Version 5.00


[HKEY_LOCAL_MACHINE\SOFTWARE\Adobe\Acrobat Reader\7.0\FeatureLockdown]
"bUpdater"=dword:00000000

Auf der folgenden Seite findest Du noch einige andere möglichen Einstellungen, um z. B. das dusseligen Yahoo wegzubekommen, Internet PrintMe, etc., vieles auch als ADM-Template:
http://www.appdeploy.com/packages/detail.asp?id=404
Hier gibt es auch noch ein ADM-Template für Acrobat Reader 5, 6, 7, 8:
http://www.gruppenrichtlinien.de/adm/Adobe.txt

mfg
Axel

Du könntest auf den (Default) bzw. (Standard) Eintrag checken..

> To access the (Default) value use "" (a blank string) for the valuename.

Andererseits bringt dir die Zeile
$key2 = RegRead("HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\8A0F842331866D117AB7000B0D610007\InstallProperties", "DisplayVersion")
doch einen Wert für die "DisplayVersion" zurück, z. B. 1.4.3.5

mit der folgenden if-Abfrage kannst Du dann weiter arbeiten... (mit case sollte es natürlich auch gehen...)
if $key2 = "1.4.3.5" Then
installiere oder tue was dir gefällt
else
dann halt nicht
endif

Ich habe gerade hier im Forum noch etwas gefunden:
[ offen ] RegRead und Platzhalter (Sternchen)

mfg
Axel

Du könntest die @error Variable abfragen. Inder Online Hilfe fand ich dies:

...

Return Value
Success: The PID of the process that was launched.
Failure: Depends on RunErrorsFatal; see Remarks.

Remarks
To run DOS (console) commands, try Run(@ComSpec & " /c " & 'commandName', "", @SW_HIDE)
After running the requested program the script continues. To pause execution of the script until the spawned program has finished use the RunWait function instead.
By default the script will terminate with a fatal error if the Run function fails. To set @error 1, @extended to GetLastError() Windows API and return 0 as an indication of failure
...

mfg
Axel

Hallo Doc,

das fluchen habe ich schon besorgt , hat mich ein paar Stunden Fehlersuche gekostet, da ich unsere McAfee EPO Konfiguratoren im Verdacht hatte Einstellengen verändert zu haben, und Script mehrfach umgebaut hatte.
Es viel mir erst auf, als ich in der Run Funktion nicht @SW_HIDE, sondern @SW_MAXIMIZE eingetragen hatte und den Pakettest auf einem neu installierten frischen Rechner startete...

So wie es aussieht betrifft es alle Tools aus der aktuellen Sysinternals Suite bzw. die Tools die man aktuell auch einzeln herunterladen kann. (ich habe diverse gestartet und jedes Mal die Meldung bekommen...)

Wieder ein Grund mehr, das Prozess killen nur mit AutoIt-Funktionen durchzuführen...

mfg
Axel

Kleiner Hinweis zu pskill.

Seit der letzten PsKill Version (v1.12) unter der Regie von MS erscheint beim erstmaligen Start eine Lizenz Meldung, da man diese aber normalerweise in einem silent Skript nicht sieht, funktioniert das Beenden nicht.
Beim erstmaligen Start der sysinternals Tools wird beim Anwender ein Registry-Key erzeugt. Wird die Lizenzmeldung bestätigt, wird ein entsprechender Wert für "EulaAccepted" eingetragen, ansonsten erscheint die Meldung immer wieder.

Wenn jetzt pskill als Local System (oder anderer User) ausgeführt werden soll, muss zuvor der folgende Registryeintrag gesetzt werden:

Windows Registry Editor Version 5.00


[HKEY_USERS\S-1-5-18\Software\Sysinternals\PsKill]
"EulaAccepted"=dword:00000001

Bei der alten Version von PsKill (v1.11) war dies noch nicht nötig!

mfg
Axel

Tja, wenn du auch immer die gleiche Diskette im Laufwerk hast, dann brauchst du den Laufwerkscheck natürlich nicht (es sei denn die Diskette funktioniert nicht mehr richtig oder ist zufällig nicht im Laufwerk... )

Erst Datei öffnen, dann kann man mit FileRead lesen (s. a. Beispiel aus der Online-HIlfe):

$file = FileOpen("test.txt", 0)

; Check if file opened for reading OK
If $file = -1 Then
MsgBox(0, "Error", "Unable to open file.")
Exit
EndIf

; Read in 1 character at a time until the EOF is reached
While 1
$chars = FileRead($file, 1)
If @error = -1 Then ExitLoop
MsgBox(0, "Char read:", $chars)
Wend

FileClose($file)

mfg
Axel

Hallo Doc,

ja, dort habe ich auch schon etwas gestöbert, allerdings bislang nur die "ProcessClose" Lösung gefunden... (die Übersicht ist in diesem Forum aber etwas gewöhnungsbedürftig...)

mfg
Axel

Hallo Doc,

ich arbeite auch sehr gerne mit den PS-Tools, allerdings sind wir nicht die Einzigen und daher verhindern manche Virenchecker (bzw. Scanengines) die Nutzung. (z. B. McAfee, AVG,...) Einzige Möglichkeit ist, die entsprechenden EXE Dateien vom Scan auszuschließen, das wird aber von einigen Sicherheitsbeauftragten nicht so gerne gesehen ... Manchmal ändert sich das auch von Update zu Update und das wäre nicht so geschickt, wenn die Installation mal funktioniert und mal nicht. Das erleichtert nicht gerade die Fehlersuche...

Daher wäre mir eine reine AutoIt Lösung immer noch lieber

mfg
Axel

Hier noch ein kleiner Hinweis, wie es zur 132 kommt:

InstallHinfSection Function

und hier, wie es auch unter Vista per Batch klappt...

inf-Datei automatisch installieren

mfg
Axel

Meine bisherigen "Lösungen" mit "Dritt"-Tools:

Lösung mit taskkill: (läuft nur unter XP und Windows 2003)

Run(@ComSpec & " /c taskkill.exe /t /im pjreader.exe", "", @SW_HIDE)

Lösung mit pskill: (läuft auch unter Windows 2000)

$WorkDir = @TempDir & "\test\gnuffz\"
$pspath = $WorkDir & "pskill.exe -t " ; Befehlszeile
DirCreate ($WorkDir) ; Temp Verz. fÜr die installation erstellen
FileInstall ("D:\testscripte\gnuffz\pskill.exe", $WorkDir,1 ) ; Sourcedatei einfügen
$PID = ProcessExists("gnuffz.exe") ; Liefert die PID oder 0 wenn der Process nicht gefunden wurde
If $PID Then Run($pspath & $PID, "", @SW_HIDE)
. . .
DirRemove ($WorkDir,1) ; Löschen des Installationsverzeichnisses

Vielleicht hat ja jemand noch eine Idee, wie ich ohne die Tools auskomme...

mfg
Axel

Sorry für die späte Rückmeldung, war etwas un-fit...

installieren kann man auch per "runas" oder aber per laufenden Systemprozess eines Softwareverteilungstools. D. h. während der Anwender angemeldet ist wird per Dienst oder Runas-Kommando Software im Hintergrund installiert.

Das funktioniert eigentlich recht gut, auch das Beenden von laufenden Tasks mit Hilfe von Taskkill oder PSKill, allerdings nicht mit AutoIt...

Da ich einige ältere Batches ablösen möchte und die Abfragerei leid bin, ob ein Tool nun bei diesem OS vorhanden ist oder nicht, dachte ich stelle mein Skript komplett auf AutoIt um...

mfg
Axel

Hallo,

ich habe da ein Problem bei einer Installation. Vor der Installation (Update) sollte ein laufenden Programm beendet werden, damit die Installation durchläuft.
Das funktioniert auch ganz schön, wenn ich mit Hilfe von ProcessClose den Prozess im Userkontext beenden, d. h. es funktioniert, wenn ich es mit dem gleichen Account beende mit dem ich zuvor die Anwendung gestartet habe.

$PID = ProcessExists("notepad.exe") 
If $PID Then ProcessClose($PID)

Allerdings installiert ein Anwender normalerweise nix, sondern dass macht ein administrativer Account. Dieser hat jedoch anscheinend keine Rechte dies mit der Funktion ProcessClose zu machen. Mit Hilfe des Konsolenkommandos "taskkill /PID #" (unter XP z. B.) funktioniert es dagegen.

Jetzt könnte ich natürlich mit den Shell-Kommandos herummachen, aber wozu habe ich AutoIt, außerdem sollte das Ganze natürlich auch unter W2003, W2K und WXP laufen...

Hat jemand eine Idee?

mfg
Axel