;There is one large drawback with this procedure,
;gadget enumeration MUST start with 1 and not at 0 as many tend to do,
;the reason is that 0 is returned on failure or if no mouseover/hover occurs.
;so enumerate your gadgets as 1, 2, 3, 4 etc.
Procedure.l EventHoverGadget()
Protected cursor.POINT,hndl.l
If GetCursorPos_(cursor.POINT)
hndl=WindowFromPoint_(cursor\x,cursor\y)
If hndl
hndl=GetDlgCtrlID_(hndl)
If hndl
ProcedureReturn hndl
EndIf
EndIf
EndIf
ProcedureReturn 0
EndProcedure
OpenWindow(1,0,0,400,100,#PB_Window_ScreenCentered|#PB_Window_SystemMenu,"MouseOver example")
CreateGadgetList(WindowID())
ButtonGadget(1,10,10,380,20,"Button 1") ;Please note that the first gadgetid start with 1
ButtonGadget(2,10,30,380,20,"Button 2")
hover=0
oldhover=hover
Repeat
event=WindowEvent()
Select event
Case #WM_MOUSEMOVE
hover=EventHoverGadget()
If hover<>oldhover
Select hover
Case 1 : SetGadgetText(1,"Hover")
Case 2 : SetGadgetText(2,"Hover")
EndSelect
Select oldhover
Case 1 : SetGadgetText(1,"Button 1")
Case 2 : SetGadgetText(2,"Button 2")
EndSelect
oldhover=hover
EndIf
EndSelect
Delay(1)
Until event = #PB_Event_CloseWindow
Now let's hope something similar appear in a future PB version
I decided to use 0, because that is also what the windows API returns.
(so why the windows API itself allow gadget enumerations of 0 is beyond me, as you can't tell a gadget 0 and error apart in this case)
If anyone know how to allow 0 gadget id's and retrn -1 instead by all means post and I'll update the first post.
But, don't try to complicate the code any more, the goal of this one vs the other examples and snippets on the forum was simplicity,
clean implementation, no callbacks, and an example that shows how to avoid the "flicker" in the program loop itself.
Is there any way to get this to work with TextGadget? Currently GetDlgCtrlID_ does not seem to register anything when hovering over a textgadget, or any gadget that is disabled for that matter...
Thanks Netmaestro! And as a follow-up, what would be the simplest/easiest/shortest way to detect a mouse click on a TextGadget, preferably *without* using a callback of any kind?
Just using the code above with the #WM_LBUTTONDOWN event instead of #WM_MOUSEMOVE reports clicks on ButtonGadgets correctly, but again, not TextGadget, even with #SS_Notify enabled.
Okay, that works... but it brings the compile/run time for my program from about three seconds, to about ONE FULL MINUTE, from the time I hit the compile/run button. Wow.
hndl=WindowFromPoint_(PeekQ(@cursor))
This brings it back to about the three second mark... why does the first one slow down compile time sooooooooooo dramatically?
srod wrote:No problems here. Not sure how this could possibly affect the compile time?
Me neither..? But then I readily admit that I know nothing about these things. However I've switched it back and forth several times now to test, and I can verify that it changes the compile time in my program from 3 to 60 seconds every time. On its own with nothing else it compiles fast.. only in my program does it slow the compile time.. even though nothing else in the program slows it down.. weird!!
Okay it's not that line specifically, it turns out. I'm having weird issues with compile time chaging based on any number of seemingly arbitrary things.
I commented an old CreateGadget() line because it's not needed anymore in PB 4.3, and THAT caused compile time to slow to a minute again. I uncommented the line and it went back to 3 seconds.
But if I save the file, close it and then re-open it again, compile time is 3 seconds no matter which lines I leave in which state. If at that point I change the WindowFromPoint_ line to the other version (whichever I wasn't using and had commented), it will change compile time to one minite again. Regardless of which way the switch happens. If I open the file with the "PeekQ" version active, and then change it to the "<<32" version, it slows compile time. Same happens if I open it with the "<<32" version and change to the "PeekQ" version.
But no matter what, if I save, close and re-open the file (just saving isn't enough) it slows down until I either revert the change, or close and re-open again.
It doesn't happen with just that EventHoverGadget() procedure alone, so I will have to methodically remove other bits of the code until I get down to which parts are involved in this. It's very odd.
I occasionally find that the IDE appears to hang having just completed compiling my code and before running the resulting exe. Really quite rare (happened once today amongst the three million and one compilations I have undertaken!) It will compile the code, get to the last line and then there is a long delay before proceeding; as if the IDE awaits some final signal from the compiler.
It is weird and happens very infrequently; too infrequent for me to have made any kind of fuss about it. Perhaps though it is related to whatever it is that is happening with your installation?
I may look like a mule, but I'm not a complete ass.
