Does GUIGetCursorInfo gobble-up mouse-events ?

[BitRot]

Hello all,

I'm attempting to use the GUIGetCursorInfo function, and have a bit of a hard time : no matter if I use it with a GUI in polled loop or in Event-driven mode, it seems that I'm missing mouse-events. Sometimes down, and sometimes up.

Am I missing something (besides the mouse-clicks ), or is the function really troublesome in this regard.

Another problem with the same function : it seems to be having problems in detecting a combo-box : most of the combo-box area simply returns a Zero as the control-ID (nothing found), even if another control is placed underneath it.

Any insights please.

Edited September 28, 2006 by BitRot

[martin]

Could you give us some code which shows the problems? Otherwise insights are difficult.

[BitRot]

Could you give us some code which shows the problems? Otherwise insights are difficult.

Just the basic message-loop with the GuiGetCursorInfo -function thrown in will do nicely :

#include <GUIConstants.au3>

GUICreate("My GUI")
GUISetState (@SW_SHOW)
do
    $msg = GUIGetMsg()
    if $msg<>0 and $msg<>-11 then ConsoleWrite("$msg : "&$msg&@crlf)
    $Mouse=GUIGetCursorInfo()   ;comment this line out to see all mouse-events again
    
until $msg=$GUI_EVENT_CLOSE

Just press the mouse-buttons, and notice sometimes nothing being written to the console-window (for the left mouse-button allways pairs of -7 (press) and -8 (release) should appear).

[martin]

Just the basic message-loop with the GuiGetCursorInfo -function thrown in will do nicely :

#include <GUIConstants.au3>

GUICreate("My GUI")
GUISetState (@SW_SHOW)
do
    $msg = GUIGetMsg()
    if $msg<>0 and $msg<>-11 then ConsoleWrite("$msg : "&$msg&@crlf)
    $Mouse=GUIGetCursorInfo()   ;comment this line out to see all mouse-events again
    
until $msg=$GUI_EVENT_CLOSE

Just press the mouse-buttons, and notice sometimes nothing being written to the console-window (for the left mouse-button allways pairs of -7 (press) and -8 (release) should appear).

Using events works-

#include <GUIConstants.au3>
Opt("GUIOnEventMode", 1)
GUICreate("My GUI")
GUISetState (@SW_SHOW)
GUISetOnEvent($GUI_EVENT_PRIMARYDOWN,'DOWN')
GUISetOnEvent($GUI_EVENT_PRIMARYUP,'UP')
GUISetOnEvent($GUI_EVENT_CLOSE, 'CLOSE')

while 1
WEnd

func DOWN()
     ConsoleWrite('button down')
 EndFunc
 
 func Up()
    ConsoleWrite('button up' & @crlf)
 EndFunc 
Func Close()
    Exit
EndFunc

The message loop way only gets the message every time the loop is executed so it can miss events I think.

The on event method will still not detect mouse down if it is over a control so you would have to

check for this.

[BitRot]

The on event method will still not detect mouse down if it is over a control so you would have to check for this.

Yes, and when you do that (using that "GUIGetCursorInfo()" function) you will again loose mouse-clicks.

[SmOke_N]

Yes, and when you do that (using that "GUIGetCursorInfo()" function) you will again loose mouse-clicks.

Captures them for me (If I click alot). I think the delay for GUIGetCursorInfo() might be the issue you are having capturing them all.

If you need the clicks, then try GUIRegisterMsg(), maybe that will help the delay in GUIGetCursorInfo().

[martin]

If you get the coordinate information and the button state each time you call GuiGetCursorInfo then I think you won't have a problem with loosing clicks. Doesn't this do what you want?

expandcollapse popup

#include <GUIConstants.au3>
Opt("GUIOnEventMode", 0)
$MGUI = GUICreate("My GUI")
GUISetState (@SW_SHOW)
$coords = GUICtrlCreateLabel('x = ..',50,10,100,12)
$state = GUICtrlCreateLabel('o',50,22)
$mdown = 0
$nc=0

While 1
   $mouse = GUIGetCursorInfo($MGUI)
   if $mouse[2] <> $mdown Then
       $mdown = $mouse[2]
       switch $mdown
        case 0
            ConsoleWrite(', up' & @crlf)
        case 1
            $nc = $nc + 1;
            GUICtrlSetData($state,$nc)
           ConsoleWrite('down')
       EndSwitch
   EndIf
   
       
   GUICtrlSetData($coords,'X = ' & $mouse[0] & ' Y = ' & $mouse[1])
   if $mdown Then
       GUICtrlSetPos($state,$mouse[0]-3,$mouse[1] - 9)
       EndIf
   $msg = GUIGetMsg()
   
   Switch $msg
       Case $GUI_EVENT_CLOSE
         Exit
        Case Else
        
   EndSwitch
WEnd

Edited September 29, 2006 by martin

[BitRot]

Captures them for me (If I click alot).

