Hi Dave,
Yes you could do things when the key is down, but you run the risk of
collision with the CPU stack and such.
Inside the WE object model, they allow you to block the we speaking of
the key and such. Now, as long as that process is short, in and out quick,
you have no problem. But, like the Queue process, you want to be totally
outside of that event before doing anything else.
I do not know if Rick is using the Queue method or not, but, the key
down has it's place especially for Windoweyes speaking keys and such.
I just think you will find that this is for blocking the WE processing
the key.
As I said, you use it at your own risk. But, in Tree Views and such,
there is no data collected until you have the keyprocess event...
In other words, monitor the key down, so you can check to see if there
any modifiers, control/shift and such also pressed. If clear of them, then
do what you want to do depending on keys pressed. But, do not do anything
while the key is down or timing issues, stacks and such are also in play and
things like the last fix to Windoweyes was key events causing crashes. Even
GW Micro had to fix such issues.
Bruce
Sent: Thursday, May 24, 2012 9:25 AM
Subject: Re: KeyProcessedUp and KeyProcessedDown Events
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 to
> close tool windows like Solution Explorer although it is never really
> closed
> only "hidden".
> Actually it is a TabItem but that is neither here nor there for this
> problem
> me 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 and
> did not see it there so there should be no problem with that unless I
> missed
> something. 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 the
> Active and Focused windows are not changing as they should in normal
> VB.net
> processing 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 suggestion
> which is a little nebulus to my understanding but I will try anyway since
> he
> has 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 Events
>
>
>>I 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 a
>>registered hotkey. Within the hotkey event handler, unregister the
>>hotkey,
>>send the Alt-Escape key to VS, re-register the hotkey, and then perform
>>any
>>specialized 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 keyProcessedUp
>>>> event 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
>>>> does
>>>> the 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 up
>>>> process. I think you will find that data and such is not ready until
>>>> the
>>>> key 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.net
>>>> 2010 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 the
>>>> Target Application being scripted specifies the KeyUp or KeyDown
>>>> Methods
>>>> in the source code or are the WE versions suppose to execute upon
>>>> actual
>>>> user 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
>>>> operation
>>>> of 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
>>>>
>>>
>>
>
