Hi,
ich wollte ein uraltes Programm überarbeiten. Bei einer ListBox werde ich jedoch angemeckert, dass GUICtrlSetState und $GUI_EVENT_CLOSE nicht bekannt sind.
Kann mir bitte jemand sagen was ich importieren muss, damit Befehl und Konstante wieder funktionieren?
Hang loose, haklesoft
Wieso hast du upgedatet?
Bis dahin waren in der Zielumgebung nur Rechner bis maximal Win XP im Einsatz. Jetzt gibt es aber auch Rechner mit Win 7, Win 8 und den vergleichbaren Servervarianten. Und da hab ich mir gedacht, dass ein aktuelles AutoIt sicherlich besser an die Gegebenheiten der neuen Umgebungen angepasst ist. Nun ja; - denken heisst nicht wissen.
Hang loose, haklesoft
Danke. Jetzt weiß ich's auch. Hab die 3.2.12 lange benutzt und erst vor ein paar Wochen auf die 3.3 umgestellt.
Hang loose, haklesoft
Hi,
wie kann ich einstellen, dass eine mit AutoIT erstellte Exe auch unter Windows NT4 ausgeführt werden kann?
Hang loose, haklesoft
Dank Euch zwei.
Die deutlich schmalere WMI-Variante reicht mir.
Hang loose, haklesoft
Hi,
mit @OSVersion kann ich die Betriebssystemversion ermitteln; - allerdings nur die, die die Funktion erkennt.
Gibt es eine Möglichkleit, die Major- und Minor-Ziffer und ggf. PlatformID und Workstation-Status zu ermitteln?
Hang loose, haklesoft
Danke für Deine Unterstützung. Dürfte dann wohl eher ein lokales Problem sein. In der EXE sind einige mit FileInstall zu kopierende Dateien enthalten. Könnte das den Explorer behindern?
Hallihallo,
wenn ich AU3-Dateien in compilierte EXE's umwandle, bekomme ich die Dateieigenschaften der EXE im WinXP-Explorer nur sehr schleppend angezeigt - dauert meist sehr lange oder funktioniert gar nicht (Mauszeiger bleibt Sanduhr), so dass ich den Explorer schließen/abschießen muss. Mit anderen Dateien gibt es diese Probleme nicht.
Was muss ich bei der Compilierung einstellen, damit sich die EXE in Bezug auf die Anzeige der Dateieigenschaften "normal" verhält?
Der Region-Abschnitt meiner AU3-Dateien sieht etwa so aus:
#Region ;**** Directives created by AutoIt3Wrapper_GUI ****
#AutoIt3Wrapper_icon=C:\Volumes\Projekte\VB6\Alt_NTRechner\Projekte\SETUP1.ICO
#AutoIt3Wrapper_UseUpx=n
#AutoIt3Wrapper_Res_Comment=Anforderungen: aktuelles AS und neueste Programm-Version
#AutoIt3Wrapper_Res_Description=Patch-Datei für Ablage und Aufruf Programm-Update
#AutoIt3Wrapper_Res_Fileversion=9.2.0.2
#AutoIt3Wrapper_Res_LegalCopyright=Meine Firma, Mein Name, Ort
#AutoIt3Wrapper_Res_Language=1031
#EndRegion ;**** Directives created by AutoIt3Wrapper_GUI ****
Hang loose, haklesoft
Moin,
die _Security Befehle haben mit File Berechtigungen nichts zu tun.
Vielleicht hilft Die dieser Thread weiter
[ offen ] Ordner erstellen mit NTFS Berechtigung
;-))
Stefan
Danke. Da suche ich in AutoIt und dann tut es doch ganz profanes Dos.
Hang loose, hakelsoft
Hallo Spezis,
mit einem AutoIt-File werden auf einem Zielsystem (Vista) Verzeichnisse und Dateien im ProgramData-Pfad angelegt. Wenn das AutoIt-File "als Administrator" gerufen wird, dann hat der Admin die vollen Zugriffsrechte und ist wohl auch Besitzer. Der eigentliche User kann die vom Admin angelegten Files dann aber nicht ändern oder löschen obwohl er grundsätzlich Schreibrechte in dem Verzeichnis hat. Ich möchte mit AutoIt erreichen, dass auch der eigentliche User vollen Zugriff auf die über das Admin-Konto angelegten Dateien bekommt.
In AutoIt 3.2.12.1 existieren eine Reihe von _Security_ - Befehlen. Allerdings schweigt sich die Hilfe über die praktische Anwendung aus und es gibt auch kein einziges Beispiel. Kann mir bitte jemand erklären oder zeigen, wie ich einem User Vollzugriff auf ein Verzeichnis gebe.
Hang loose, haklesoft
1
Runwait("rundll32.exe printui.dll,PrintUIEntry /if /b " & Chr (34) & $drucker2 & Chr (34) & " \f " & Chr (34) & $drucker3 & "oemsetup.inf" & Chr (34) & " /r " & Chr (34) & "IP_" & $drucker4 & Chr (34) & " /m " & Chr (34) & $drucker2 & Chr (34) & " /Y")
Ohne Dein Problem wirklich lösen zu können sehe ich zumindest zwei Problemstellen:
" \f " - hätte da nicht " /f " stehen sollen?
$drucker3 & "oemsetup.inf" - keine Trennung dazwischen erforderlich?
Bei mir funktioniert das mit dem Chr(34) (in anderem Zusammenhang) einwandfrei.
Hang loose, haklesoft
Gestern hat Kaspersky auf einem Vistarechner dauernd die von mir erstellten Script-Exes als verseucht mit Trojan.Win32.Autoit.gs angemeckert. Auf dem Quellrechner unter WinXP hat Norton keine Feststellungen getroffen. Natürlich bin ich mir sicher, dass ich selbst keinen Trojaner eingebaut habe, aber ich kann nichts dazu sagen, ob meine in die Exe eingeflossenen AutoIt-Originale eventuell verseucht sind.
Wie kann ich feststellen, welche AutoIt-Dateien der Compiler in meine Script-Exes einfügt und ob diese Dateien unverändert sind?
Hang loose, haklesoft
PS: heute hat sich Kaspersky auf dem Vistarechner wieder beruhigt und aktzeptiert meine Files.
$ES_PASSWORD steht in der EditConstants.au3 und $BS_DEFPUSHBUTTON in der ButtonConstants.au3.
Beider werden bei mir in der GUIConstants.au3 eingebunden.Ich nutze noch die ältere Version 3.2.10.0 !
Aber ich wüsste nicht, das sich dort etwas groß geändert hat.
Nun ja. Die 3.2.12.1 hot offenbar mehr Neues zu bieten, als erwartet. Wie gesagt, auch RunAsSet() iss nich mehr.
Ich habe inzwischen festgestellt, dass Vista den vorherigen User in einem Registry-Eintrag festhält. Wenn es da einen Unterschied zum aktuellen User gibt, kann ich also entsprechend reagieren.
Hang loose, haklesoft
Jetzt kann diese Exe mittels folgendem Script gestartet werden...
[spoiler][autoit]#include <GUIConstants.au3>
GUICreate("Ausführen als...",380,150)
GUICtrlCreateLabel("Admin-Kennwort:",45,43)
$Kennwort=GUICtrlCreateInput('',130,40,150,22, $ES_PASSWORD)
$Login=GUICtrlCreateButton("Start",160,100,60,22,$BS_DEFPUSHBUTTON)
...
Hallo Micha_he,
meine GUIConstants.au3 verweisen auf die GUIConstantsEx.au3 und in der finde ich die Definitionen für $ES_PASSWORD und $BS_DEFPUSHBUTTON nicht. Wie sind die definiert?
Hang loose, haklesoft
Ganz abgesehen davon, dass RunAsSet() in meiner AutoIt-Version nicht enthalten ist.
#RequireAdmin hilft dir evtl, bzw. Prüfungen mit IsAdmin, oder auch RunAs...
Hallo peethebee,
#RequireAdmin hatte ich drin. Führt aber dazu, dass in jedem Falle ein Adminkonto aktiviert werden muss und dann bekommt meine ScriptExe immer den falschen Anwenderpfad.
Mit IsAdmin kann ich feststellen, ob der gerade aktuelle User Admin ist. Wenn beim Start schon Adminrechte erforderlich sind, liefert das also immer 1 zurück.
RunAs könnte helfen, wenn die Exe selbst keine Adminrechte erfordert und nur für einzelne Aktionen mehr Rechte gebraucht werden. In meinem Falle ist das die Registrierung einer DLL.
Hang loose, haklesoft
Unmittelbar nach dem Start der compilierten Exe liefern auch die Environment-Variablen schon die Admindaten.
Da brauche ich also so etwas wie einen Aufrufbatch, der seinerseits keine Adminrechte erfordert und meine Exe mit Parametern aufruft.
Ich bastele morgen mal. Einstweilen vielen Dank für die Anregung.
Hang loose, haklesoft
Hallo,
die Ausführung eines compilierten Scriptes unter Vista erfordert Administratorrechte. Ein Anwender mit zu schwachen Rechten muss das Programm mit einem Administrator-Passwort starten. Das funktioniert problemlos. Allerdings liefert @AppDataDir dann das Anwendungsverzeichnis des Admin und nicht des ursprünglich angemeldeten Users.
Wie bekomme ich den ursprünglichen User und sein AppDataDir heraus? Und wie kann ich lesend und schreibend auf die CurrentUser-Registry des ursprünglichen User zugreifen?
Hang loose, haklesoft