You mean to say that they sometimes come thru (in other words : you can't depend on it) ?

I think the delay for GUIGetCursorInfo() might be the issue you are having capturing them all.

Possible. But if that is the cause, can I modify that delay back to Zero (I did not see it mentioned in the Help) ?

If you need the clicks, then try GUIRegisterMsg(), maybe that will help the delay in GUIGetCursorInfo().

I didn't think of that method yet, I'll test it within shortly. Thanks for the suggestion

[martin]

BitRot,

Can you let me know what happens if you try the code I posted (#7) so I can understand the probelm.

[BitRot]

If you get the coordinate information and the button state each time you call GuiGetCursorInfo then I think you won't have a problem with loosing clicks. Doesn't this do what you want?

<snip code>

Yes, it would. Its allso pretty-much what I currently have (which is why I know it would ).

But don't you think its quite "stupid" to have to write a "pressed" and "released" capturing yourself, when much more elegant methods (either the GUIGetMsg or GUISetOnEvent methods) are supposedly available ?

Actually, that was what my origional question was aimed at : checking if this (mal-)behaviour is known, and if there is a simple solution for it, preferrably forcing the command to behave itself.

Alas, no such simple solution seems to be existing, and only work-arounds that result in the need to fully re-write the whole code seem to be available (although "SmOke_N"-s suggestion looks to be promising)

Maybe I should submit this interference of this command with the basic message-loop as a bug.

Hmmm ... Just thought of it : maybe I should try to go the DLL-way, and see what "ChildWindowFromPoint " can do for me

[martin]

Yes, it would. Its allso pretty-much what I currently have (which is why I know it would ).

But don't you think its quite "stupid" to have to write a "pressed" and "released" capturing yourself, when much more elegant methods (either the GUIGetMsg or GUISetOnEvent methods) are supposedly available ?

Actually, that was what my origional question was aimed at : checking if this (mal-)behaviour is known, and if there is a simple solution for it, preferrably forcing the command to behave itself.

Alas, no such simple solution seems to be existing, and only work-arounds that result in the need to fully re-write the whole code seem to be available (although "SmOke_N"-s suggestion looks to be promising)

Maybe I should submit this interference of this command with the basic message-loop as a bug.

Hmmm ... Just thought of it : maybe I should try to go the DLL-way, and see what "ChildWindowFromPoint " can do for me

I don't fuly understand your answer. By using GUIGetCursorInfo you aren'y writing capturing yourself but if you use on events then you would have to. I don't think there is any "interference" with the message loop, only an incorrect use of a function.

I don't think the problem you describe is a bug.

Edited September 29, 2006 by martin

[BitRot]

I don't think there is any "interference" with the message loop, only an incorrect use of a function.

Than please tell me why those mouse-events are disappearing when using that GUIGetCursorInfo command, making it impossible to create a program that relies upon receiving them ?

I don't think the problem you describe is a bug.

I could possibly believe you if you can answer the above question

[martin]

Than please tell me why those mouse-events are disappearing when using that GUIGetCursorInfo command, making it impossible to create a program that relies upon receiving them ?

I could possibly believe you if you can answer the above question

The mouse events are not disappearing, they are being dealt with by GUIGetCursorInfo so your example doesn't work.

The code that you don't want to try shows that it's not impossible.

If you use GUIGetCursorInfo then you need to use it for the position and the state of the mouse button and not try and use GuiGetMsg to look for an event that's already been dealt with.

Here is your code

#include <GUIConstants.au3>

GUICreate("My GUI")

GUISetState (@SW_SHOW)

do

$msg = GUIGetMsg() ;<---AAA

if $msg<>0 and $msg<>-11 then ConsoleWrite("$msg : "&$msg&@crlf)

$Mouse=GUIGetCursorInfo() ;<---BBB

until $msg=$GUI_EVENT_CLOSE

[\code]

There is a time between executing AAA and BBB. Any mouse click which occurs in this time will be seen by

GUIGEtCursorInfo and removed from the messages.

Then there is a smaller delay between BBB and AAA. If a click occurs in this time period then $msg will show it, but it is likely to get only a few, and the more code that exists between AAA and BBB the lower the chance of seeing a click with GUIGetMsg.

That's why my code works.

[BitRot]

The mouse events are not disappearing, they are being dealt with by GUIGetCursorInfo so your example doesn't work.

I'm sorry, but was that ("they are being dealt with by GUIGetCursorInfo" and therefore not available to the "standard" methods) not pretty-much what I was inquiring about ?

[edit]

Look at it this way : You've got a perfectly-allright running car, to which you decide to attach a car-company created-and-provided draw-hook to (to pull some sort of trailer). But whenever you do that your car somehow sometimes refuses to either accelerate or brake.

When you reclamate about it (this non-mentioned side-effect with high impact to the reliability of your car) they just tell you to replace your whole engine with another, more klunky one (and like it).

Would you think that is acceptable ? Well, neither do I.

Funnily when you decide to create and install your own draw-hook you acceleration and breaking paddles work like a charm again ....

Edited September 30, 2006 by BitRot

[martin]

I'm sorry, but was that ("they are being dealt with by GUIGetCursorInfo" and therefore not available to the "standard" methods) not pretty-much what I was inquiring about ?

[edit]

Look at it this way : You've got a perfectly-allright running car, to which you decide to attach a car-company created-and-provided draw-hook to (to pull some sort of trailer). But whenever you do that your car somehow sometimes refuses to either accelerate or brake.

When you reclamate about it (this non-mentioned side-effect with high impact to the reliability of your car) they just tell you to replace your whole engine with another, more klunky one (and like it).

Would you think that is acceptable ? Well, neither do I.

Funnily when you decide to create and install your own draw-hook you acceleration and breaking paddles work like a charm again ....

I'm very impressed that you are able to get replies to this forum so quickly from the planet you live on.

[BitRot]

I'm very impressed that you are able to get replies to this forum so quickly from the planet you live on.

Well, with your "a problem does not exist if you can work around it" attitude I'm actually glad that I do not live on your planet.

I would not want you to be the person who comes into my home to repair anything, let alone having you for a physician. Yikes ! I would than probably be worse off after, than before.

By the way, did you actually understand that car-comparision I made ? Somehow I don't think so, otherwise you response would have been different. Ofcourse, there is a chance you did understand .....

[BitRot]

As nobody seems to have an explanation (let alone solution) to why GUIGetCursorInfo exhibits this gobble-up behaviour I've posted the problem as a Bug-report.