Bruce,I have been following this conversation from the sideline. From your last statement, you say to wait to work with the stuff, till the key is UP. That makes sense well enough. But then, since you are not going to do anything until the key is released, why would you ever need connecting to the OnKeyDown? Wouldn't it be enough to connect to the OnKeyUp event? Maybe a silly question, but still an unclear point to me. Name me a dummy; smile.
----- Original Message ----- From: "BT" <[email protected]>
To: <[email protected]> Sent: Thursday, May 24, 2012 3:14 PM Subject: Re: KeyProcessedUp and KeyProcessedDown Events
Hi Rick, Yes, make sure you key is up before doing anything. Also, monitor the window status to actually not do anything until the status of that window changes. But, I still think you should never monitor just the key down event, always wait until that key is up. Unpredictable things can happen if you don't. In key events for Windoweyes they have stuff to disable the we part of the event, thus monitoring the key down event, in order to block keys. So, work with it after the key is back up. Bruce Sent: Thursday, May 24, 2012 8:46 AM Subject: Re: KeyProcessedUp and KeyProcessedDown Events Hi Guys: The actual key combo is: Shift-Escape and is a .net (vb.net) hot key toclose tool windows like Solution Explorer although it is never really closedonly "hidden".Actually it is a TabItem but that is neither here nor there for this problemme thinks. Problem: I open vb.net and a project then bring up Solution Explorer. I hit Shift-Escape and the screen goes dark and I should no longer be able to access the objects listed in Solution Explorer.This is the normal behavior. What I want: I want the screen to continue to go dark but I want WE to not continue having focus on the Hidden Solution Explorer. Right now WE keeps reading and processing Solution Explorer even after hitting Shift-Escape and the screen going dark (Solution Explorer is hidden). I checked as best I could for shift-escape in windoweyes dialog stuff anddid not see it there so there should be no problem with that unless I missedsomething. I also went through most, all, of the WE apps currently running on my machine and did not see that key combo used in them either. My Attempt to fix the problem: I added a WE Key Object OnProcessedKeyDown event handler to my script and tried to set focus by weApplication.ActiveWindow.Focus(). It fires but a couple of bad things happen: 1) the focus does not change. 2) According to a print statement embedded in the EventHandler Sub theActive and Focused windows are not changing as they should in normal VB.netprocessing without my Event Handler Sub. 3) The screen no longer goes dark as if the Hide Command in vb.net is not being processed. Conclusion: The Event Handler seems to be impacting vb.net's normal processing of the Shift-Escape KeyPress which should not be the case if I read the WE Docs correctly. I tried the KeyUp version but it never fired and thus Bruce's suggestionwhich is a little nebulus to my understanding but I will try anyway since hehas got it working in a couple of his apps. So thats it guys. Later and let me know if you have any ideas. Rick USA To: <[email protected]> Cc: "Stephen Clower" <[email protected]> Sent: Wednesday, May 23, 2012 7:57 PM Subject: Re: KeyProcessedUp and KeyProcessedDown EventsI was wondering that, too. If memory serves, Rick wanted special speech processing if the user presses Alt-Escape in Visual Studio. In that case, I would think the simplest solution would be to define Alt-Escape as aregistered hotkey. Within the hotkey event handler, unregister the hotkey, send the Alt-Escape key to VS, re-register the hotkey, and then perform anyspecialized speech output as desired. My only question would be whether Alt-Escape is one of the key combinations that Window-Eyes has trouble intercepting -- not sure either way. Jamal On 5/23/2012 10:48 AM, Stephen Clower wrote:Rick, What is the goal for your keyboard hooking? I assume this is for your VS 2010 project? Steve On 5/23/2012 10:40 AM, BT wrote:Hi Rick, Sorry about not getting back sooner, but the data is not available is the reason why I did what I did. But, you would have to look at each event, I think you will find that the key event info is not ready until the key processed event. I am just guessing but I think that is what I found out. So, when doing such an event set a flag to indicate the key is down. Then the next event, the key processed, gives you that data and the flag can be reset and such to indicate that the event you are watching is in fact the one that is giving the processed data... So, when the keydown event happens, connect to the keyProcessedUpevent and when that happens collect the data captured by the key events,for they will be ready at that point, and not some data from another event not related to the one you are in fact watching. The UnInstall program is involved a little because I am going down several tree levels so many conditions are checked. I reduced it down in the Trek game so it is a little more readable and very little there.So, just look at the very beginning of the MainDialogProc that doesthe call back events in my Trek.vbs. There is 2 subroutines for the processed event of the key which is set using the connectevent at the beginning of the call back function. See if that works for you. Bruce Sent: Wednesday, May 23, 2012 9:11 AM Subject: Re: KeyProcessedUp and KeyProcessedDown Events Hi Bruce: It sounds like you set up a handler for the KeyProcessedDown event and then, within that code, watch for the subsequent KeyProcessedUp event. Before I spend hours slogging through allot of unfamiliar code is this the case? Can you tell me why you used both the KeyProcessedUp and the KeyProcessedDown Event handlers instead of just the one that applied to your situation? Both event handlers have the same parameters so should work independently unless I am missing something from the Docs. Rick USA Rick USA From: BT To: [email protected] Sent: Wednesday, May 23, 2012 7:58 AM Subject: Re: KeyProcessedUp and KeyProcessedDown Events Hi Rick, I think you will find that the data is not there until the key is released, only a guess.Look at my Uninstall program, and the addition to my Trek game.In both .vbs files I watch for the key down and connect for the key upprocess. I think you will find that data and such is not ready until thekey processed up happens. Bruce To: [email protected] Sent: Wednesday, May 23, 2012 7:12 AM Subject: KeyProcessedUp and KeyProcessedDown Events Hi Guys:In my external script while testing against the Target App vb.net2010 Express: The KeyProcessedDown event fires the target subroutine specified in the AddressOf parameter. The KeyProcessedUp does not. Is the functionallity of these keys dependent on whether theTarget Application being scripted specifies the KeyUp or KeyDown Methods in the source code or are the WE versions suppose to execute upon actualuser interaction with the Keyboard regardless of whether the programmer used the KeyDown or KeyUp or KeyPressed methods? Also: When I do not use the OnKeyProcessedDown event handlers the screen goes dark when I press Shift-Escape to close the Solution Explorer. The screen does not go dark when I cllose the Solution Explorer while using the OnKeyProcessedDown Event Handler. The OnKeyProcessedUp Event handler does not fire in any case - thus the first question.If I understand these events they should not impact the operationof the Target Application being scripted so the screen should still go dark when the Shift-Escape keys are pressed without doing any handling of passing keys through to it, or am I wrong on that? Rick USA
