OnEvent PRIMARYDOWN missing event.

[sigmason]

I've noticed that quick presses of the mouse, which should fire the PRIMARYDOWN event in OnEvent mode, are sometimes missed.

Windows can obviously see these events because you can select other open windows via their title bars no problem.

However, unless you hold the mouse button down for a certain duration (very short duration) the event does not fire.

This can be replicated with a touch pad or mouse buttons on a laptop.

Can this effect be adjusted somehow, or can anyone explain the nature of the issue?

I've searched the forums, but again, the subject is too broad to narrow the results.

See this sample code:

#include <GUIConstantsEx.au3>
#include <WindowsConstants.au3>

Opt("GUIOnEventMode", 1)

; Prep UI.
Global $Form1 = GUICreate("OnEvent Test", @DesktopWidth / 2, @DesktopHeight / 2, -1, -1, $WS_OVERLAPPEDWINDOW)
GUISetState(@SW_SHOW)

GUISetOnEvent($GUI_EVENT_CLOSE, "CloseEvt")
GUISetOnEvent($GUI_EVENT_PRIMARYDOWN, "PriDwnEvt")
; End of prep UI.

; Start of main.
While 1
    Sleep (1000)
WEnd
; End of main.

Exit

Func CloseEvt()
  Exit
EndFunc

Func PriDwnEvt()
    MsgBox(0, "OnEvent", "PrimaryDown Intercepted!")
EndFunc

Sigmason

Edited November 1, 2009 by sigmason

[Authenticity]

It might be a problem with the device itself or the device driver. Theoretically, you can't press faster than it takes to register a mouse click. If the device it self cannot post such a gentle click of a mouse it's the device it self. I've tested it here and the system registers as fast as I can.

[Melba23]

sigmason,

Hello again!

Try reducing the Sleep(1000) to Sleep(10). The small pause is only there to enable you to have a tight loop and not eat up all the CPU cycles - GUIGetMsg() puts in a Sleep of about the same length automatically if you use GetMessage mode.

Sleep actually makes the whole script unresponsove - absolutely nothing happens at all while it runs. If you want a pause and still look for events (in either GUI mode) use some thing like this:

$iBegin = TimerInit()
While TimerDiff($iBegin) < $iDelay  ; Whatever length you need
; look for other things in GetMessage mode or enter a short Sleep(10) in OnEvent mode
WEnd

I hope everything is now clear.

Ignore the above - it is not true!

M23

Edited November 2, 2009 by Melba23

[Authenticity]

@Melba23, events are blocked only by other events not a sleep:

#include <GUIConstantsEx.au3>
#include <WindowsConstants.au3>

Opt("GUIOnEventMode", 1)

; Prep UI.
Global $iCounter = 0
Global $Form1 = GUICreate("OnEvent Test", @DesktopWidth / 2, @DesktopHeight / 2, -1, -1, $WS_OVERLAPPEDWINDOW)
GUISetState(@SW_SHOW)

GUISetOnEvent($GUI_EVENT_CLOSE, "CloseEvt")
GUISetOnEvent($GUI_EVENT_PRIMARYDOWN, "PriDwnEvt")
; End of prep UI.

; Start of main.
While 1
    Sleep (60000)
WEnd
; End of main.

Exit

Func CloseEvt()
  Exit
EndFunc

Func PriDwnEvt()
    $iCounter += 1
    ConsoleWrite("PrimaryDown Intercepted! " & $iCounter & @CRLF)
EndFunc

[Melba23]

Autenticity,

You learn something every day! I use OnEvent mode so rarely I was not aware of that and made an erronous assumption.

Thank you for pointing it out.

M23

[picea892]

Try a guiregister and see you if you get better results

GUIRegisterMsg(0x0201,"leftmouse") ;WM_LBUTTONDOWN

[sigmason]

Try a guiregister and see you if you get better results

GUIRegisterMsg(0x0201,"leftmouse") ;WM_LBUTTONDOWN

Interesting. The GUIRegisterMsg works just fine.

Also attaching an external AOpen USB mouse works just fine, the buttons in question are below the touch pad on this laptop.

The laptop is a Compaq V4000 laptop with an Alps Touch Pad assembly.

I've tried with the Microsoft driver (as installed by Windows XP SP3) and the HP/Compaq driver from their site.

I thought these commands worked relatively the same way, by registering the handler for the event in the Windows message handling chain. Is there some little difference internally that could account for the one working and the other not?

Here's the code I'm using with the suggested modification:

#include <GUIConstantsEx.au3>
#include <WindowsConstants.au3>

Opt("GUIOnEventMode", 1)

; Prep UI.
Global $Form1 = GUICreate("OnEvent Test", @DesktopWidth / 2, @DesktopHeight / 2, -1, -1, $WS_OVERLAPPEDWINDOW)
GUISetState(@SW_SHOW)

