Beiträge von BigRox

    Hallo timee000,

    ich habe das mit "_WinAPI_IsWindowVisible" ausprobiert.


    Ergebnis:

    Die Funktion gibt mir auch immer das Fenster sei sichtbar zurück, obwohl das Fenster nirgends sichtbar ist.

    Es erscheint aber auch nicht, wenn man es mit "WinSetState($_WindowHandle, "", @SW_MAXIMIZE)" maximieren, oder mit

    "WinSetState($_WindowHandle, "", @SW_SHOW)" anzeigen will.


    MfG:

    BigRox

    Hallo,

    ich habe mal wieder einige Fragen.

    Wie kann man das Fenster des Microsoft-Edge Browser erkennen und zwar wenn ich den Browser selber gestartet habe und daher

    auch ein Symbol in der Taskleiste angezeigt wird?


    Und wie kann man erkennen, dass der Edge-Browser von Windows und nicht von mir gestartet wurde?


    Hintergrund dieser Frage:

    Ich installiere Windows 10 öfters zum Testen in VirtualBox. Da richte ich keine Netzwerkverbindung ein, da ich in Virtualbox keine Internetverbindung will (beim installieren einiger Programme darf auch keine Internetverbindung bestehen).

    Zudem ist diese Windows-Version nicht aktiviert (nur zum testen ist das ja auch nicht nötig, es sei den man will irgendetwas personalisieren).

    Dann wird jedesmal, wenn ich diese Windows-Version starte, MS-Edge ohne mein Zutun von Windows gestartet (anscheinend um die Aktivierung zu testen), aber der Browser wird nirgends angezeigt. und MS-Edge wird erst wieder beendet, wenn eine Internetverbindung besteht).

    (Bei einer aktivierten Windows-Version wird der Browser nicht gestartet, oder er läuft nicht lang genug, das ich in erkennen kann).

    Es gibt zwar eine Process des Browsers und auch in einer Liste (WinList(), _ArrayDisplay()) der Fenster erscheint Microsoft Edge (Status des Fensters 7), aber dieses Fenster erscheint nirgends, auch nicht als Symbol in der Taskleiste. Somit kann ich das Windows-Info-Tool von AutoIt ja auch vergessen und der Process von MS-Edge kann man auch nicht zum identifizieren gebrauchen.


    Aber genau diese Zustand möchte ich aber eindeutig erkennen.

    (oder kann man irgendwie abfragen, ob das Symbol von MS-Edge in der Taskleiste sichtbar ist)?


    MfG:

    BigRox

    Hallo Bitnugger,

    DANKE für den Tipp :thumbup:.


    Auf die Möglichkeit den Button anhand seines Textes zu identifizieren hätte ich eigentlich auch selbst kommen können.

    Aber ab und zu sieht man anscheinend den Wald vor lauter Bäumen nicht mehr:D.


    MfG:

    BigRox

    Hallo,

    ich habe ein Problem beim Installieren eines Programms in VirtalBox 5.2.8.

    Bei dem Programm, das ich installieren will, handelt es sich um AIMP.

    Dafür habe ich ein Script geschrieben und das funktioniert einwandfrei. Es funktioniert auch auf verschiedenen Rechnern, welche u.a. auch mit Windows 10 64bit laufen.

    Jetzt wollte ich mit Hilfe dieses Scripts AIMP mal in einem Windows 10 64bit auf VirtualBox installieren und das geht nicht.


    Also Fehlersuche, Ergebnis: Die Buttonbezeichnungen stimmen plötzlich nicht mehr.

    Hat ein Button beim installieren auf einem "realen" PC die Bezeichnung: "TACLButton2", so "hört" dieser Button in VirtualBox plötzlich auf den Namen:

    "TACLButton1".

    Dies gilt aber nur, wenn sich nur ein Button in dem Fenster befindet, bei Fenstern mit zwei Buttons stimmen die Bezeichnungen plötzlich auch wieder.

    Mit einem anderen Script, welches die Buttons über ihre ID anspricht, funktioniert es immer.

    Also scheint das ein Problem mit den Instanzen der Steuerelmente in VirtualBox zu sein.

    (bei AIMP gibt es aber leider keine eindeutigen ID`s)


    Das was mir dazu einfällt, wäre: Advanced (Class) verwenden und dabei die Instanz weglassen und nur bei Fenstern mit mehreren Buttons, die Instanz dazuschreiben.

    Oder gibt es da noch eine "elegantere" Möglichkeit dieses Problemchen zu lösen.


    MfG:

    BigRox

    Hallo misterspeed,

    DANKE für den Tipp :thumbup:


    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:

    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=O.


    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 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 und Oscar,
    :thumbsup: DANKE für eure Antworten :thumbsup:


    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