Sign in to follow this  
Followers 0
sigmason

OnEvent PRIMARYDOWN missing event.

18 posts in this topic

#1 ·  Posted (edited)

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 by sigmason

Share this post


Link to post
Share on other sites



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.

Share this post


Link to post
Share on other sites

#3 ·  Posted (edited)

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 by Melba23

Any of my own code posted anywhere on the forum is available for use by others without any restriction of any kind._______My UDFs:

Spoiler

ArrayMultiColSort ---- Sort arrays on multiple columns
ChooseFileFolder ---- Single and multiple selections from specified path treeview listing
Date_Time_Convert -- Easily convert date/time formats, including the language used
ExtMsgBox --------- A highly customisable replacement for MsgBox
GUIExtender -------- Extend and retract multiple sections within a GUI
GUIFrame ---------- Subdivide GUIs into many adjustable frames
GUIListViewEx ------- Insert, delete, move, drag, sort, edit and colour ListView items
GUITreeViewEx ------ Check/clear parent and child checkboxes in a TreeView
Marquee ----------- Scrolling tickertape GUIs
NoFocusLines ------- Remove the dotted focus lines from buttons, sliders, radios and checkboxes
Notify ------------- Small notifications on the edge of the display
Scrollbars ----------Automatically sized scrollbars with a single command
StringSize ---------- Automatically size controls to fit text
Toast -------------- Small GUIs which pop out of the notification area

 

Share this post


Link to post
Share on other sites

@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

Share this post


Link to post
Share on other sites

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


Any of my own code posted anywhere on the forum is available for use by others without any restriction of any kind._______My UDFs:

Spoiler

ArrayMultiColSort ---- Sort arrays on multiple columns
ChooseFileFolder ---- Single and multiple selections from specified path treeview listing
Date_Time_Convert -- Easily convert date/time formats, including the language used
ExtMsgBox --------- A highly customisable replacement for MsgBox
GUIExtender -------- Extend and retract multiple sections within a GUI
GUIFrame ---------- Subdivide GUIs into many adjustable frames
GUIListViewEx ------- Insert, delete, move, drag, sort, edit and colour ListView items
GUITreeViewEx ------ Check/clear parent and child checkboxes in a TreeView
Marquee ----------- Scrolling tickertape GUIs
NoFocusLines ------- Remove the dotted focus lines from buttons, sliders, radios and checkboxes
Notify ------------- Small notifications on the edge of the display
Scrollbars ----------Automatically sized scrollbars with a single command
StringSize ---------- Automatically size controls to fit text
Toast -------------- Small GUIs which pop out of the notification area

 

Share this post


Link to post
Share on other sites

Try a guiregister and see you if you get better results

GUIRegisterMsg(0x0201,"leftmouse") ;WM_LBUTTONDOWN

Share this post


Link to post
Share on other sites

#7 ·  Posted (edited)

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 by sigmason

Share this post


Link to post
Share on other sites

#9 ·  Posted (edited)

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 by sigmason

Share this post


Link to post
Share on other sites

#10 ·  Posted (edited)

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 by sigmason

Share this post


Link to post
Share on other sites

#12 ·  Posted (edited)

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 by sigmason

Share this post


Link to post
Share on other sites

#13 ·  Posted (edited)

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 by sigmason

Share this post


Link to post
Share on other sites

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.


The Wheel of Time turns, and Ages come and pass, leaving memories that become legend. Legend fades to myth, and even myth is long forgotten when the Age that gave it birth comes again.

Share this post


Link to post
Share on other sites

#15 ·  Posted (edited)

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 by sigmason

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

#17 ·  Posted (edited)

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 by sigmason

Share this post


Link to post
Share on other sites

#18 ·  Posted (edited)

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 by sigmason

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0