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