GuiCtrlBusy - wie ToolTip, nur anders ;-) - Final [v1.0]

    • Offizieller Beitrag

    2017-10-26: FINAL v1.0

    Mit GuiCtrlBusy.au3 können ToolTip ähnliche Controls erstellt werden, mit einer Vielzahl von Funktionen.

    • Mehrere Ctrl lassen sich gleichzeitig erstellen, z.B. zum Debuggen in verschachtelten Schleifen.

    • Ctrl haben eine minimale Größe von 250*120 (B*H)

    • Die Ctrl lassen sich mit der Maus ziehen.

    • 3 Arten von Ansichten, Titelzeile mit: Titel allein / Titel und Uhrzeit / Titel und Countdown (Standard)

    • Alle Ansichten lassen sich mit Countdown verwenden. Die Restzeit kann im Text angezeigt werden mit "%C%".

    • Zwischen den Ansichtsarten kann hin und her gewechselt werden.

    • Font, Größe und Stil des Titels sind fest. Titel und Trennlinie verwenden dieselbe Farbe.

    • Links vom Titel kann ein Icon gesetzt werden. (aus *.dll oder *.ico Datei)

    • Die Textausgabe erfolgt links, rechts oder zentriert (Standard).

    • Die Textfarbe kann unterschiedlich zur Titelfarbe gesetzt werden.

    • Der Text kann in Font, Größe und Stil verändert werden.

    • Für die Färbung des Hintergrundes wird ein Farbverlauf verwendet. Dessen Richtung kann von oben-nach-unten (Standard) auf links-nach-rechts geändert werden.

    • Es existieren vordefinierte Farbschemata, die genutzt werden können.

    • Temporär lassen sich eigene Farbschemata hinzufügen.

    • Alle Parameter sind zur Lebenszeit des Ctrl änderbar.

    • Alle Ctrl haben ein Sicherheits-Timeout. Es ist vordefiniert in $GCB_U_TIMEOUT_ZERO (Standard = 2 Stunden). Beim Setzen eines höheren Countdown Wertes,

    wird $GCB_U_TIMEOUT_ZERO automatisch auf diesen Wert erhöht.

    • Alle Standard Parameter lassen sich ändern mit _GuiCtrlBusy_UserDefaults().

    • Die Funktion _GuiCtrlBusy_GetClosed() gibt eine Dummy-ID zurück. Der Dummy wird ausgelöst beim Schliessen eines Ctrl (mit Countdown oder _GuiCtrlBusy_Close() ).

    Das Handle des geschlossenen Ctrl kann dann mit GuiCtrlRead(Dummy-ID) ausgelesen werden.

    • Das Callback Intervall ist für jedes Ctrl einzeln änderbar (Standard ist 500 ms). Bitte mit Vorsicht anwenden.

    Bei hoher Frequenz, vielen Control und Neuberechnung der Ctrl-Größe bei jedem Aufruf, wird die CPU stark gefordert.

    Zusätzlich kann aber die Neuberechnung der Ctrl-Größe gestoppt werden (normalerweise passiert das bei jeder Änderung in Titel oder Text). Haben die Änderungen

    keinen oder minimalen Einfluß auf die Textlänge, ist es sinnvoll die Berechnung zu stoppen. Dann lassen sich auch sehr kurze Callback Intervalle verwenden.

    Funktionsliste

    _GuiCtrlBusy_Create([$_sTitle=''[, $_sText=''[, $_iAlign=2[, $_iX=-1[, $_iY=-1[, $_iTimeout=-1[, $_iTimeCounter=-1[, $_BGRtitle=-1[, $_BGRtext=-1[, $_RGBtopleft=-1[, $_RGBbottomright=-1[, $_bRotate=False]]]]]]]]]]]])

    Ctrl erstellen

    _GuiCtrlBusy_Close([$_hWnd=-1])

    Ein/alle Ctrl beenden

    _GuiCtrlBusy_SetTitle($_hWnd, $_sTitle=''[, $_iTimeCounter=''[, $_iTimeout=''[, $_BGRtitle=''[, $_bSetOnTop='']]]])

    Einstellungen Titelzeile: Titel, Anzeige: nur Titel/Titel und Zeit/Titel und Countdown, Timeout, Farbe, ontop.

    _GuiCtrlBusy_SetIcon($_hWnd, $_sIconFile=''[, $_iIconID])

    Icon setzen aus *.dll/*.ico Datei. Mit Leerstring "shell32.dll".

    _GuiCtrlBusy_SetText($_hWnd, $_sText=''[, $_BGRtext=''[, $_iSize=''[, $_iStyle=''[, $_sFontname=''[,$_iAlign=''[, $_bSetOnTop='']]]]]])

    Setzen Text /~farbe /~größe /~stil /~font, opt. ontop

    _GuiCtrlBusy_SetCBInterval($_hWnd[, $_iInterval=$GCB_U_CALLBACK_INTERVAL[, $_bNoReCalc=False]])

    Setzen individuelles Callback Intervall, opt. stoppen Neuberechnung Ctrl-Größe.

    _GuiCtrlBusy_StopRecalc($_hWnd[, $_bNoReCalc=True])

    Stoppt (oder erlaubt) Neuberechnung Ctrl-Größe bei Änderung von Text oder Titel.

    _GuiCtrlBusy_SetColors($_hWnd, $_BGRtitle=''[, $_BGRtext=''[, $_RGBtopleft=''[, $_RGBbottomright='']]])

    Setzen Titel/Text/Farbverlauf Farben.

    _GuiCtrlBusy_SetGradient($_hWnd, $_RGBtopleft=''[, $_RGBbottomright=''[, $_bRotate='']])

    Setzen Farben Farbverlauf und Richtung

    _GuiCtrlBusy_SetScheme($_hWnd[, $_sScheme=''[, $_bRotate=''[, $_bSetOnTop='']]])

    Setzen von Farbschema / Richtung, optional ontop.

    _GuiCtrlBusy_GetScheme($_sScheme='')

    Rückgabe Array mit einem oder allen Farbschemata.

    _GuiCtrlBusy_AddScheme($_sScheme, $_RGBtopleft, $_RGBbottomright, $_BGRtitle, $_BGRtext)

    Hinzufügen neuer Farbschemata, nur gültig zur Laufzeit

    _GuiCtrlBusy_SetPos($_hWnd, $_iX=''[, $_iY=''[, $_bSetOnTop='']])

    Bewegen des Ctrl an x/y Position, optional ontop.

    _GuiCtrlBusy_SetTimeout($_hWnd, $_iTimeout, $_iTimeCounter)

    Setzen/Beenden des Timeout, switchen der Ansicht.

    _GuiCtrlBusy_SetOnTop([$_hWnd=-1])

    Setzt ein (Standard: alle) Ctrl ontop.

    _GuiCtrlBusy_UserDefaults($_sParamValue[, $_sDelim='|'])

    Ändern der Voreinstellungen (Standardwerte) für die Ctrl-Erstellung.

    _GuiCtrlBusy_GetClosed()

    Dummy-ID abfragen, die ausgelöst wird, wenn ein Ctrl geschlossen wird. Mit "GuiCtrlRead(Dummy)" ist das Ctrl-Handle des geschlossenen Ctrl auslesbar. 

    Testcode

    Mit dem Standardintervall von 500 ms habe ich auch bei 10 zeitgleich offenen Ctrl und Neuberechnung der Ctrl-Größe bei jedem Aufruf (normalerweise erforderlich bei jeder Änderung von Text oder Titel) keine spürbare Belastung der CPU.

    Viel Spaß damit.

    alter Inhalt

    Das Skript liegt bei mir nun schon seit Jan. 2016, jetzt poste ich es mal.

    Ich betrachte es aber noch als Beta-Status. Einige Ideen zur Erweiterung habe ich noch. Vorerst möchte ich aber erst mal Folgendes abklären:

    Bei mir tritt manchmal folgender Fehler auf. Wenn die Ctrl über lange Zeit stehen, werden diese plötzlich nicht mehr gezeichnet - werden weiß - und/oder das Programm friert ein.

    Ich kann das an keiner Ursache festmachen. zumal es nicht immer auftritt.

    Vielleicht kann das mal jemand austesten und berichten.

    Achja, was macht das Ctrl:

    - Ähnlich wie ein Tooltip, aber es können mehrere zeitgleich verwendet werden.

    - Es kann als Countdown oder reine Anzeige genutzt werden.

    - Verschieden Farbschemata sind vordefiniert (Farbverlauf, passende Textfarben).

    - Schließt das Ctrl wird eine Msg an ein Fenster eigener Wahl (Standard das aktive Fenster) gesendet.

    - Zur Laufzeit sind alle Einstellungen (Text/Titel/Farben) änderbar.

    NEU

    - Es kann ein ein Dummy-Ctrl erstellt werden, das beim Schließen der Ctrl befeuert wird (.._GetClosed() ). Das jeweilige Ctrl-Handle ist mit "GuiCtrlRead(Dummy)" auslesbar (s. Bsp)

    FARBSCHEMA:

    - Das Farbschema kann kpl. mit .._SetScheme() geändert werden

    - Zur Laufzeit lassen sich eigene Farbschemata mit .._AddScheme() hinzufügen (keine dauerhafte Speicherung)

    - Die Farbschemata lassen sich einzeln/alle als Array ausgeben mit .._GetScheme()

    TEXT:

    - Text kann links/rechts/zentriert angezeigt werden, Parameter Align bei Erstellung

    - Änderung von Textgröße, Darstellung(und/oder): Normal,Fett/Kursiv/Unterstrichen/Durchgestrichen, Schriftart

    ACHTUNG: Bei einigen Kombinationen von Schriftarten/ -größe und -darstellung ist die Größenberechnung fehlerhaft!

    - Es kann geswitcht werden zwischen Anzeige Titel(und Zeit) oder Countdown - hin und her

    - Die Textausrichtung ist auch nachträglich änderbar.

    [EDIT 2017-10-20]

    Ich habe das Skript kpl. überarbeitet. Die Erstellung und Verwaltung der Ctrl ist jetzt deutlich beschleunigt. Zugriffe erfolgen, da wo es möglich ist, ByRef. Integriert habe ich noch einen Kollisionsschutz, damit die Callbackfunktion nicht ausgeführt werden kann, während durch Nutzereingriff gerade Parameter geändert werden.

    Aber ich habe noch folgendes Problem:

    Speicherlecks treten nicht mehr auf, der genutzte Arbeitsspeicher während der Ausführung ist nahezu konstant. Aber obwohl das Skript fehlerfrei läuft (Countdown läuft runter, Uhrzeiten werden angezeigt) kann ich nach etwa zwei Minuten das Bsp-Skript nicht mehr schliessen. Keine erhöhte CPU-Nutzung, RAM auch OK. Es reagiert nur nicht.

    Könnt ihr das bitte mal nachtesten?

    [Edit im Edit] Nach Rechnerneustart tritt das Problem nicht mehr auf, da hatte wohl was anderes blockiert. - Für Rückmeldungen bin ich trotzdem dankbar.

    P.S. Icon Integration ist vorgesehen, dazu muß aber erst mal alles konfliktfrei laufen.

    [EDIT FARBSCHEMATA]

    Ich habe noch 3 weitere Schema erstellt: 'fire', 'system' und 'sys_invers'

    Ersetzt einfach die vorhandene Arraydeklaration mit der folgenden und kopiert noch die Funktion __RGB2BGR() in die UDF.

    Integriert in aktueller Version

    [EDIT 2]

    Danke an Zeitriss für das Aufspüren eines Fehlers. Die Ctrl mit Uhrzeit wurden neugezeichnet, auch wenn keine Zeitänderung stattfand. Ist jetzt in v0.10 gefixed.

    Der Code der UDF nur im Anhang (überschreitet die 100.000 Zeichen Grenze ;))

  • BugFix das Ding ist ja echt sehr gut ausgedacht und umgesetzt.

    Den Sample-Code verstehe fast vollständig, vom UDF-Code selbst verstehe ich leider nur etwa die Hälfte.

    Das ist echt harte Kost für einen fortgeschrittenen Anfänger, aber deiner Beschreibung nach klingt der Fehler doch

    eventuell nach einem Memory-Überlauf oder eine Art Speicherschutzverletzung.

    Es wäre echt super wenn der Fehler gefunden und gefixt werden könnte.

    Endlich mal richtig schöne Tooltips und vor allem mehrere gleichzeitig. So eine UDF wäre perfekt fürs Debugging

    von Scripten geeignet. Ich vewrwende fürs finden von Fehlern meistens die Tooltips.

    Aber es wäre schon öfters wünschenswert mehr als ein Tooltip gleichzeitig anzeigen zu können.

    Ich halte mir das Thema mal warm Danke BugFix

    Tuxedo

    • Offizieller Beitrag

    Den Sample-Code verstehe fast vollständig, vom UDF-Code selbst verstehe ich leider nur etwa die Hälfte.

    Beim UDF-Code ist eigentlich der Kernpunkte die _Create-Funktion. Hier werden die Fenster erstellt, ihre Parameter in Arrays gespeichert, die Arrays der zentralen Verwaltung zugeführt.

    Die Timergesteuerte Callback-Funktion prüft halt nur ob - und wenn ja - was neu gezeichnet werden soll und initiiert das dann.

    Alle anderen Funktionen dienen der Parameterverwaltung /-änderung.

    eventuell nach einem Memory-Überlauf oder eine Art Speicherschutzverletzung.

    Das klingt recht wahrscheinlich.

    Und manchmal muss man Dinge einfach mal aufschreiben um nochmal besser drüber nachdenken zu können. Ich habe mir aufgrund deiner Vermutung nochmals die Callback-Funktion angeschaut: Wie es aussieht habe ich vergessen beim Freigeben der Ressourcen einen DC zu löschen.

    In Zeile #653 (Gradienterstellung) hole ich mir den DC Local $hDC = _WinAPI_GetDC($hWnd), gebe ihn aber nicht wieder frei.

    Das sollte sich beheben lassen, mit einem _WinAPI_DeleteDC($hDC), einzufügen in Zeile #718.

    Vielleicht kannst du mal ausgiebig testen, ob es jetzt rund läuft.

    Ich hatte noch als Idee, die Funktionen _GuiCtrlBusy_RegisterSingleClick($hWnd, "function") und _GuiCtrlBusy_RegisterDoubleClick($hWnd, "function") zu erstellen, die dann entsprechend Klick/Doppelklick auf das Control auswerten. Wäre das interessant/nützlich/sinnvoll?

  • Ja dann werde ich mal testen gehen, ist sicher sinnvoller als sich mit Controlclick zu beschäftigen, Hatte erst kürzlich

    wieder so ein Amokläuferscript gehabt das hunderte Instanzen eines Programms geöffnet hatte und den Rechner längere Zeit

    lahmgelegt hat(trotzt der Sicherheitsvorkehrungen, ich hasse Controlclick).

    Ich hoffe dein Script verhält sich freundlicher beim Abstürzen, falls es soweit kommt). Zum Klick auswerten habe ich gemischte

    Gefühle wofür es gut sein könnte. Beim Debugging eventuell als eine Art Bestätigung, daß der Tip gelesen wurde.

    Ich würde dafür vermutlich eher die Timer nutzen, aber ich sehe auch nicht alle Möglichkeiten voraus.

    Was ich gut finde ist, daß die Tooltips verschiebbar sind.

    Würde sich das nicht mit der Klickauswertung überkreuzen.

    Ich würde mal sagen wenn es leicht und ohne zusätzliche Fehlerquellen einbaubar ist, dann baue es mit rein sonst lasse es weg.

    Ich würde die Klickauswertung zu Gunsten eines schlanken Codes nicht einbauen, eine Lesebestätigung kann man sich

    auch gut auf die selbe art bauen die du mir selbst für mein Smartclip empfohlen hast. Mit einer Mausbewegung auf dem jeweiligen

    Tooltip kann der enstsprechende Tooltip quasi als gelsen markiert und entfernt werden. Braucht es wirklich mehr ???

    Ich hätte dann gerne eine Spezial-Version ohne Klickauswertung von Dir.

    Ich melde mich wenn Fehler auftreten

    Tuxedo

  • Und Fehler schon aufgetreten nach etwa 5 Minuten auf einem Rechner mit Windows 7 64 bit mit 8 GB Ram.

    Speicherauslastung im Taskmanager war bei ca 16 MB .

    Alle Tooltips wurden weiss oder grau und das Falschzeichnen hat sich auch auf den Taskmanager ausgedehnt,

    der Fehler wirkt sich scheinbar auf alle aktiven Fenster aus oder zumindest auf mehrere Fenster.

    Dein Script braucht doch hoffentlich keine Adminrechte oder sonstige besondere Berechtigungen?

    Solche Rechte haben bei mir nur sehr wenige Programme, ich habe auch dem Browser die angeforderten Adminrechte entzogen.

    Habe dadurch vielleicht ein paar kleinere Einschränkungen, aber damit kann ich leben.

    Aber es gibt leider Programme die mit solchen Einschränkungen gar nicht klarkommen, gehört deines dazu?

  • Ich habe jetzt einige Versuche laufen gelassen, und im Beispiel-Script alle Befehle auskommentiert oder umgeschrieben die

    Veränderungen an den angezeigten Tooltips vornehmen. Dadurch lässt sich der Fehler verzögern, aber er tritt immer

    noch auf.

    Der Fehler wird wohl durch Änderungen am angezeigten Bildschirminhalt verursacht. Umso mehr sich verändert

    umso schneller tritt der Fehler ein, im Moment bei mir in ca 45 Minuten.

    Zu Anfang mit den Timergesteuerten Tooltips und der angezeigten Zeit in den Tips 5+6+7+8 waren es etwa 5 Minnuten.

    Sobald der Fehler eintritt wird auch in anderen Fenstern fehlerhaft gezeichnet, bis die Script-GUI beendet wird.

    Ich hoffe das hilft dir schonmal weiter.

    • Offizieller Beitrag

    OK, Danke erst mal fürs Probieren.

    Ich habe eine Vermutung:

    Beim Erstellen der Control verhindere ich das Kollidieren der Callbackaufrufe durch ein kleines Sleep. Aber irgendwann wird wohl in Summierung der Differenzzeiten eine Kollision unausweichlich und während eine Callbackprozedur gerade abgearbeitet wird, grätscht schon der nächste Aufruf rein. Nun muss ich mal sehen, wie da am besten eine "Warteschlange" hinbekomme.

  • Hab grad noch einen Testdurchlauf beendet nach knapp 45 Minuten dann wieder alles weiss.

    Ist das was du vermutest, so ein Fehler der auch auftritt wenn z.B. eine Funktion nicht sauber beendet wird und irgendwann das Limit

    für Funktionsaufrufe von Autoit erreicht oder überschritten wird, das wäre nämlich momentan eine Vermutung von mir.

    Na dann hoffe ich du findest den Übeltäterdenn diese UDF wäre sehr wertvoll.

    Es grüsst Tuxedo

  • Hi,

    Hier hast du ein _WinAPI_DeleteObject() vergessen:

    AutoIt
    Local $hFont = _WinAPI_CreateFont(16, 0, 0, 0, 600, False, False, False, $DEFAULT_CHARSET, _
                $OUT_DEFAULT_PRECIS, $CLIP_DEFAULT_PRECIS, $DEFAULT_QUALITY, 0, 'Microsoft Sans Serif')
    Code
    $hFont = _WinAPI_CreateFont(19, 0, 0, 0, 400, False, False, False, $DEFAULT_CHARSET, _
                $OUT_DEFAULT_PRECIS, $CLIP_DEFAULT_PRECIS, $DEFAULT_QUALITY, 0, 'Microsoft Sans Serif')

    Du erstellst zweimal mal $hFont, löscht es aber nur einmal.

    €: Löst aber nicht das Problem mit der Darstellung.

    mfg

    Zeitriss

  • Tut mir Leid Zeitriss, samt dem ersten Bugfix von BugFix und deiner Korrektur beides in der UDF eingefügt und

    sobald sich das erste Tooltip-Fenster bei Timerende verabschiedet steigt das Script bei mir folgendem Fehler aus

    !>16:29:56 AutoIt3.exe ended.rc:-1073741819
    +>16:29:56 AutoIt3Wrapper Finished.
    >Exit code: 3221225477 Time: 37.82

    Ich warte dann mal auf den Umbau von BugFix und vertraue darauf daß es besser wird.

  • deiner Korrektur

    Welcher Korrektur?:P

    Ich habe nur auf eine Stelle verwiesen die ich für Falsch halte.

    So müsste man das Memory-Problem Lösen können:

    AutoIt
    _WinAPI_DeleteObject(_WinAPI_SelectObject($hDestDC, $hFont))

    oder eben:

    Code
    Local $hTempFont = _WinAPI_SelectObject($hDestDC, $hFont)
    ...
       _WinAPI_DeleteObject($hTempFont)

    Dies dürfte eigentlich zu keinem Fehler führen.

    Edit: Sinnvoller wäre es warscheinlich $hFont in $hFontTitle bzw $hFontText (oder ähnlich) umzubenennen.

    Hift aber wie gesagt nicht bei dem eigentlichem Problem.

    PS:

    [EDIT] ACHTUNG: Möglichen Fehler entdeckt. Bitte

    _WinAPI_DeleteDC($hDC)

    einfügen in Zeile #718.

    Sollte das nicht _WinAPI_ReleaseDC($hWnd, $hDC) sein?

    After painting with a common device context, the _WinAPI_ReleaseDC() function must be called to release the DC


    ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

    BugFix , Tuxedo

    So scheint der Grafikfehler nicht mehr aufzutreten.

    GuiCtrlBusy.au3

    mfg

    Zeitriss

    6 Mal editiert, zuletzt von Zeitriss (28. September 2017 um 18:22)

  • Hallo Bugfix, ich bin leider noch nicht zufrieden, wenn ich das Beispiel über den Dateiexplorer starte läuft es fehlerfrei etwa 1 Stunde und dann werden ja beabsichtigt alle Tooltips geschlossen, das klappt ja soweit.

    Aber wenn ich das Beispiel über Scite starten will, läuft es nur bis der erste Tooltip geschlossen wird und dann folgt ein

    Absturz mit folgenden Exitcodes

    !>00:04:45 AutoIt3.exe ended.rc:-1073741819
    +>00:04:45 AutoIt3Wrapper Finished.
    >Exit code: 3221225477 Time: 36.56

    Das passiert immer und immer wieder genau auf dieselbe art.

    Leider ist mein Englisch arg eingeschränkt, aber wenn ich das richtig interpretiere, passiert das gerne dann wenn

    ein String auf die falsche Art auf Null gesetzt werden soll( und verursacht dann angeblich ein Memory Leak).

    Könnte das in deiner UDF irgendwie noch der Fall sein.

    Würdest du dich der Sache nochmal annehmen bitte.

    Schönen Abend Tuxedo

    • Offizieller Beitrag

    Tuxedo Das kann ich nicht reproduzieren. Das Verhalten ist bei mir identisch, egal ob kompiliert oder als Run in SciTE. Ich verwende die SciTE Version 3.4.4 und AutoIt Stable 3.3.14.2

    Bei mir läuft Win 7 Pro x64.

    So wie du es beschreibst, verursacht _Timer_KillTimer() diesen Crash.

    Ich habe mal in den Tickets gesucht und #3513 dazu gefunden, geht hier um _Timer_KillAllTimers(), sollte aber vergleichbar sein.

    Kernaussage:

    - Wenn _Timer_KillAllTimers() mit AutoIt 64bit in SciTE4AutoIt genutzt wird, kommt es zum Crash

    - Mit AutoIt 32bit in SciTE4AutoIt tritt der Fehler nicht auf

    - Ebenso nicht mit der Lite-Version von SciTE

    - Mit der AutoItversion (3.3.12.0) war dieses Verhalten auch nicht vorhanden

    Aber wenn ich deine Fehlermeldung betrachte, wird nicht die 64bit Version von AutoIt gestartet. Insofern ist das dann wohl nicht in der Form relevant. Wobei ich aber als "Übeltäter" eindeutig _Timer_KillTimer() sehe. Vom Ablauf her ist das die einzige Möglichkeit zum Crash.

  • Danke, deine Tips hier sind goldrichtig, habe schon wieder sehr lange und viel getestet und bin dabei schon darüber gestolpert,

    daß das Beispiel nicht abstürzt wenn man den Befehl #AutoIt3Wrapper_UseX64=N verwendet.

    Und das ist ja das merkwürdige, beide Starts erfolgten mit der au3 Datei, eben einmal per File-Explorer(Doppelklick auf die au3)

    und dann einmal per Scite F5 und dabei stürzt das Script ab sobald der erste Tooltip geschlossen wird.

    Ich habe zu keiner Zeit ein Script kompiliert nur die AU3 verwendet.

    Dann müsste also Scite eine Unverträglichkeit mit _Timer_KillTimer() unter 64 bit haben.

    Ich habe Autoit 3.3.14.2 Win 7 pro 64 bit und Scite v3.7.3 verwendet

    Achja unter Autoit 3.3.12.0 Win 7 pro 64 bit und Scite v3.4.4.0 trat übrigens der selbe Fehler auf wenn es als

    64 bit ausgeführt wird(was bei Win 7 x64 ja autmatisch geschieht).

    Ich bin erst gestern aufgrund des Fehlers umgestiegen und durfte mich da weiter ärgern bis ich eher zufällig mal als

    32 bit Version gestartet habe und dann gings plötzlich.

    Schon krass, daß es rund 10 Jahre nach Start der Windows 64 bit Ära (WindowsXP 64 bit war wohl eher ne Beta-Version) immer

    noch Probleme mit 64 bit Programmen gibt.

    Der Ärger hört wohl nie auf was?

    Dann kann ich mich jetzt ja daran machen deine UDF besser kennenzulernen und für meine Zwecke zu nutzen.

    Dank BugFix für diese schöne brauchbare UDF

    Tuxedo

  • Es wäre sehr schön, wenn man die Textausrichtung ($iAlign = 0|1|2 - left|right|centered) mit angeben könnte. Noch schöner wäre es, wenn man links neben dem Text noch ein Icon platzieren könnte. ;)

    Ich hatte noch als Idee, die Funktionen _GuiCtrlBusy_RegisterSingleClick($hWnd, "function") und _GuiCtrlBusy_RegisterDoubleClick($hWnd, "function") zu erstellen, die dann entsprechend Klick/Doppelklick auf das Control auswerten. Wäre das interessant/nützlich/sinnvoll?

    Unbedingt!

    Oder ginge das auch so: _GuiCtrlBusy_RegisterMessage($hWnd, $WM_LBUTTONDBLCLK, "function"') und _GuiCtrlBusy_RegisterMessage($hWnd, $WM_CLOSE, "function"')

    • Offizieller Beitrag

    Oder ginge das auch so: _GuiCtrlBusy_RegisterMessage($hWnd, $WM_LBUTTONDBLCLK, "function"') und _GuiCtrlBusy_RegisterMessage($hWnd, $WM_CLOSE, "function"')

    Dafür benötigt man eigentlich keine zusätzlichen Funktionen.

    Die Funktion "_GuiCtrlBusy_Create()" gibt doch das Handle des Fensters zurück. Damit kannst Du in Deinem Script mit GUISetOnEvent (OnEventMode) oder mit einer entsprechenden Case-Anweisung (Msg-Loop-Modus) auf linken oder rechten Mausklick und/oder auf das Schließen des Fensters reagieren.

    • Offizieller Beitrag

    wenn man die Textausrichtung ($iAlign = 0|1|2 - left|right|centered) mit angeben könnte.

    Das ist machbar, werde ich aber nicht als Parameter für die Erstellung integrieren, sondern dann als Zusatzfunktion _SetAlign().

    wenn man links neben dem Text noch ein Icon platzieren könnte.

    Grundsätzlich ist alles machbar, was man mit einem Fenster machen kann. Jedoch würde ich mir das dann für später aufheben, weil ich dann die Größenkalkulation verändern muss. Wobei ich das Icon nicht neben den Text, sondern top links neben dem Titel platzieren würde.

    Dafür benötigt man eigentlich keine zusätzlichen Funktionen.

    Stimmt natürlich, ich hätte die Events auch nur gecastet - aber das wäre overdressed. ;)

    Ich mache jetzt erst mal die fehlerbereinigte Version fertig, in der auch alle Parameteränderungen zur Laufzeit funktionieren (momentan noch nicht kpl.). Dann werde ich mich den Wünschen widmen.