Hallo misterspeed,
DANKE für den Tipp 
Die Funktion kannte ich noch gar nicht.
Zu dieser Funktion habe ich aber sofort eine Frage.
Wenn ich die Funktion in einem Script einsetze und danach ein Programm mit z.B. Run starte, gilt das dann auch für dieses Programm oder nur für das Script?
MfG:
BigRox
Hallo Peter S. Taler,
da hatte Oscar mit seiner Antwort schon Recht.
Mein Problem lag nicht an Hardlinks oder fehlenden Rechten, sonder an der Umleitung zum SysWow64-Ordner.
Da stehen nämlich genau die Dateien/Ordner die mir die _FileListToArray-Funktion angezeigt hat und wenn ich mein Script mit der Direktive
"#AutoIt3Wrapper_UseX64=y" kompiliere, so funktioniert auch alles.
Einen kleinen Hacken hat die Sache aber, das Script läuft dann natürlich auch nur noch auf einem 64bit System.
Und wenn ich das Script mit der F5-Taste in SciTe starten will, so muss ich die auch die AutoIt3_x64.exe-Datei verwenden.
Mit Kompatibilität zu 32bit Rechnern, wird es dann etwas schwierig (für die Kisten muss ich meine Scripte dann wieder als 32bit kompilieren).
MfG:
BigRox
Hallo,
ich habe da ein Problem mit der _FileListToArray- Funktion.
Zuerst als Betriebssystem verwende ich Windows 10 Pro 16299.248 64bit und die AutoIt Version ist 3.3.14.2.
Mein Problem ist, dass die Funktion nicht immer alle Dateien auflistet.
Bei dem Ordner "C:\Windows\System32\Dism" funktioniert es, es wird alles aufgelistet.
Bei dem Ordner "C:\Windows\System32\oobe" werden alle Ordner und nur zwei Dateien aufgelistet, obwohl der Ordner 28 Dateien enthält.
Und bei dem Ordner "C:\Windows\System32\Tasks" werden nur die Ordner und keine Dateien aufgelistet (der Ordner enthält aber auch acht Dateien.
Der Funktionsaufruf ist aber immer so, dass Dateien und Ordner aufgelistet werden sollen.
Hier ein kleines Beispiel zum testen:
#include <Array.au3>
$Test = _FileListToArray("C:\Windows\System32\Dism")
;$Test = _FileListToArray("C:\Windows\System32\oobe")
;$Test = _FileListToArray("C:\Windows\System32\Tasks")
_ArrayDisplay($Test)
MsgBox(262144, "", "Ich habe fertig!")
Exit
Gibt es eine Lösung, damit die Funktion immer alles auflistet?
MfG:
BigRox
Hallo,
ich habe noch etwas rumgetestet und habe zumindestens das Problem mit dem installieren der MSDN-Library gelöst.
Also das Script zum Installieren der Library braucht keine Administratorberechtigung. Das Script lässt sich mit F5 in SciTE problemlos und ohne #RequireAdmin starten.
Wenn ich es mit der Kompiler-Direktive "Default" kompiliere, so lässt es sich per Doppelklick auf die EXE auch problemlos starten.
Aber wenn ich diese EXE per Autostart starten lassen will, so funktioniert die EXE plötzlich nicht mehr, aber wenn ich zum starten den Taskplaner von Windows einsetze, so funktioniert alles auch wieder.
Also kann man anscheinend kein kompiliertes Script mehr per Autostart starten lassen sondern muss in diesem Fall immer den Taskplaner einsetzen.
Aber in den scriptbreaking changes finde ich nichts dazu.
Das man keine Kompilierten Script per Autostart mehr starten lassen kann, mag ja aus Sicherheitsgründen noch sinnvoll sein, aber das man diese Funktion einfach mit dem Taskplaner machen kann, ist wohl nicht so ganz sinnvoll. Das bedeutet ja nur etwas mehr Schreibarbeit für eine "bösen Buben".
MfG:
BigRox
Hallo,
ich habe mir mal die Mühe gemacht und mein altes Windows 7 SP2 64bit installiert.
Dabei habe ich die Version von Microsoft installiert und nur den Schieberegler der UAC auf die unterste Stufe gestellt und sonst nichts geändert.
Dann habe ich AutoIt 3.3.8.1 und SciTe installiert und mein Script damit kompiliert und ausgeführt.
Und es funktioniert.
Danach habe ich AutoIt und SciTe vollständig deinstalliert und nach einem Neustart AutoIt 3.3.14.2 und die neuste Version von SciTe installiert.
Dann habe ich mein Script nochmals kompiliert und ausgeführt.
Und es ging plötzlich nicht mehr.
Danach habe ich das selbe nochmals mit Windows 10 16299.248 64bit gemacht (auch nur den UAC-Schieber auf die unterste Stufe und sonst nichts) und es führte zum selben Ergebnis.
AutoIt 3.3.8.1 und das Script läuft, AutoIt 3.3.14.2 und Game over.
Also scheint es doch irgendetwas mit AutoIt zu tun zu haben.
Zudem habe ich bemerkt, dass sich bei AutoIt 3.3.14.2 die MSDN Library nicht mehr mit dem Run-Befehl instillieren lässt.
Das CD-Laufwerk startet zwar, aber es erscheint kein Fenster vom Setupprogramm mehr.
Mit ShelExecute kommt zwar ein Fenster, aber es lässt sich dann nur noch mit Send-Befehlen bedienen.
Beachte bitte auch mit welchen Rechten Du eingeloggt bist. Hast Du bereits Admin Rechte oder bist Du gar bereits als Admin unterwegs? Oder anders ausgedrückt. Du schreibst ja, UAC sehr weit zurückgedreht... wie weit? Kannst Du von Deinem Acount aus Änderungen in der Reg ausführen (händisch) ohne dass Du ein Admin PSW brauchst? Wenn ja dreh das UAC soweit zu dass Du ein Admin PSW zur Änderung benötigst und schau was autoit dann macht.
Ich denke wie folgt:
Ich bin als einiger Benutzer eingeloggt. Windows nennt diese einzige Konto zwar Administrator, nur muss ich für bestimmte Änderungen bestätigen, dass ich Administrator-Berechtigungen habe. Der UAC-Schieberegler steht bei mir auf der untersten Stufe aber damit ist die UAC bei Windows 10 ja nicht ganz aus.
Von meinem Account kann ich gewisse Änderungen in der Registry nur machen, nachdem ich bestätigt habe das ich Administrator bin.
Damit bin ich bisher immer ganz gut zu Recht gekommen, man wird eben nicht andauernd von UAC-Meldungen "belästigt" und hat dennoch einen gewissen Schutz.
Da hat Microsoft die Kontobezeichnung wohl etwas unglücklich gewählt, weil es viele verwirrt, wenn das Konto zwar Administrator heißt es aber trotzdem kein vollwertiges Administrator-Konto ist.
MfG:
BigRox
Hallo,
also sollte das #RequireAdmin eigentlich nur in einem Script beachtet werden und wenn ich das Script kompiliere, so müsste es eigentlich ignoriert werden, weil es dann ja die Kompiler-Direktiven gib.
Es wird aber nicht ignoriert, da es ein Ausführen des mit Kompiler-Direktiven kompilierten Scriptes unmöglich macht.
Das man ein kompiliertes Script mit Admin-Rechten früher per Autostart aufrufen konnte, das hat mich auch schon gewundert, damit währen ja alle Sicherheitsbemühungen von Microsoft ganz leicht auszuhebeln.
Einfach #RequireAdmin ins Script schreiben und schon währe die Malware installiert
.
Und das eine EXE früher Admin-Rechte brauchte um zu laufen und jetzt dafür auch schon Invoker reicht = Verwirrung total
.
Anscheinend hält sich die AutoIt-Version 3.3.14.2 da genauer an die Regeln.
MfG:
BigRox
Hallo Bitnugger,
ich habe es eben mal ausprobier.
die kompilierte EXE eines Scripts lässt sich nur per Autostart starten, wenn man das #RequireAdmin weglässt und als Kompiliererdirektive:
"#AutoIt3Wrapper_Res_requestedExecutionLevel=asInvoker"
schreibt.
Damit frage ich mich aber, wozu ist dann dieses #RequireAdmin überhaupt noch gut?
Anscheinend braucht man es nur noch damit die UAC einem Script (EXE) nicht andauernd mit ihrem "rummeckern"die "Quere" kommt.
Aber wieso darf man es dann an gewissen Stellen keinesfalls reinschrieben? Oder stellt die Direktive "asInvoker" die UAC auch ruhig?
MfG:
BigRox
Hallo,
Ausserdem schreibe ich meine Scripte möglichst so, daß sie keine Adminrechte benötigen,
das braucht es eigentlich nur wenn man in der Registry herumautomatisieren will oder in
Ordnern arbeitet für die einem die Rechte fehlen(dann verschaffe ich mir die Rechte auf anderem Wege.).
genau dass mache ich in einigen Scripten.
Z.B. ändere ich mit einem Scirpt viele Einstellungen vom Explorer, Maus, Taskleiste, Desktop, Taskplaner usw. und das geht nur mit Adminrechten.
(aber auch Schlüssel für die man eigentlich keine Admin-Rechte braucht, werden nicht geändert).
Aber so einfach, mit einem #RequireAdmin im Script, kann es eigentlich auch nicht gehen, sonst könnte sich ein "böser Bube" so auch ganz einfach Admin-Rechte verschaffen.
Aber es muss ja auch irgendwie noch gehen, sonst währe ja vieles mit AutoIt nicht mehr möglich.
Wenn ich z.B. ein Script in dem #RequireAdmin steht durch einen Doppelklick selber starte, so funktioniert es.
Wenn ich aber dieses Script automatisch per Autostart starten lasse, so geht es nicht mehr.
MfG:
BigRox
Hallo,
früher, als ich noch mit der AutoItVersion 3.3.8.1 gearbeitet hatte war alles noch in Ordnung.
Nun bin ich auf die AutoIt-Version 3.3.14.2 umgestiegen und damit gingen die Probleme los.
Zuerst, ich verwende Windows 10 1709 64bit als Betriebssystem und habe die UAC auf die unterste Stufe gestellt, weil ich ansonsten von UAC-Meldungen regelrecht erschlagen werde. Ich bin auch der einzige Benutzer des Rechners und habe daher auch nur ein Konto.
Nun zu meinem Problem:
Es geht um dieses "#RequireAdmin", das ist ja anscheinend wegen der UAC nötig, um der UAC mitzuteilen, dass das Script Admin-Rechte benötigt und deswegen nicht "rummeckern" soll.
Ich habe da z.B ein Script, welches zuerst gestartet wird. In diesem Script steht am Anfang dieses #RequireAdmin. Dieses Script ruft ein anderes Script mit Run() auf und in diesem Script steht auch dieses #RequireAdmin. Das erste Script funktioniert und ruft auch das zweite Script auf. Aber dieses zweite Script spinnt dann total, da werden Befehle einfach ignoriert (aber bei jedem Aufruf andere) oder Variablen habe auf einmal ganz falsche Werte oder das zweite Script wird komplett übersprungen usw.
Auch kann man z.B. keinen Autostart-Eintrag zu einem Script ausführen, wenn in diesem Script dieses #RequireAdmin steht.
Oder mit #RequireAdmin funktioniere plötzlich auch einige Run()-Befehle im Script nicht mehr.
Wie geschrieben, unter 3.3.8.1 funktionierte das alles einwandfrei, aber in der Version 3.3.14.2 ist da anscheinend etwas geändert worden.
Da muss ich wohl alle Scripte umschreiben, damit sie auch mit 3.3.14.2 funktionieren. Nur vorher muss ich genau wissen, wie man dieses #RequireAdmin in den beschriebenen Fällen einsetzt.
Darf man #RequireAdmin überhaupt nochmal benutzen, wenn es in einem vorherigen Script schon einmal benutzt wurde?
Und wie erstellt man einen funktionierenden Link zu einem Script, in dem #RequireAdmin stehen muss (wenn man es einfach weglässt, so funktiioniert vieles in dem Script nicht)?
MfG:
BigRox
P.S. mit dem
If Not IsAdmin Then
#RequireAdmin
EndIf
geht es auch nicht.
Hallo,
ich habe wieder eine kleine "Unschönheit" in der deutschen Hilfe entdeckt.
Es handelt sich um die Zeilen mit den Rückgabewerten der Funktion RegWrite.
1 = der angegebene Schlüssel kann nicht geöffnet werden
2 = der angegebene Hauptschlüssel kann nicht geöffnet werden
3 = keine Verbindung per Netzwerk zur Registrierung kann hergestellt werden
-1 = der angegebene Wert kann nicht geöffnet werden
-2 = der Wertetyp nicht unterstützt wird
Als ich die Texte bei den Rückgabewerten 3 und -2 gelesen habe, musste ich sofort an den Oberjedi Yoda denken .
Auch die Formatierung der Textzeilen sieht etwas sonderbar aus. Irgendwie ist da wohl bei der ersten Zeile etwas nicht in Ordnung.
(das sieht man aber in der Hilfe besser).
Das betrifft aber nicht nur diese Funktion, dass ist nämlich bei allen Registry-Funktionen so, dass die erste Zeile etwas nach links verschoben ist.
Übrigens:
Das mit der Fahne oben rechts - zum umschalten zwischen deutsch und englisch - finde ich richtig gut.
MfG:
BigRox
Hallo,
mir ist eben auch etwas aufgefallen.
Es handelt sich um die UDF _ArrayDelete()
Da steht ja als Beschreibung:
Entfernt das festgelegte Element bzw. die festgelegten Elementes von dem festgelegten 1D oder 2D Array
Sollte man das nicht, in z.B.:
Entfernt das festgelegte Element bzw. die festgelegten Elemente aus dem festgelegten 1D oder 2D Array
ändern?
Es steht zwar im englischen:
Deletes the specified element(s) from the specified 1D or 2D array
Aber stimmt das eigentlich so, überall list man nämlich, dass man Werte nicht von einem Array, sondern aus einem Array löscht.
MfG:
BigRox
Hallo Bitnugger und BugFix,
nachdem ich die Datei auf ein FAT32-Laufwerk kopiert habe und sie davon ins AutoIt-Verzeichnis kopiert habe, funktioniert es auch bei mir.
Danke für den Tipp, da wäre ich wohl so schnell nicht drauf gekommen.
Das sollte man aber auch in die "lesen.txt"-Datei schreiben, damit es jeder lesen kann.
MfG:
BigRox
Hallo Tweaky,
ich habe mir eben AutoIt 3.3.14.2 installiert und danach die neuste SciTE-Version installiert.
Danach habe ich die Dateien der deutschen Hilfe vom 11.12.2017 so kopiert, wie es in der "lesen.txt"-Datei steht.
Leider funktioniert aber irgendetwas nicht so recht.
Es wird mir zwar immer das Fenster von der deutschen Hilfe angezeigt, aber darin ist immer nur etwas im linken Fenster zu sehen, dass rechte Fenster, wo die eigentlichen Hilfetexte usw. stehen sollte, bleibt jedoch immer leer.
Auch das mit einen Befehl markieren und dann dien dazugehörenden Hilfetext mit "F1" aufrufen, funktioniert nicht.
Bei der AutoIt-Version 3.3.8.1 waren es doch drei Dateien für die Hilfe (AutoIt.chm, AutoIt3.chm und UDF3.chm) bei der neuen Version ist es jedoch nur noch eine 11MB-Datei für die Hilfe.
Liegt da eventuell das Problem?
Ich habe, mal so aus Spaß, die drei Dateien der 3.3.8.1-Version, in das AutoIt-Verzeichniss der 3.3.14.2-Version kopiert und dann funktioniert das ganze wieder richtig (nur wird dann auch die alte Version der Hilfe angezeigt).
MfG:
BigRox
Hallo BugFix,
DANKE für die Erklärung dieser Sache.
MfG:
BigRox
Hallo BugFix und Oscar,
DANKE für eure Antworten
Ich versuch es mal mit der Funktion von BugFix.
Die Funktion funktioniert ganz gut.
Nur eins ist mir dabei nicht so ganz klar.
Wenn GDI+ schon vorm Aufruf der Funktion mit _GDIPlus_Startup() gestartet wurde, beendet dies Funktion dann einfach GDI+, weil da ja am Ende _GDIPlus_ShutDown() aufgerufen wird, oder läuft GDI+ auch nach dieser Funktion dann noch weiter, da ja dann auch noch einige GDI+-Objekte existieren ?
MfG:
BigRox
Hallo,
ich versuche die Länge eines Texte in Pixel zu ermitteln.
Dabei kann ich aber nicht einfach die Zeichenzahl verwenden, da der Text als proportionale Schrift angezeigt werden soll.
Der Text soll z.B. als SplashText angezeigt werden, wobei sich die Länge der Box automatisch an die Textlänge anpasst.
Dabei bin ich u.a. auf die Funktion "_GUICtrlListView_GetStringWidth($hListView, "Text")" gestoßen.
Diese Funktion gibt mir zwar die Pixelzahl zurück, aber sie braucht auch ein Handle zu einer ListBox, die ich aber nicht habe.
Ich vermute diese Handle wird von der Funktion benötigt, um die Schriftart die Schriftgröße usw. zu ermitteln.
Ich brauche also eine Funktion, die aus einem Text, der als String vorliegt, die Pixelzahl zurückgibt, die dieser String benötigt und die am besten alle zum ermitteln erforderlichen Werte selber aus z.B. der Registry (ich vermute mal, da steht alles erforderliche drin) auslesen kann.
Achja, die Funktion soll mit Windows 10 funktionieren.
MfG:
BigRox
Hallo Xorianator,
ich habe letztens ein Problem mit dem APM von Festplatten gehabt.
Dabei las ich auch immer wieder, dass es dadurch auch bei einigen zu diesem "Stottern" gekommen ist.
Vielleicht hängt dein Problem ja auch mit dem APM der Festplatte zusammen.
Versuch doch mal APM abzustellen.
Das geht z.B. mit dem Programm "CristalDiskInfo" (Optionen | Erweiterte Optionen | AAM//APM Verwaltung...).
Nur das gilt dann aber nur für die aktuelle Windows-Sitzung, nach einem Neustart ist APM wieder aktiv.
(dafür gibt es aber anscheinend auch eine Lösung (Autostart lässt grüßen 
))
MfG:
BigRox
Hallo Mars,
Ein Problem das ich seit Win10 beobachte ist, dass der Rechner immer für 30-40sek komplett einfriert
Dazu einen kleinen Tipp von mir:
Wenn der Rechner mit einer SSD/mSATA ausgestattet ist, dann probier mal das LPM für dieses Laufwerk in der Registry abzustellen.
Bei Windows 10 wird das nämlich standardmäßig eingeschaltet, obwohl viele SSD/mSATA das nicht können.
Das selbe Problem hatte ich auch, nachdem ich eine mSATA in mein Notebook eingebaut hatte und da war auch das LPM (Link Power Management) die Ursache.
Hier mal eine kleine Beschreibung dazu:
Schlüsselname.txt
MfG:
BigRox
Hallo Bugfix,
ich habe einen kleinen Zusatzverstärker (250W 
Eigenbau) an meinem TV, da mir der interne Verstärker (10W 
) etwas zu schwach ist.
Den habe ich einfach an den Kopfhörerausgang gesteckt.
Das ganze steuere ich mit der normalen Fernbedienung des TV und alles funktioniert einwandfrei (Lautstärke, Klang und Ton aus sin damit problemlos steuerbar).
Somit brauche ich dafür keine extra Fernbedienung und vorallem gehen mir die internen Krawallbüchsen nicht mehr auf den S... .
MfG:
BigRox
Hallo Bitnugger,
Danke für den Hinweis .
Genau das war mein Problem.
Ein 64-Bit System, ist zwar modern und angesagt, aber eben manchmal auch etwas "anders".
MfG.
BigRox
