Re: [Winforms] Treeview events

[Peter Duniho]

On Sat, 27 Sep 2008 12:02:04 -0700, <timor.super@gm ail.comwrote:

[...]
The problem is that I have to do this thing if I only select the node,
or if i only click on the node ; so depending on what i'm doing :
>
- click on the node (that is already selected) =my treatment is
doing 1 time (only the mouse click event is fired)
- click on the node (that is not selected) =2 times (After select &
MouseClick)
- expand the node =3 times
>
How can I make my treatment only one time and that all the 3 things
are covered ?

You don't, not when you don't know that one event is necessarily going to
follow another. If the events can appear alone, then you can't make them
depend on each other.

You don't describe what this "thing" you are doing is. But it's bad
design to have some "thing" you do in response to user input like this be
something that can't be done repeatedly. For example, any good UI design
that uses both single clicks and double-clicks will always perform the
single-click action first, even for a double-click event, because
otherwise the UI winds up laggy at best, and confusing at worst.

So, hopefully your only concern here is one of performance, in which case
the answer is "don't worry about it". If it's somehow harmful to repeat
the action, then you should rethink your user-interface design.

Pete

[timor.super@gmail.com]

Re: Treeview events

Thanks for your answer. The "thing" is :
it's a treeview containing the files on the hard drive, so, deploy a
node load the files under the directory
Selecting the node, update the node with possible change on the hard
disk, clicking on the node too ...

When there's many files, the loading or updating (that is the same
task) can be quite long, that's why I would like to avoid loading this
too many times.

Any idea ?

On 27 sep, 22:47, "Peter Duniho" <NpOeStPe...@nn owslpianmk.comw rote:

On Sat, 27 Sep 2008 12:02:04 -0700, <timor.su...@gm ail.comwrote:

[...]
The problem is that I have to do this thing if I only select the node,
or if i only click on the node ; so depending on what i'm doing :

>

- click on the node (that is already selected) =my treatment is
doing 1 time (only the mouse click event is fired)
- click on the node (that is not selected) =2 times (After select &
MouseClick)
- expand the node =3 times

>

How can I make my treatment only one time and that all the 3 things
are covered ?

>
You don't, not when you don't know that one event is necessarily going to 
follow another.  If the events can appear alone, then you can't make them  
depend on each other.
>
You don't describe what this "thing" you are doing is.  But it's bad  
design to have some "thing" you do in response to user input like this be 
something that can't be done repeatedly.  For example, any good UI design  
that uses both single clicks and double-clicks will always perform the  
single-click action first, even for a double-click event, because  
otherwise the UI winds up laggy at best, and confusing at worst.
>
So, hopefully your only concern here is one of performance, in which case 
the answer is "don't worry about it".  If it's somehow harmful to repeat  
the action, then you should rethink your user-interface design.
>
Pete

[Peter Duniho]

Re: Treeview events

On Sat, 27 Sep 2008 13:58:20 -0700, <timor.super@gm ail.comwrote:

Thanks for your answer. The "thing" is :
it's a treeview containing the files on the hard drive, so, deploy a
node load the files under the directory
Selecting the node, update the node with possible change on the hard
disk, clicking on the node too ...
>
When there's many files, the loading or updating (that is the same
task) can be quite long, that's why I would like to avoid loading this
too many times.
>
Any idea ?

Yes. Don't do that. :)

Instead, your nodes should retrieve the data as needed according to
visibility and changes to the directory. You can use FileSystemWatch er as
a way to monitor the latter; it's not perfect (rapid changes can overwhelm
it, especially if you're not careful to keep your event handlers simple),
but it'd be automatic rather than relying on user input and would avoid
the redundancy

If you insist on relying on user input to decide when to refresh, don't
make it based on selection. Retrieve the data as needed according to
visibility, and then provide the user with an explicit option to refresh
the data (e.g. context menu).

One final option, if you insist on this redundant behavior, is to handle
the updating in a worker thread and only start it again if you're not
already processing that node. Of course, each node would have to keep
track of whether it's waiting for such a worker thread to finish updating
it, but that's not hard.

Pete

[timor.super@gmail.com]

Re: Treeview events

I find your method quite hard.
It's strange that I need to watch the entire system to be aware of
files modification on a tree.
I won't load the entire tree at beginning too, it's taking too much
time ...

Is there a design pattern for treeview ?

On 27 sep, 23:08, "Peter Duniho" <NpOeStPe...@nn owslpianmk.comw rote:

On Sat, 27 Sep 2008 13:58:20 -0700, <timor.su...@gm ail.comwrote:

Thanks for your answer. The "thing" is :
it's a treeview containing the files on the hard drive, so, deploy a
node load the files under the directory
Selecting the node, update the node with possible change on the hard
disk, clicking on the node too ...

>

When there's many files, the loading or updating (that is the same
task) can be quite long, that's why I would like to avoid loading this
too many times.

>

Any idea ?

>
Yes.  Don't do that.  :)
>
Instead, your nodes should retrieve the data as needed according to  
visibility and changes to the directory.  You can use FileSystemWatch eras  
a way to monitor the latter; it's not perfect (rapid changes can overwhelm  
it, especially if you're not careful to keep your event handlers simple), 
but it'd be automatic rather than relying on user input and would avoid  
the redundancy
>
If you insist on relying on user input to decide when to refresh, don't  
make it based on selection.  Retrieve the data as needed according to  
visibility, and then provide the user with an explicit option to refresh  
the data (e.g. context menu).
>
One final option, if you insist on this redundant behavior, is to handle  
the updating in a worker thread and only start it again if you're not  
already processing that node.  Of course, each node would have to keep  
track of whether it's waiting for such a worker thread to finish updating 
it, but that's not hard.
>
Pete

[Peter Duniho]

Re: Treeview events

On Sun, 28 Sep 2008 00:10:24 -0700, <timor.super@gm ail.comwrote:

I find your method quite hard.

To each their own, I suppose.

It's strange that I need to watch the entire system to be aware of
files modification on a tree.

I never suggested you need to watch the _entire_ system. Each node could
install its own handler for its own specific spot in the file system, if
and only if that node is visible.

I won't load the entire tree at beginning too, it's taking too much
time ...

Again, I never suggested you do.

All that said, "my method" is not necessarily to use the FileSystemWatch er
class. That was but one suggestion I offered. I think having a
user-initiated refresh would be fine too. But doing it simply because a
node is selected? Not only is that the root of your present problem, it
seems overly eager and potentially confusing to the user.

Pete

[timor.super@gmail.com]

Re: Treeview events

On 28 sep, 09:37, "Peter Duniho" <NpOeStPe...@nn owslpianmk.comw rote:

On Sun, 28 Sep 2008 00:10:24 -0700, <timor.su...@gm ail.comwrote:

I find your method quite hard.

>
To each their own, I suppose.
>

It's strange that I need to watch the entire system to be aware of
files modification on a tree.

>
I never suggested you need to watch the _entire_ system.  Each node could  
install its own handler for its own specific spot in the file system, if  
and only if that node is visible.
>

I won't load the entire tree at beginning too, it's taking too much
time ...

>
Again, I never suggested you do.
>
All that said, "my method" is not necessarily to use the FileSystemWatch er  
class.  That was but one suggestion I offered.  I think having a  
user-initiated refresh would be fine too.  But doing it simply because a  
node is selected?  Not only is that the root of your present problem, it  
seems overly eager and potentially confusing to the user.
>
Pete

Ok,

I understand better. I've used your suggestion to use a
FileSystemWatch er, and it's working good, I can improve my
reloading...

Thanks for your help

Best regards