Modify

Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#3729 closed Bug (Wont Fix)

GUICtrlSetDefColor and GUICtrlSetDefBkColor cause inputs to fire other controls' events

Reported by: mainmaster@… Owned by:
Milestone: Component: AutoIt
Version: 3.3.14.5 Severity: None
Keywords: GUICtrlSetDefColor, GUICtrlSetDefBkColor, events Cc:

Description

Hi,
was trying to apply some styles to one of my programs and found this issue.

Basically, if you create a GUI and call GUICtrlSetDefColor() or GUICtrlSetDefBkColor(), any input created after a button will fire both its event and the (last focused) button's one.

Creating (!= placing) the input BEFORE the buttons seems to avoid the issue.

Tested on latest stable (v3.3.14.5) and latest beta (v3.3.15.1).

Attached is a simple script to reproduce the issue.
Tested both with an event-based approach and with a GUIGetMsg() one.

Regards
Enrico Boldori

Attachments (2)

AutoIt - GuiCtrlSetDefXXColor double event bug.au3 (1.5 KB) - added by Enrico Boldori <mainmaster@…> 5 years ago.
Reproduction script for the reported issue
AutoIt - Buttons background color issue.au3 (1.5 KB) - added by Enrico Boldori <mainmaster@…> 5 years ago.
Second reproduction script

Download all attachments as: .zip

Change History (6)

Changed 5 years ago by Enrico Boldori <mainmaster@…>

Reproduction script for the reported issue

Changed 5 years ago by Enrico Boldori <mainmaster@…>

Second reproduction script

comment:1 Changed 5 years ago by Enrico Boldori <mainmaster@…>

Update: the issue is actually related to the background color of a button.

I have attached a second example, please try the following:

  • Run the example, immediately click inside the input, change the text and press ENTER. A single event is fired
  • Cycle through the controls with the TAB button until the focus is again in the input field. Change the text and press ENTER again. Two events will be fired.
  • Try moving the call to GUICtrlSetBkColor() under the first button and notice the same behaviour.

comment:2 Changed 5 years ago by Enrico Boldori <mainmaster@…>

Second update: found an old closed issue (#376) for the same problem that was marked as Won't Fix without any real explanation or solution provided.

comment:3 Changed 5 years ago by Melba23

  • Resolution set to Wont Fix
  • Status changed from new to closed

I think the explanation given in that Trac response is quite clear - fixing the bug would require a complete rewrite of the GUI generation code of AutoIt and that is something which the Devs are not prepared to undertake.

So as suggested in the multitude of threads which have reported the same thing, do not colour buttons! We usually suggest using a slightly larger underlying disabled label and changing its colour as and when required.

M23

comment:4 Changed 5 years ago by Enrico Boldori <mainmaster@…>

In that case I'll leave here a possibile workaround for future reference.

; [...] GUI creation [...]
GUICtrlSetOnEvent($controlHandle, eventHandler)

; [...]

Func eventHandler()
    If GUICtrlGetHandle(@GUI_CtrlId) <> _WinAPI_GetFocus() Then Return

    ; Do the rest here
EndFunc

We must use GUICtrlGetHandle(@GUI_CtrlId) to get the handle because @GUI_CtrlHandle reports the wrong control handle, while @GUI_CtrlId refers to the correct control that generated the event.

Thanks for the quick reply

Guidelines for posting comments:

  • You cannot re-open a ticket but you may still leave a comment if you have additional information to add.
  • In-depth discussions should take place on the forum.

For more information see the full version of the ticket guidelines here.

Add Comment

Modify Ticket

Action
as closed The ticket will remain with no owner.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.