Help, anyone know how to solve notify() event bug?

BlitzMax Forums/MaxGUI Module/Help, anyone know how to solve notify() event bug?

skn3(Posted 2011) [#1]
See the following code:


Try selecting the textfield and then selecting the listbox. The textfield fires the LOSTFOCUS event and that is picked up in the hook. In the hook for LOSTFOCUS it will open a message box with Notify(). Once you close the message box you will see that the original mouse down actually registered on the listbox and you will have a "stuck" selection rect.

Any ideas how I can work around this?

Unfortunately I can't use a custom dialogue/window as this comes with its own maxgui issues.

Another option is adding ActivateGadget(textfield) after the notify but if you then try and select the textfield to edit the cursor has vanished!... plus it doesn't actually get rid of the the event bug...

Last edited 2011

Last edited 2011


skn3(Posted 2011) [#2]
Well after a few hours today looking into this it seems that it is bad practice to open/activate another window from within the WM_KILLFOCUS msg (the winapi message handled internally by maxgui).. so I guess I need to rethink my form..

It would still be good if anyone can think of a solution though?


H&K(Posted 2011) [#3]
COuld you not, store mouse coor, deal with notify, reposition mouse, post a Lft Click?


skn3(Posted 2011) [#4]
Hey H&K,

I had never though of that, but I don't know if it would solve the issue. The problem seems to be when maxgui wakes up after the blitz system module releases control from the notify window...


H&K(Posted 2011) [#5]
When I ran your code if looked like the GUI (After the notify) was returning from a click without an unclick, (Ie Click and hold/drag)

(It seemed the click kicked in, started the Lost focus, and didnt post the unclick to the GUI:- SO I figured restart the click sequence at the old Coors)


skn3(Posted 2011) [#6]
ooohhh interesting yeah that makes sense, I'll have a look at that. Thanks.