The NodeMouseDoubleClick event passes the incorrect node in the TreeNodeMouseClickEventArgs

[Tom]

Hello everyone,

I found a frustrating behavior in the TreeView control in .NET 2.0.
The TreeNode that is passed in the TreeNodeMouseClickEventArgs is
incorrect when the TreeView automatically scrolls upon expanding. Here
is some code that will reproduce the problem:

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Text;
using System.Windows.Forms;

namespace WindowsApplication1
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();

TreeNode rootnode = new TreeNode("Level 1: Node Number 1");

for (int i = 0; i < 5; i++)
{
TreeNode tempNode = new TreeNode(string.Format("Level
2: Node Number {0}", i));

for (int z = 0; z < 50; z++)
{
tempNode.Nodes.Add(new
TreeNode(string.Format("Level 3: Node Number {0}", z)));
}

rootnode.Nodes.Add(tempNode);
}

this.treeView1.Nodes.Add(rootnode);
}



private void treeView1_NodeMouseDoubleClick(object sender,
TreeNodeMouseClickEventArgs e)
{
MessageBox.Show(e.Node.Text);
}

}
}


Try double clicking on the node labeled "Level 2: Node Number 1". I
would expect that e.Node.Text would say "Level 2: Node Number 1".
However, it reads "Level 3: Node Number 1".

Is there something that I am doing wrong? Any work arounds?

Thanks,
Tom

 

[Tom]

I came up with one work around.

I added the following code to the code I submitted with my first
posting:

private TreeNode mLastNode = null;

private void treeView1_MouseDown(object sender, MouseEventArgs e)
{
mLastNode = this.treeView1.GetNodeAt(new Point(e.X, e.Y));
}

I also changed the MessagBox line to:

MessageBox.Show(mLastNode.Text);


This seems to give me what I want. However, I am still curious why the
code in the first posting doesn't work. It seems that the
NodeMouseDoubleClick event does the expanding first then tries to
populate the TreeNodeMouseClickEventArgs .Node. Because the control
scrolled, the mouse coordinates for the double click event now points
to another node. Is this right?

Does anyone have a better work around than this?

Tom

 

[Larry Lard]

Hello everyone,

I found a frustrating behavior in the TreeView control in .NET 2.0.
The TreeNode that is passed in the TreeNodeMouseClickEventArgs is
incorrect when the TreeView automatically scrolls upon expanding.

I agree this is probably technically a bug - however, I would argue
that it's only being exposed because you are overloading the meaning in
the UI of double clicking a node. Do you want it to mean
collapse/expand, or do you want it to mean <do whatever>? Without
knowing what <whatever> is in the real app, it's hard to be absolutely
sure, but consider everyone's favorite treeview - the one in Windows
Explorer. Node double click means one thing unambiguously there, and I
don't think anyone would like it if node double click *also* did
something like, say, bringing up the properties window for that folder.

What is it you actually do on node double click? (If you actually want
to track collapse/expand events, these are events on the *nodes*, not
the treeview)

 

[Tom]

Larry,

Your point is well taken and I have considered another ui design where
there isn't ambiguity about what does what. However, I chose this
design actually because my users are use to and request the behavior
demonstrated by WIndows Explorer.

Perhaps I didn't understand your comments about WIndows Explorer, but I
think you are wrong about Windows Explorer. Double clicking in the
explorer either expands a folder or it will also show the contents of a
folder that doesn't have any subfolders. This might actually be
responding to the first mouse down on the folder and the expand is
skipped because there isn't any children nodes to expand. The end
result is the same regardless. I have been told that the user wants to
be able to double click the leaf nodes and open the thing that is
represented in the leaf node. A mouse click doesn't fit this ui design
because it leads to opening items that the user did not intend to open.

Thanks,
Tom

 

[Larry Lard]

Larry,

Your point is well taken and I have considered another ui design where
there isn't ambiguity about what does what. However, I chose this
design actually because my users are use to and request the behavior
demonstrated by WIndows Explorer.

Perhaps I didn't understand your comments about WIndows Explorer, but I
think you are wrong about Windows Explorer. Double clicking in the
explorer either expands a folder or it will also show the contents of a
folder that doesn't have any subfolders. This might actually be
responding to the first mouse down on the folder and the expand is
skipped because there isn't any children nodes to expand. The end
result is the same regardless.

Well, I would put a different spin on it:

Single click: show contents of that folder in the other pane
Double click: expand / collapse if applicable

This would translate directly into code with the events exposed in the
Framework (which are just the Windows messages, really), namely
NodeMouseClick and NodeMouseDoubleClick. Remember that when a user
double clicks we get a click event then a double click event - this
paradigm of 'select on click, activate on double click' is widely used.
eg a listbox where clicking selects, double clicking does the same
thing as presing the OK button.

I have been told that the user wants to
be able to double click the leaf nodes and open the thing that is
represented in the leaf node. A mouse click doesn't fit this ui design
because it leads to opening items that the user did not intend to open.

With the leaf nodes there is no problem, because there is no built-in
behaviour for leaf nodes. However, what do your users want to happen
when they double click a *branch* node - that is, one with children? Do
they want it to expand/collapse AND open the thing it represents? (Do
branch nodes even represent the things in question?) I would be
surprised if the answer were yes.

If the answer is no, so double click behaviour should depend on whether
the node has children, then you can easily accommodate this by only
doing the 'show thing' action on double click _when the node is leaf_.