Beiträge von Bitnugger

    "AutoIt habe ich offiziell in der Whitelist und kann es also benutzen."


    Das habe ich aber auch übersehen... dann kann @CHmux seine Scripte ja einfach mit der AutoIt3.exe starten, ohne sie zu kompilieren.


    Run a script using the interpreter:

    AutoIt3.exe [/ErrorStdOut] [/AutoIt3ExecuteScript] filename [params ...] ; Execute the AutoIt3 script 'filename' with optional parameters

    Wenn Du bei ControlFocus das Child korrekt setzt: ControlFocus($hEdit, '', $hListView), dann geht ControlGetPos auch mit Leerstrings: ControlGetPos($hListView, '', '').

    Danke für dein Feedback... ich denke zwar, dass es so nicht korrekt ist, obwohl es funktioniert, aber es hat mich dennoch auf den Weg der Erleuchtung gebracht!


    Die ersten drei Parameter der Control*()-Funktionen sind ja immer gleich...


    Control* ( "title", "text", controlID ...


    ParameterErklärung
    Bemerkungspez. Beschreibungen
    titleThe title/hWnd/class of the window to access.Parent-WindowTITLE, TEXT, REGEXPTITLE, REGEXPCLASS, LAST, ACTIVE, X \ Y \ W \ H, INSTANCE
    textThe text of the window to access.kann in Verbindung mit title angegeben werden
    irgendein Text, den AutoIt sehen kann, z.B. von einem Edit, Input, Button.
    text wird als SubString behandelt.
    Versteckte Fenster können nur durch den title gefunden werden, wenn text leer ist.
    controlIDThe control to interact with.ControlID, TEXT, CLASS, CLASSNN, NAME, REGEXPCLASS, X \ Y \ W \ H, INSTANCE


    Als controlID kann auch das Handle des Controls ($hEdit, $hListView) angegeben werden, was der Hilfe aber nicht zu entnehmen ist... dann dürfen die ersten beiden Parameter auch Leerstrings sein.


    Allem Anschein nach verhält es sich so:


    Alle Control*()-Funktionen erwarten als ersten Parameter etwas, mit dem das Handle eines Windows identifiziert werden kann. Dort kann alternativ auch direkt das Handle eines Controls angegeben werden, solange dieses selbst keine Child-Windows hat. Ist der erste Parameter eindeutig, kann für die beiden folgenden Parameter einfach ein Leerstring übergeben werden, ohne das Probleme zu erwarten sind.


    Hat das Control allerdings selbst Child-Windows, kann der Fokus nur auf eines dieser Childs gesetzt werden, was dazu führt, dass dann alle Control*()-Funktionen ebenfalls das Handle des Childs verwenden... also das Handle des Controls, dass den Fokus hat.

    Also Problem gelöst?

    Es ist weniger ein Problem, sondern vielmehr eine Verständnisfrage... denn im ersten Post habe ich ja bereits im Script gezeigt, wie ich zum korrekten Ergebnis komme.

    Was sagt ihr dazu?

    Ich formuliere sie mal anders: Wieso beeinflußt der Fokus das Ergebnis von ControlGetPos($hListView, '', '') und wieso wird der Fokus bei ControlFocus($hListView, '', '') auf "Edit1" gesetzt?


    Letzteres kann ich ja noch halbwegs nachvollziehen... weil $hListView mit _WinAPI_SetWindowLong zum Parent-Window für $hEdit gemacht wurde...

    Da fehlt die ControlID:

    Darum geht es doch gar nicht... denn ControlFocus($hEdit, '', '') funktioniert ja... und zwar immer, weil $hEdit ja das Handle des Controls ist und somit auch unverwechselbar ist, weshalb dann für Text und ID ein Leerstring reicht.


    Das Problem ist, dass ControlGetPos dann unterschiedlich reagiert, wenn... siehe Post #3.

    Ich verstehe dein Problem nicht ganz. Wenn ich "ControlFocus()" benutze wie vorgesehen, funktioniert es doch richtig, oder?

    Hehe... ja, sicher, wie vorgesehen... das ist ja auch unverwechselbar... nur gibt es halt auch Controls, für die keine ControlID verfügbar ist... deshalb habe ich mir angewöhnt, nur das Handle des Controls zu nehmen... und unter "normalen" Bedingungen funktioniert das ja auch tadellos.


    Bei ControlGetPos gebe ich dann ja als ersten Parameter auch das unverwechselbare Handle des Controls an... Text und ID kann ich mir somit ersparen, dachte ich... aber wie man sieht, eben nicht immer... und wie schon erwähnt... was machen, wenn das Control keine ID hat?


    ControlGetPos($hGUI, "", "[CLASS:Blabla; INSTANCE n]") wäre eine Möglichkeit... nur blöd, wenn sich die Instanz dann im Laufe des Betriebs ändert...


    Das Problem hier ist, dass ControlGetPos($hControl, '', '') nur dann korrekt funktioniert, wenn der Fokus nicht auf einem der Controls liegt, die durch _WinAPI_SetWindowLong() beeinflußt wurden.


    Die erste Frage ist also: Was hat ControlGetPos mit dem Fokus zu tun?

    So wie im Titel angegeben, mache ich es sehr oft mit ControlGetPos und hatte bis dato kein Problem damit gehabt... aber das hat sich nun geändert!


    Die für den "Fehler" relevanten Zeilen:

    _WinAPI_SetWindowLong($hEdit, $GWL_HWNDPARENT, $hListView) ; Setzt das Handle des Parentfensters für $hEdit auf $hListView - das allein löst aber keinen Fehler aus!

    ControlFocus($hEdit, '', '') ; Das ist der Bösewicht... ControlGetPos($hListView, '', '') und ControlFocus($hListView, '', '') funktionieren danach nicht mehr richtig!


    Lege ich den Fokus auf ein anderes Control, z.B. ControlFocus($hOK, '', ''), funktioniert wieder alles...


    Was sagt ihr dazu?


    Hier das Test-Script:

    Mittlerweile vermute ich ein Problem in der (erlaubten) Kommunikation da, wenn ich das Skript lokal ausführe, es funktioniert.

    Das kannst du mit dem Microsoft-Tool wbemtest testen.

    https://knowledge.broadcom.com…ectivity-using-micro.html


    https://social.technet.microso…forum=winserverManagement


    https://www.windowspro.de/wolf…remote-ueber-wmi-auslesen



    Ich teste später aber dennoch nochmal das Skript von dir (Bitnugger) ob das eine Änderung bewirkt.

    Ich denke mal ja... denn in deinem Script sind zwei böse Fehler drin...

    - Zeile 9 muss vor Zeile 8 stehen

    - nach Zeile 8 musst du testen, ob $colItems ein Objekt ist, bevor du darauf zugreifst.


    So wäre es korrekt:

    Moin, hier mal eine erste Alpha-Version meines Scripts zum In-Place-Editieren aller ListView-Items.


    Das Besondere daran ist, dass um das Edit-Control (Input) ein Frame gezeichet wird, dass die Farbe wechelt... wenn der Mauszeiger darüber steht, wird Brush2 verwendet, wenn nicht Brush1 und dass es auch funktioniert, wenn die Items im ListView gescrollt werden - und dass die Farben der Items/SubItems anpassbar sind, wobei das Item mit dem Fokus eine eigene Farbe bekommt. Es funktioniert auch dann, wenn die Schrift-art/größe des ListViews geändert wird.


    Ich würde gerne eure Meinungen/Verbesserungsvorschläge dazu hören... und wer mag, darf gerne Hand anlegen und es optimieren. ;-)



    Update: Edit bleibt nun auch aktiv, wenn sich die Größe des Fensters geändert hat.

    Dateien

    Bei einigen PCs wird allerdings keine SerialNumber angezeigt, so auch bei virtuellen Maschinen. Da kann dann z.B. auch To be filled by O.E.M. oder 0 stehen.


    Hier ein Bsp. mit Powershell:

    PS C:\Users\bitnugger> Get-WmiObject -Class Win32_BIOS


    SMBIOSBIOSVersion : A7522MLN.10F

    Manufacturer : American Megatrends Inc.

    Name : Default System BIOS

    SerialNumber :

    Version : MEDION - 20100914

    Wobei _WinAPI_GetLastError() & ' ' & _WinAPI_GetLastErrorMessage() mir zurück gibt: 0 DER VORGANG WURDE ERFOLGREICH BEENDET.

    _WinAPI_GetLastError() und _WinAPI_GetLastErrorMessage() rufst du auf, wenn du zuvor eine _WinAPI_*-Funktion ausgeführt hast, z.B. _WinAPI_ActivateKeyboardLayout.


    Um Fehler bei Objekten abzufangen und auszuwerten, brauchst du einen COM ERROR HANDLER.


    Hier ein Bsp. mit _DebugCOMError:


    Hier noch eins ohne _DebugCOMError:


    $IP musst du natürlich anpassen...

    Script von Bitnugger hat mir alle Icons kreuz und quer um die Ohren gehauen!

    Oh ja... ich denke ich habe die fehlerhafte Zeile gefunden:

    _GUICtrlListView_SetItemPosition($g_hListview, $iIndex, $aIcons[$iIndex][1], $aIcons[$iIndex][2]) ; Position wieder restaurieren!

    Richtig ist:

    _GUICtrlListView_SetItemPosition($g_hListview, $i, $aIcons[$iIndex][1], $aIcons[$iIndex][2]) ; Position wieder restaurieren!


    Nur um das klarzustellen: ICU (Icon Configuration Utility) von KaFu ist definitiv die bessere Wahl... das Minimal-Script von Veronesi und auch die geänderte Version von mir funktionieren nur dann, wenn die Desktopeinstellungen es zulassen. ICU berücksichtig diese jedoch.

    Wie wäre es mit dem Icon Configuration Utility von KaFu?

    Danke... habe mal rein geschaut... Fehlerprüfung hat er deaktiviert... ist nicht wirklich sauber geschrieben, aber sicher einen Blick wert.


    SEuBo - ich habe aus dem Script von KaFu die Funktion zum Ermitteln des Desktop-Handle mit bei mir eingebaut... teste es mal damit.

    Funktionieren allerdings beide (weder das von Veronesi, noch von Dir Bitnugger ) bei mir. Windows 10 version 2004 , 64 Bit.

    Schon seltsam... ich habe:

    AutoIt: 3.3.14.5/X64

    PC1: Windows 10 20H2 (Build 19042.685), X64

    PC2: Windows 10 Version 2004 (Build 19041.685), X64


    Auf PC1 habe ich Fences installiert ControlGetHandle("[CLASS:NDesk]", ...) und auf PC2 nicht ControlGetHandle("[CLASS:Progman]", ...), auf beiden funktioniert es.


    Mein bei Windows angemeldeter User ist in der Gruppe der Administratoren (Default) und UAC ist deaktiviert... aber das kann es nicht sein!?


    Was sagt denn das AutoIt-Info-Tool, wenn du den Finder auf dem Desktop (freie Stelle) loslässt?

    Zitat von @CHMux

    Das Skript unter dem Link von SEuBo (Desktop icons) ist schon mal sehr gut.

    Na ja, gut ist relativ... hier mal meine Version:

    Hier eine etwas geänderte Version des Bsp. aus der AutoIt-Hilfe zu _WinAPI_DragAcceptFiles, das auch funktioniert, wenn das Script als Administrator ausgeführt wird.


    Im Original wird ein Label verwendet, für Tweaky habe ich dafür nun ein Listview verwendet... und zudem folgende auskommentierte Zeilen im Script aktiviert:

    AutoIt
    ; Allow WM_DROPFILES to be received from lower privileged processes (Windows Vista or later)
    #cs
    If IsAdmin() Then
    _WinAPI_ChangeWindowMessageFilterEx($g_hLabel, $WM_COPYGLOBALDATA, $MSGFLT_ALLOW)
    _WinAPI_ChangeWindowMessageFilterEx($g_hLabel, $WM_DROPFILES, $MSGFLT_ALLOW)
    EndIf
    #ce

    Dies ermöglicht den Empfang von WM_DROPFILES von Prozessen mit niedrigeren Berechtigungen.


    Weil sich das Listview in dem geänderten Bsp. in einer Group befindet, muss bei _WinAPI_DragAcceptFiles das Handle der Group angegeben werden, ohne Group das Handle des Listviews.