Problem mit dem Edit-Control

Hi BigRox 👋 ,

kannst du bitte nochmal genau beschreiben, wie das erwartete Verhalten sein soll und was du danach machen willst?
Denn vielleicht gibt es andere Wege deine Zielsetzung zu bewältigen.

Viele Grüße
Sven

Moin,

hier (Win 10 - AutoIt 3.3.16.1) zeigt sich exakt das beschriebene Verhalten:

Beim ersten Klick auf den Button bleiben die Ränder des Edits als weiße Linien im Label sichtbar. Wenn ich das Edit vorher disable, braucht es ein Sleep() von mindestens 140 ms, damit die Ränder nicht mehr durchschlagen. Für mich läuft da etwas mit stark angezogener Handbremse.

#include-once
#include <GUIConstants.au3>
#include <WindowsConstants.au3>

Opt("MustDeclareVars", 1)

Global $idBtn_Anzeigen, $idEdiText, $hGUI_Hauptfenster, $GUI_Msg, $idLbl_Wartehinweis

; Das Fenster des GUI erstellen.
$hGUI_Hauptfenster = GUICreate("TEST TEST TEST", 830, 185, -1, -1)
GUISetBkColor(0x3680FF)


; Das Textfenster (Edit-Control) erstellen.
$idEdiText = GUICtrlCreateEdit("", 30, 30, 768, 40, BitOR($ES_CENTER, $ES_MULTILINE))

; Das Label mit dem Wartehinweis erstellen.
$idLbl_Wartehinweis = GUICtrlCreateLabel("", 214, 23, 372, 89)
GUICtrlSetBkColor(-1, 0x707070)
GUICtrlSetState(-1, $GUI_HIDE)

$idBtn_Anzeigen = GUICtrlCreateButton("Label anzeigen.", 250, 128, 310, 40, BitOR($SS_CENTER, $BS_PUSHLIKE))
GUICtrlSetFont(-1, 12, 400, 0, "Tahoma")
GUICtrlSetBkColor(-1, 0x00FF00)


GUISetState(@SW_SHOW, $hGUI_Hauptfenster)

While 1
	$GUI_Msg = GUIGetMsg()
	Switch $GUI_Msg
		Case $GUI_EVENT_CLOSE     ; Symbol <Fenster schließen>
			GUIDelete($hGUI_Hauptfenster)
			ExitLoop

		Case $idBtn_Anzeigen     ; Button <Label anzeigen.>
			; Das Label für den Wartehinweis anzeigen.
			GUICtrlSetState($idEdiText, $GUI_DISABLE)
			Sleep(140)
			GUICtrlSetState($idLbl_Wartehinweis, $GUI_SHOW)
			;GUICtrlSetState($idEdiText, $GUI_HIDE)

	EndSwitch
WEnd
Exit

Die folgenden zwei Zeilen bringen eine Änderung, die ich glaube von dir BigRox gewünscht ist. Doch das weißt du am besten 😅 ?

• GUICtrlSetState($idBtn_Anzeigen, $GUI_FOCUS) nach dem Button erstellen
• GUICtrlSetState($idEdiText, $GUI_DISABLE) beim Klick auf Button
  
  

Danach wird das Edit Control nicht immer wieder in den Fokus gebracht.

Viele Grüße
Sven

Ich hab mal rumprobiert und konnte leider keinen Style,... finden, der das aendern koennte...

Ich vermute, die Balken sind initial da, weil das Event, mit dem der Fokus vom Edit genommen wird nach dem aktuellen "button klick event" (Case $idBtn_Anzeigen) ausgefuehrt wird und das fenster da schon neugezeichnet wird und danach erst der Fokus vom Edit genommen wird.

Ich konnte es loesen, indem ich das Edit disable ($GUI_DISABLE) und das ganze aus der aktuellen event loop rausnehme mit "AdlibRegister". Ich hoffe, das ist fuer dich eine akzeptable Loesung...

#include-once
#include <GUIConstants.au3>
#include <WindowsConstants.au3>
#include <WinAPIGdi.au3>

Opt("MustDeclareVars", 1)

Global $idBtn_Anzeigen, $idEdiText, $hGUI_Hauptfenster, $GUI_Msg, $idLbl_Wartehinweis

; Das Fenster des GUI erstellen.
$hGUI_Hauptfenster = GUICreate("TEST TEST TEST", 830, 185, -1, -1)
GUISetBkColor(0x3680FF)

; Das Textfenster (Edit-Control) erstellen.
$idEdiText = GUICtrlCreateEdit("", 30, 30, 768, 40, BitOR($ES_CENTER, $ES_MULTILINE))