GUISetOnEvent($GUI_EVENT_CLOSE, "CloseEvt")
;GUISetOnEvent($GUI_EVENT_PRIMARYDOWN, "PriDwnEvt")
GUIRegisterMsg(0x0201,"PriDwnEvt") ;WM_LBUTTONDOWN

; End of prep UI.

; Start of main.
While 1
    Sleep (1000)
WEnd
; End of main.

Exit

Func CloseEvt()
  Exit
EndFunc

Func PriDwnEvt()
    MsgBox(0, "OnEvent", "PrimaryDown Intercepted!")
EndFunc

Sigmason

Edited November 2, 2009 by sigmason

[Yashied]

I am curious, the example that you presented in the first post does not work for you too?

[sigmason]

I am curious, the example that you presented in the first post does not work for you too?

Yes to be clear, the example I posted in the first post works, but if I am quick to press and release the touch pad buttons (mind you not the touchpad tap, I mean the physical buttons below the touch pad surface) on this laptop the event does not happen (as you can see there's no filter of the events, if it exerts, I should get a message box.) If I am deliberate (in other words slower) in my press of this same button the function operates as it should. It's all about how fast I can basically tap that left button, and if I'm quick I can reliably make it miss. I'd make a video of it, but the motions involved are so tiny it's probably a waste of time.

I know Windows is getting the event, even though AutoIt doesn't fire the function because like I said I can navigate away or in other programs without incident using the very same speed that will almost always get missed by the script. I even tried compiling and running the script, same problem. I tried shutting down all other software too, no difference.

However, as I just posted, registering the event (GUIRegisterMsg) DOES work no matter how fast I am about tapping that left button.

I'm running the latest version of AutoIT, installed yesterday, no previous versions floating around, this machine was formatted clean less than 2 weeks ago.

Sigmason

Edited November 2, 2009 by sigmason

[sigmason]

It's interesting that if you do tap on the touch pad, the original, unstable example never misses the event. It only happens with the touch pad's actual left button.

Also, if you flip the touch pad buttons (in other words, left button is right button and vice versa) you still have this issue with the first example.

Sigmason

Edited November 2, 2009 by sigmason

[Yashied]

On my touchpad it works fine.

[sigmason]

Okay on a Dell Dimension E521 with AMD Athlon X2 CPU, not a problem.

Dell Inspiron Mini 9, Atom CPU, not a problem.

Power supply or not, on the Compaq V4000, with reloaded OS, the touch pad left physical button fails to trip events when not using GUIRegisterMsg (in OnEvent mode).

It's just a question of how fast someone taps that button.

I would do this in message mode, but that's not nearly a real comparison.

Sigmason

Edited November 2, 2009 by sigmason

[sigmason]

I thought it might have something to do with the V4000 being an older Celeron P4 1.3GHz, but the Intel Atom is only 1.6GHz and with that flash drive in that Dell Mini 9 it is not exactly a speed demon.

Sigmason

Edited November 2, 2009 by sigmason

[Hawkwing]

Well, from a troubleshooting standpoint, how about we ask ourselves what's different between

GUISetOnEvent($GUI_EVENT_PRIMARYDOWN, "PriDwnEvt") and

GUIRegisterMsg(0x0201,"PriDwnEvt"). If one works and the other doesn't, and they both accomplish the same thing, then finding the difference would be the first thing to do.

[sigmason]

Additional information, I have a Dell Inspiron 8200 with an Alps Touch Pad and that also does not exhibit this behavior.

For giggles, I put the driver from the Dell (older) on the Compaq V4000, works but doesn't correct the issue.

I tried removing the older driver from the Dell, the Alps driver and then reinstalled the Compaq touch driver, still the same.

No changes, but even MS Paint responds correctly to the touch pad's left button.

So I agree with Hawkwing, what is the fundamental difference between the 2 lines in the later example?

I am now going to try one last thing and downgrade a few versions of AutoIt as a test.

Sigmason

Edited November 2, 2009 by sigmason

[sigmason]

Guess what?

Not an issue with AutoIt 3.2.6.0 from the previous versions download.

Now the question is not only what is the fundamental difference between GUIRegisterMsg and GUISetOnEvent.

Now the question is why does it work okay in 3.2.6.0 but not 3.3.0.0?

Sigmason

[sigmason]

Okay well the last production version that works right is:

3.2.10.0

Starting in version:

3.2.12.0

This problem exists on this hardware platform and it exists in 3.2.12.1 as well.

None of the changes listed in the history on the site seem to indicate a change in relevant sections.

Sigmason

Edited November 2, 2009 by sigmason

[sigmason]

The good news for me is that I don't actually need to fix this immediately.

For my immediate purpose the left button needs to be pressed and held for a good long time.

I'll check back here, and I have access to the effected hardware, if there are any more suggestions.

Besides GUIRegisterMsg does work, but it may have the disadvantage of not passing the handles and ID information that I would have gotten with the other call. Unfortunately, I may actually need that information. I'm going to have to think about that a bit.

I'm not sure I should report it as an error yet.

It would seem to be difficult to test.

Sigmason

Edited November 2, 2009 by sigmason