J
Jon Pawley
Hi,
I have this problem with the .NETCF TreeView control, and I'm pretty
sure someone else had the same or a similar problem a wee while back.
Basically, I need to work out a way of detecting when the user taps
on a node in a TreeView control.
The .NET Compact Framework Frequently Asked Questions (at
http://msdn.microsoft.com/mobility/prodtechinfo/devtools/netcf/FAQ/default.aspx)
has this to say:
Well, that sounds reasonable, and I've given it a pretty good satb,
using the AfterSelect event. It's not perfect, but I can almost do
what I need. However there are two deficiencies that have me stumped,
and wondered whether anyone had a solution?
Problem 1: AfterSelect does not get fired if the user taps on a node
that is already selected.
Scenario: A form has a TreeView with a bunch of entries. Tapping on
one of the entries opens up a new form which allows the user to edit
the data associated with that node.
Thing is, the first node that is displayed automatically gets selected
before I can do anything about it. So, if the user wants to edit the
data associated with the first node that is displayed they have to tap
on any other node, which casues the secondary form to be displayed)
close that form, and then tap on the first node, the one they really
wanted. Hmm... and we are to explain that to our users how, exactly?
Well, then I thought, "OK, why don't I just set the
TreeView.SelectedNode to null, then nothing will be selected and then
the user will be able to tap on the first displayed node and
everything will be OK." Nope. Setting TreeView.SelectedNode to null
seems to have no effect. The initial form still shows the first
displayed node as being selected, so that doesn't work. (And besides,
it's not really a completed solution to not getting an evet when the
user taps on an already selected node.)
I was wondering whether there is a way to "subvert" .NETCF on this
one, and do some kind of magic P/Invoke thing to set the selected node
in the tree to "nothing". I haven't yet got to grips with P/Invoke
(probably about time, though...) and wondered if anyone had any
pointers? Thanks.
Problem 2: can't distinguish between a user selecting a node because
they tapped on it (and hence, want to edit the data associated with
the node) and the user tapping-and-holding because they want to pop-up
a context menu associated with the TreeView control.
Scenario: Pretty self explanatory. User might tap-and-hold (to get the
"red dots" or "Ring Of Fire") to pop-up the context menu, or they
might simply tap in order to open up the data editing form.
Unfortunatley MS didn't provide a
TreeView.PredictWhatTheUserWantsToDo() method...
Well, I've been working on this for a while, and the only half decent
thing I can do is, in the AfterSelect handler, do a
System.Threading.Thread.Sleep(200); and then test the state of the
Control.MouseButtons to see if the stylus is still in contact with the
touch screen. It is only half decent, isn't it? For how long should I
Sleep()? My latest idea is to play around with the
SystemInformation.DoubleClickTime to see if that is a suitable value
to use... I'll have to see.
My conclusion is that the TreeView control as provided by .NETCF SP2
is only barely adequate. I don't suppose there is any chance of
getting some MouseEvents from the control? (I can't understand why,
when TreeView is derived from Control, which does emit these--and a
few more--events, MS decided to keep them from us. There must be
something I don't fully understand...)
And, how do I explain to my employer that the TreeView control is
inadequate? "Ah, but you could do that easily in VB, *surely* you can
do it in .NET...," he says.
Seems I'm going to have to roll up my sleeves an implement a custom
tree view control that *is* adequate. Unless anyone has other ideas on
how to get around these problems? (And, I guess, it would be kind of
nice to hear from MS and explain why their TreeView is deficient.)
Cheers,
Jo
I have this problem with the .NETCF TreeView control, and I'm pretty
sure someone else had the same or a similar problem a wee while back.
Basically, I need to work out a way of detecting when the user taps
on a node in a TreeView control.
The .NET Compact Framework Frequently Asked Questions (at
http://msdn.microsoft.com/mobility/prodtechinfo/devtools/netcf/FAQ/default.aspx)
has this to say:
Well, that sounds reasonable, and I've given it a pretty good satb,
using the AfterSelect event. It's not perfect, but I can almost do
what I need. However there are two deficiencies that have me stumped,
and wondered whether anyone had a solution?
Problem 1: AfterSelect does not get fired if the user taps on a node
that is already selected.
Scenario: A form has a TreeView with a bunch of entries. Tapping on
one of the entries opens up a new form which allows the user to edit
the data associated with that node.
Thing is, the first node that is displayed automatically gets selected
before I can do anything about it. So, if the user wants to edit the
data associated with the first node that is displayed they have to tap
on any other node, which casues the secondary form to be displayed)
close that form, and then tap on the first node, the one they really
wanted. Hmm... and we are to explain that to our users how, exactly?
Well, then I thought, "OK, why don't I just set the
TreeView.SelectedNode to null, then nothing will be selected and then
the user will be able to tap on the first displayed node and
everything will be OK." Nope. Setting TreeView.SelectedNode to null
seems to have no effect. The initial form still shows the first
displayed node as being selected, so that doesn't work. (And besides,
it's not really a completed solution to not getting an evet when the
user taps on an already selected node.)
I was wondering whether there is a way to "subvert" .NETCF on this
one, and do some kind of magic P/Invoke thing to set the selected node
in the tree to "nothing". I haven't yet got to grips with P/Invoke
(probably about time, though...) and wondered if anyone had any
pointers? Thanks.
Problem 2: can't distinguish between a user selecting a node because
they tapped on it (and hence, want to edit the data associated with
the node) and the user tapping-and-holding because they want to pop-up
a context menu associated with the TreeView control.
Scenario: Pretty self explanatory. User might tap-and-hold (to get the
"red dots" or "Ring Of Fire") to pop-up the context menu, or they
might simply tap in order to open up the data editing form.
Unfortunatley MS didn't provide a
TreeView.PredictWhatTheUserWantsToDo() method...
Well, I've been working on this for a while, and the only half decent
thing I can do is, in the AfterSelect handler, do a
System.Threading.Thread.Sleep(200); and then test the state of the
Control.MouseButtons to see if the stylus is still in contact with the
touch screen. It is only half decent, isn't it? For how long should I
Sleep()? My latest idea is to play around with the
SystemInformation.DoubleClickTime to see if that is a suitable value
to use... I'll have to see.
My conclusion is that the TreeView control as provided by .NETCF SP2
is only barely adequate. I don't suppose there is any chance of
getting some MouseEvents from the control? (I can't understand why,
when TreeView is derived from Control, which does emit these--and a
few more--events, MS decided to keep them from us. There must be
something I don't fully understand...)
And, how do I explain to my employer that the TreeView control is
inadequate? "Ah, but you could do that easily in VB, *surely* you can
do it in .NET...," he says.
Seems I'm going to have to roll up my sleeves an implement a custom
tree view control that *is* adequate. Unless anyone has other ideas on
how to get around these problems? (And, I guess, it would be kind of
nice to hear from MS and explain why their TreeView is deficient.)
Cheers,
Jo