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
