Rick,
Considering registering a cursoring key to Shift-Escape. The key will
pass through to VS as normal, and once done you could attempt moving
focus. What is likely happening is that while the window is hidden on
screen, it still actually exists and thus your focus doesn't change.
What if, in your cursor key event handler, you simulate a Tab to move
focus elsewhere?
Steve
On 5/24/2012 8:46 AM, RicksPlace wrote:
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
--
Stephen Clower
Product support specialist & App Development
GW Micro, Inc. * 725 Airport North Office Park, Fort Wayne, IN 46825
260-489-3671 * gwmicro.com
