Re: [Winforms] Treeview events

[Peter Duniho]

On Sat, 27 Sep 2008 12:02:04 -0700, <ti*********@gmail.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]

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" <[e-mail]:

On Sat, 27 Sep 2008 12:02:04 -0700, <[e-mail]:

[...]
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]

On Sat, 27 Sep 2008 13:58:20 -0700, <ti*********@gmail.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 FileSystemWatcher 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]

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" <[e-mail]:

On Sat, 27 Sep 2008 13:58:20 -0700, <[e-mail]:

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 FileSystemWatcheras *
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]

On Sun, 28 Sep 2008 00:10:24 -0700, <ti*********@gmail.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 FileSystemWatcher
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]

On 28 sep, 09:37, "Peter Duniho" <[e-mail]:

On Sun, 28 Sep 2008 00:10:24 -0700, <[e-mail]:

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 FileSystemWatcher *
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
FileSystemWatcher, and it's working good, I can improve my
reloading...

Thanks for your help

Best regards