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.

Reply via email to