$idBtn_Anzeigen = GUICtrlCreateButton("Label anzeigen.", 250, 128, 310, 40, BitOR($SS_CENTER, $BS_PUSHLIKE))
GUICtrlSetFont(-1, 12, 400, 0, "Tahoma")
GUICtrlSetBkColor(-1, 0x00FF00)

; Das Label mit dem Wartehinweis erstellen.
$idLbl_Wartehinweis = GUICtrlCreateLabel("", 214, 23, 372, 89)

GUICtrlSetBkColor(-1, 0x707070)
GUICtrlSetState(-1, $GUI_HIDE)

GUISetState(@SW_SHOW, $hGUI_Hauptfenster)

While 1
	$GUI_Msg = GUIGetMsg()
	Switch $GUI_Msg
		Case $GUI_EVENT_CLOSE ; Symbol <Fenster schließen>
			GUIDelete($hGUI_Hauptfenster)
			ExitLoop
		Case $idBtn_Anzeigen ; Button <Label anzeigen.>
			; Das Label für den Wartehinweis anzeigen.
			AdlibRegister("_disable")
	EndSwitch
WEnd

Func _disable()
	AdlibUnRegister("_disable")
	GUICtrlSetState($idEdiText, $GUI_DISABLE)
	GUICtrlSetState($idLbl_Wartehinweis, $GUI_SHOW)
EndFunc

Velted ja es scheint ein Zeitverhalten Problem zu sein, also manchmal ist ein Delay nötig manchmal nicht und an sich scheint es ein Bug in AutoIt an sich zu sein. Hatte mal kurz im englischen Forum gesucht und ähnliche Fragestellungen gefunden, allerdings alles alte Threads - keine Ahnung ob es bereits gefixed sein soll oder nicht 🤔 ?

BigRox also falls dies wirklich ein AutoIt Bug sein sollte, könntest du bspw. für dein Szenario SplashTextOn() und SplashOff() benutzen. Dann musst du gar nicht auf der GUI herumzeichnen 😅 . Ansonsten gibt es auch fertige "Spinner" (loading indicator) im englischen Forum und wahrscheinlich auch hier, die du einbinden kannst. Denn der Experte (einer der Experten, aber der Erste der mir sofort dazu einfällt) UEZ ist auch hier im Forum vertreten und hat mich Sicherheit so'n Spinner parat 🤞 .

Viele Grüße
Sven

Update: Kanashius das ist eine schöne Lösung 👍 .

ich vermute, nur weil das Control innerhalb von AutoIt das flag "DISABLED" erhält, ist der Befehl dazu im Windows noch lange nicht durch.

Ob das jetzt ein WinAPI Aufruf oder ein DLL-Call ist kann ich nicht sagen, aber der benötigt sicher auch seine Zeit um "zu wirken".

Das Verhalten, dass man den "realen" Status mit GuiCtrlGetStatus nicht auslesen kann, sondern immer nur den, den Autoit intern kennt,
mag an der "Wrapper-Architektur" liegen. Da werden die Befehle erstmal an den Wrapper von Autoit geschickt, der wiederrum schickt dass dann via DllCall an Windows und das setzt den Befehl dann um. Für AutoIt ist das nach 1 ms erledigt, aber für Windows dauert der Prozess einfach etwas länger.

Ich finde in AutoIt kann man solche "Probleme" ganz gut umschiffen, indem man in seiner grafischen Architektur darauf achtet, dass COntrols sich nicht überlappen. Das gab schon von je her Probleme. Ich denke dass das auch aufgrund der Verzögerungen in der Abarbeitung begründet liegt.

Kanashius,

auch mit dem AdlibRegister()läuft das hier nur dann stabil, wenn der time Parameter mit dem Defaultwert (250 ms) arbeitet oder auf mindestens 200 ms gesetzt wird. Im Jahre 2024 ist das für einen normalen Computer eine kleine Ewigkeit. Ich kann mir das nicht erklären und gehe mal von einem Bug aus.

PS: AdLibRegister hat einen Default von 250ms.
Damit erzeugt man im Besten Fall auch nur eine Pause, die das Control braucht um real deaktiviert zu sein

Auf der Suche nach 'künstlichen' Verzögerungen bin ich vorhin auf Folgendes gestoßen:

Zitat

Opt WinWaitDelay

Alters how long a script should briefly pause after a successful window-related operation.
Time in milliseconds to pause (default=250).

Das ist doch wohl auch nicht mehr ernst gemeint. Oder arbeiten mit AutoIt nur Menschen, deren Rechner ständig am Anschlag laufen?

Schnuffel,

ich beschäftige mich auch noch mit AHK. Ich kann Dir versichern, dass es nicht am Control liegt.

das waren nur meine 50cent zu dem Thema.
Ich möchte anderen nicht die Befähigung nehmen es besser zu wissen.