Treenode image problem bug?

[Bob]

Hi,
I have a treeview which contains nodes of a class (classA) derived from
treenode.
These classA nodes may contain nodes of a class (ClassB) derived from
classA.
The form load populates a imagelist and calls a subroutine that assigns an
image to each node depending on its type.

If I expand a classA node, all is well. ie. I see the classA image on the
classA node and the classB image on the exposed classB node (which is always
a leaf node)

If I then click on the classB node it takes a classA image.

If I move further down the tree trunk and repeat this procedure on another
classA node the fault moves to this node / leaf node pair
ie. The first node / leaf node pair revert to the correct images.
It seems to me that it is something to do with selecting the leaf node, but
I have commented out my mouse event handlers and it still happens.
Also single stepping indicates that it is not in user defined code because
as soon as you step out of the mouse down event handler the code runs on
automatically and paints the form with the faulty image.
It is picking up image(0) from the imagelist.
Is this a known bug?
Is there a workaround?
thanks
Bob

 

[Jay B. Harlow [MVP - Outlook]]

Bob,
Remember that TreeNode has both ImageIndex & SelectedImageIndex.

It is picking up image(0) from the imagelist.

It sounds like you set the ImageIndex & left SelectedImageIndex at its
default of 0.

It also sounds like Class A nodes have ImageIndex=0, while Class B Nodes
have ImageIndex = 1 with SelectedImageIndex = 0.

Hence whenever you select a node you are seeing Class A's image...

If you don't have an actual Selected Image. I would set both ImageIndex &
SelectedImageIndex to the same value. Alternatively you could define both
images & selected images in your ImageList and set the ImageIndex &
SelectedImageIndex properties of both classes appropriately...

Hope this helps
Jay

 

[Bob]

Jay,
I am prostrate at your feet!
Right On.
thanks
Bob

 

[Cor Ligthert]

Bob,

Please don't write that something is a bug before that is more sure, than we
have more change that Microsoft will look at real bugs.

Just my opinion

Cor

 

[Jay B. Harlow [MVP - Outlook]]

Cor,
It seems to me that Bob asked if it was a bug, I don't see that he stated
that it definitely is.

Although I agree, too many developers feel that the bug is in the Framework
or the OS, when "Select" isn't broken!

http://www.pragmaticprogrammer.com/ppbook/extracts/rule_list.html

Just a thought
Jay

 

[Cor Ligthert]

Jay,

Does that not almost all fit for "us"?



Cor