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

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

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

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

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

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

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

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

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

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

Yes but like the library, if your not looking for the right things you'll quickly reduce the chances you'll find it. I've bookmarked that link now. I tried a few dozen variations before I posted, in and out of the forums and more then just a casual hunt and apparently I just never hit the right combination (probably because most of my searches were like "autoit udf documentation" and the like). Without hunting with Google do you know how that page is linked by navigating into the site from the home page? It's really very valuable and I'd like to hope it's linked some place quite apparently and I'm just blind. Thanks very much, Sigmason

Thanks, but there's nothing on the Internet I'm missing right? This is of great help unless I happen to be wondering about something while on the go. With so many powerful functions like this people should have neon signs up . Sigmason

I've been using AutoIt a long time. I don't mind some change but since Auto3Lib has been dropped I find myself often chasing equivalent functions through various UDF and my own code. Part of the problem is pretty simply IMHO: While the documentation for AutoIT is thorough, it does not include the UDFs included by default so far as I can see. Am I missing something in this regard? Is there a wiki or document somewhere I've missed that documents the default available includes? Sigmason

I was looking at GDI+ earlier for saving B/W TIFF CCITT3 images and I suspect, based on playing with it, that if the intent is to reduce the color depth, especially to B/W you must first create a buffer, then reduce the depth by moving the pixels to the buffer with the indexed 1BPP property, and then feed that to the encoder. (All of which has more to do with the code you are using then what you are doing calling it.) It appears that the encoders do not provide for the color depth reduction and in some ways that sort of makes sense. Especially with B/W conversions, it is fairly probable that there are many ways to approach the process and that it could be included in a separate function in GDI+ (though it is apparently not, so it is left to the outside programmer). For further reference (respects granted to the linked parties and their efforts): http://www.codeguru.com/forum/archive/index.php/t-194793.html Sigmason

I confirmed today that in fact the package I installed AutoIt3 from had in fact changed versions between the time I installed and created the script on one PC and tested it on the Windows 98 PC. Thanks for all your quick responses, I ended up downgrading to the last package for AutoIt3, since my code was written and working in that..I have little need to address the unrelated issues of the update. That and I'm lazy