Hi Guys:
First thing this morning I removed all code from inside the Key Down handler
and totally removed the Key Up Handler.
So there is only the Sub and End Sub tags for the Key Down handler.
No methods, statements or anything to muck up stacks or whatever.
When I ran the vb.net 2010 Express the Solution Explorer normal function of
hidding it did not work, the screen did not go dark when I hit shift-escape.
This is a solid indication that the key down event handler in WindowEyes is
not working properly itself and it is not any code I had placed into it as
Bruce had suggested.
Since there is no Queue function in vb.net, at least I dont know how to
implement one, I will forget this method as I mentioned yesterday.
I just wanted to see if the problem was with WE itself and I think the result
of this test is indicative of that but I am no expert.
Rick USA
----- Original Message -----
From: RicksPlace
To: [email protected]
Sent: Friday, May 25, 2012 6:08 PM
Subject: Re: KeyProcessedUp and KeyProcessedDown Events
Hi Bruce: an external script can not use the WE queue method.
I think I will go back to trying to do everything in UIA and continue
avoiding the WE Object Model unless necessary.
I have no problem scheduling a StreamWriter operation when using UIA in
the script nor using the Speak command but I dont know what I need to do to
create aversion of the Queue command in VB.net so the print command and WE
Speak commands dont cause WE problems which, in turn, seem to cause problems
for the Target Program's operations.
This is what I was afraid of when considering building an external script
using the .net framework and the WE Object Model which is not compatible with
it.
There is allot of cross thread and apartment and marshalling that goes on
and I have never debugged anything like that. In fact, I am not sure WE will
even work well enough with the vb.net debugger to try and learn how to do it if
there is even anything out there on the subject.
So, this is a dead horse and I will try something else tomorrow unless
someone posts something I can dig into to create a vb.net version of the WE
Queue command.
Rick USA
----- Original Message -----
From: BT
To: [email protected]
Sent: Friday, May 25, 2012 4:00 PM
Subject: Re: KeyProcessedUp and KeyProcessedDown Events
Hi Rick,
The first thing the stand out immediately is no Queue, nothing but a
direct call to a file and that could hang everything. It must be done in a
Queue or the entire system dies...
As I had mentioned, wait until the keyprocessedup is done and you are
now outside of the key itself, but still use a Queue for it is always smart to
keep all data, especially file stuff away from any key action, for so many
stacks fire and the CPU will get lost in the shuffle.
So, just do a keyprocessedup event and queue any error handling there.
Look for your modifiers as you have done, but make sure you have a
Queue.
Bruce
Sent: Friday, May 25, 2012 3:48 PM
Subject: Re: KeyProcessedUp and KeyProcessedDown Events
Hi Guys and thanks for all the ideas so far: Here is the relevant code
and the WE Objects I am trying to use:
Remember that whenever the down key is pressed it stops Solution Explorer
from being hidden with or without any Key Up processing which is not what I
would expect.
In my code do you see anything that would muck up the Key Down Processed
Event Handler?
I dont do anything to change the Key Down Process and, in fact, want it
to work normally until I change focus downline.
Bruce, the KeyUp actually fired in an earlier test so I am guessing it is
suppose to fire.
If I dont get it working sooner rather than later I may try to use just
the Automation OnFocus event handler to determine when Solution Explorer loses
focus if that works - another analysis project.
MyCode:
In Main Module:
Public ShiftEscapeKeyUpHandlerExists As Boolean = Nothing
Public ShiftEscapePressed As Boolean = Nothing
Public WithEvents ShiftEscapeKey As WindowEyes.Key
In Initialize Sub:
Try
ShiftEscapeKey = weApplication.KeyBoard.Key( "Shift-Escape" )
AddHandler ShiftEscapeKey.OnKeyProcessedDown, AddressOf
instTester.OnKeyProcessedDownSub
ShiftEscapePressed = False
Catch ex As Exception
ScriptLog.WriteLine( "Catch Triggered assigning ShiftEscapeKey Handlers")
ScriptLog.WriteLine( ex.ToString())
End Try
In the Tester Class, the handler subs.
Public Class Tester
Dim ClassID As String = "Tester"
Dim MethodID As String = ""
Public Sub OnKeyProcessedDownSub(ByVal ReturnedKey As Integer, ByVal
ReturnedModifiers As WindowEyes.KeyModifiers)
MethodID = "OnKeyProcessedDownSub"
ScriptLog.WriteLine( "Enter " & ClassID & " > " & MethodID)
mySpeech.Speak( "Key Down fired")
ScriptLog.WriteLine( "ActiveWindowName: " &
weApplication.ActiveWindow.Name)
ScriptLog.WriteLine( "weApplication.FocusedWindow.Name: " &
weApplication.FocusedWindow.Name)
If Not ShiftEscapeKeyUpHandlerExists Then
Try
AddHandler ShiftEscapeKey.OnKeyProcessedUp, AddressOf OnKeyProcessedUpSub
ShiftEscapeKeyUpHandlerExists = True
Catch ex As Exception
ScriptLog.WriteLine( "Catch Triggered assigning ShiftEscapeKey Handler
In: " & ClassID & " > " & MethodId)
ScriptLog.WriteLine( ex.ToString())
End Try
End If
ScriptLog.WriteLine( "Exit " & ClassID & " > " & MethodID)
End Sub
Public Sub OnKeyProcessedUpSub(ByVal ReturnedKey As Integer, ByVal
ReturnedModifiers As WindowEyes.KeyModifiers)
MethodID = "OnKeyProcessedUpSub"
ScriptLog.WriteLine( "Enter " & ClassID & " > " & MethodID)
mySpeech.Speak( "Key Up fired")
ScriptLog.WriteLine( "ActiveWindowName: " &
weApplication.ActiveWindow.Name)
ScriptLog.WriteLine( "weApplication.FocusedWindow.Name: " &
weApplication.FocusedWindow.Name)
ScriptLog.WriteLine( "Exit " & ClassID & " > " & MethodID)
End Sub
End Class
Here are the WE Objects I use:
The Window-Eyes Object Model
Objects
Keyboard
Methods
Key
Returns a
Key
object from a string name.
Syntax
Set object_variable = object.Key(KeyName)
where object is a
Keyboard
object.
Parameters
Name
Data Type
Required/Optional
Description
KeyName
String
Required
The quoted string containing the name of a key (i.e. "Control-Shift-Q").
Modifiers
are spelled out completely, not abbreviated. You can use the Window-Eyes
hot key
dialog to verify the exact spelling of a hot key to use as a string. To
create an
Undefined key, use an empty string (i.e. "").
The Window-Eyes Object Model
Objects
Key
Events
OnKeyProcessedDown
Occurs when a key is pressed and processed. You cannot modify the
behavior of the
key press during this event.
For security purposes, key events will not fire when a password edit box
has focus.
Syntax
Sub OnKeyProcessedDown(
VirtualKeyCode
,
KeyModifiers
)
Parameters
Name
Data Type
Description
VirtualKeyCode
Long
The value of the key that was passed to the event
KeyModifiers
Enum
Key modifiers that were passed to the event
The Window-Eyes Object Model
Objects
Key
Events
OnKeyProcessedUp
Occurs when a key is released and processed. You cannot modify the
behavior of the
key press during this event.
For security purposes, key events will not fire when a password edit box
has focus.
Syntax
Sub OnKeyProcessedUp(
VirtualKeyCode
,
KeyModifiers
)
Parameters
Name
Data Type
Description
VirtualKeyCode
Long
The value of the key that was passed to the event
KeyModifiers
Enum
Key modifiers that were passed to the event
ndOf WEDocs>
----- Original Message -----
From: BT
To: [email protected]
Sent: Wednesday, May 23, 2012 12:35 PM
Subject: Re: KeyProcessedUp and KeyProcessedDown Events
Hi Rick,
Steve had a good question on this but what I think you are saying
may be the result of the program you are trying to control. For the events you
are asking are related to that program, unless you want to do it at the other
end. So you actually may have answered your own question.
If the other program is not triggering the other event, then it
will not be seen. I guess you could monitor it and do it yourself to get around
the no keyup event process of the command you want.
This below is for event info data and when that is available for an
object in the call back function.
Sincerely
Bruce
Sent: Wednesday, May 23, 2012 10:50 AM
Subject: Re: KeyProcessedUp and KeyProcessedDown Events
Hi Rick,
This is a tree view item but I think all key processes are the
same but may be wrong.
I capture the event change, store the data of the event which
submitted the data. Waited until the key processed event to insure that the
data may or should be related to the key in question.
This is what I did inside the Trek game. I have extra stuff there
from the Uninstall program because in the future I may allow people to store
information in the game...
Bruce
MainDialogProc = False
If dEvent = treeviewKeyDown Then
TV_KeyDown = True
myTV_KeyConnection = ConnectEvent( Keyboard, "OnKeyProcessedUp",
"OnKeyProcessedUp")
End If
If dEvent = treeviewClicked Then
TV_MouseDown = True
myTV_MouseConnection = ConnectEvent( Mouse, "OnButtonUp",
"OnButtonUp")
End If
If dEvent = treeviewSelectionChange Or dEvent = treeviewClicked Then
'Or dEvent = treeviewItemExpanded Then
Set TV_Obj = dControl.selected
Set TV_ObjControl = dControl
TV_Name = TV_Obj.Text
TV_Data = TV_Obj.Data
TV_Array(1) = TV_Data
...
End Function
Sub OnKeyProcessedUp( ky, md)
Disconnect myTV_KeyConnection
myTV_KeyConnection = 0
If TV_KeyDown and ky = vk_Space and md = 0 Then
Silence
' Speak " Name Is: " & TV_Name & " Item " & TV_Data & " Whose Item
Was Space Barred "
If treeNamesDict.Exists( TV_Name) Then Speak treeNamesDict( TV_Name)
Queue "LaunchURLEmail"
End If
TV_KeyDown = False
End Sub
Sub OnButtonUp( button)
Disconnect myTV_MouseConnection
myTV_MouseConnection = 0
If TV_MouseDown and button = 0 Then
' Speak " Name Is: " & TV_Name & " Item " & TV_Data & " Whose Item
Was Mouse Clicked "
If treeNamesDict.Exists( TV_Name) Then Speak treeNamesDict(
TV_Name), 2
Queue "LaunchURLEmail"
End If
TV_MouseDown = False
End Sub
