Hi Again,
This will be the end of this thread. There are 2 different one's for
each key and mouse event. The key has either a function to return a state,
or a process to just check which key was going back up or down, which ever
event you chose.
The mouse also either gives you the button number or everything about
the mouse, which ever you want to know...
so, this works for lists or trees and the best way as far as I can tell
to do an action after the key is uup. Note that if you choose only the
OnkeyUp or down you can not do any key action during, of course, always use
a queue in any thing you do; preventing any hang-up, or infinite loops.
Final Calls:
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
Sub OnKeyProcessedUp( ky, md)
Speak " Key: " & ky & " Modifier: " & md & " Up "
Speak " Tree View Item " & TV_Name
TV_KeyDown = False
Disconnect myTV_KeyConnection
End Sub
Sub OnButtonUp( button)
Speak " Button: " & button & " Up "
Speak " Tree View Item: " & TV_Name
TV_MouseDown = False
Disconnect myTV_MouseConnection
End Sub
Sent: Wednesday, August 10, 2011 1:47 PM
Subject: Re: Tree view
Hi Aaron and all others,
This is how to get the event of any tree view key pressed or I am sure
it will work of a list view for the event number is the same for both, I
mean the keydown event for both.
So, what I did is make sure it was a tree view event and the keydown
event was captured as a flag being set and a key event to be monitored when
it comes back up.
Once it triggers the key up event I erase that event watch from the
program and everyone is happy. At that point I can place a queue inside the
sub before exiting to execute what I wanted to do.
So, here it is:
If dEvent = treeviewKeyDown Then
TV_KeyDown = True
myTV_KeyConnection = ConnectEvent( Keyboard, "OnKeyUp", "OnKeyProcessedUp")
End If
Sub OnKeyProcessedUp( ky, md)
Speak " Key: " & ky & " Up "
TV_KeyDown = False
Disconnect myTV_KeyConnection
End Sub
Sent: Tuesday, August 09, 2011 9:03 AM
Subject: Re: Tree view
Hi Aaron,
I know, the change event and changing event can be monitored, but, a
mouse click says nothing if already in focus...
But, monitoring the events limits usage to listing but not acting
immediately.
I was studying it this morning by just reading events as they came
through the dialog.
there is a -17 event which I have not looked up, but it fires so many
times it is not worth using.
I would have to place a delay in the use of list or tree view, or add a
check box. But noticed that if you check the box, there is no event but the
keydown event, once again would have to place a delay in it.
I have not looked at monitoring key events, just dialog events, I guess
that might be the way to go.
At least the mouse click still gives a selection change and selection
changing event, but with the need to wait until all settles down or the key
up, or the after key event kind of watch. Have not done that before, but
will have to experiment with it.
I could look at the link you gave me for further reading, but at the
moment just want to be able to click on a list or tree view item and do the
action immediately on it.
Will just have to experiment on it.
Thanks, Bruce
Sent: Tuesday, August 09, 2011 8:47 AM
Subject: Re: Tree view
On 8/8/2011 4:43 PM, BT wrote:
> I would like to ask GW why they made the Tree View option but only gave
> the
> key down event? Why not the key up event?
The tree view controls that Window-Eyes provides through our XML UI are
standard controls. If you read through the MSDN documentation on the
available tree view notifications
(http://msdn.microsoft.com/en-us/library/ff486107%28VS.85%29.aspx),
you'll find that standard tree view controls do not have a key up
notification. We simply expose standard tree view behavior.
> Also, when clicking on a tree view item that would select it, that is
> all you can do with it, then have to click on it a second time to do any
> function on it because the clicked event comes before any select event
> unless one were to delay it to allow the selection to happen.
Then why not just watch for the selection change event
(treeviewSelectionChange)? I would argue that monitoring click events on
a tree view doesn't give you anything more than you can already get from
the other events, especially considering that the
treeviewSelectionChange and treeviewItemExpanded events both provide a
TreeViewItem object indicating which tree view node was affected.
Aaron
--
Aaron Smith
Web Development * App Development * Product Support Specialist
GW Micro, Inc. * 725 Airport North Office Park, Fort Wayne, IN 46825
260-489-3671 * gwmicro.com
To insure that you receive proper support, please include all past
correspondence (where applicable), and any relevant information
pertinent to your situation when submitting a problem report to the GW
Micro Technical Support Team.
