|
It seems that the node ForeColor is lost with MWTreeView. Just set the ForeColor property to some node:
node.ForeColor = Color.LightGray
As soon as you click the node to select it and then you unselect it, the original ForeColor isn't restored.
I don't know if I can still use the ForeColor property on a TreeNode or if I need to use another property of the node wrapper implemented in MWCommon.
Marco Tenuti - www.tencas.com
|
|
|
|
|
It should work.
Have a look at the screenshot TreeNodeColors (the bottom one). Here I am using many different ForeColors (and BackColors).
The only problem you might be encountering is that you can't set ForeColor (or BackColor, ImageIndex and SelectedImageIndex) on a TreeNode when that TreeNode is selected. ForeColor and the other Properties that exist in the MWTreeNodeWrapper class must be set on the MWTreeNodeWrapper object for that particular TreeNode in the SelNodes Hashtable.
|
|
|
|
|
Your treeview control is very powerful and wonderful!Thank you!
Would you please give me an example code about a project codes that one treeview can drop into another treeview(those can be multi-selected).Thank you very much !
My email is :ycjin@citiz.net
David King
|
|
|
|
|
Do you mean one application with two MWTreeViews in it? If so, then I am working on code that does this. It is essentially finished, and has been for months now, but I haven't had much spare time lately to finish it up. It is code that is very visual; you can see exactly where you are moving or copying TreeNode(s) whether it be into other TreeNode(s) or in-between other TreeNodes.
You will just have to wait for this code to be finalized 
At the moment I don't have any drag & drop code that works between two MWTreeViews in different applications since the TreeNodes are not serializable. I believe that the best way to do this is to write some form of serializer yourself, XML e.g.
|
|
|
|
|
Thank you for your answering my question.
If you finish this project code.Would you email me?Thank you!
I just want two treeviews in one application.Just multi-select is copied&moved by mouse drag&drop action.
I think you must spend your playing time in it.So Thank you very much!I am from China,and my English is poor
David King
|
|
|
|
|
No need of serialization at all. Just keep in mind that you have 2 differents instances of the TreeView. So in my case, I modify the DoDragDrop() function in OnItemDrag() by passing my item (the node).
this.DoDragDrop(e.Item, DragDropEffects.Move);
And at the OnDragDrop() fonction, you can reach the instance from where the node come.
<br />
TreeNode MovingNode = (TreeNode)e.Data.GetData("System.Windows.Forms.TreeNode");<br />
TreeView FROM = (TreeView)MovingNode.TreeView;<br />
At this point, you have just to modify your code by keeping in mind that now you have two instances of the TreeView ("this" and "FROM"). In that case, you will probably delete old nodes situated at the FROM TreeView .
That's it. The difficult part is getting data by passing the right string...
|
|
|
|
|
... of course it's just a little example to give you the idea... you'll probably passing an ArrayList, not only one node 
Keep in mind that is futil to look at old selected nodes to know wich nodes you are about droping.
|
|
|
|
|
The way I have done drag & drop is by having a collection of TreeNodes that are passed (or actually MWTreeNodeWrappers).
By passing this in the drag & drop EventHandlers I get more than just the Text of the TreeNode(s); I can see if they are selected, should be expanded, BackColor, ForeColor, Font and all the other Properties that TreeNodes have.
When I do a drag & drop operation between two different applications and I debug in the one that the TreeNodes are dropped into (inside the OnDragDrop EventHandler) I can get my MWTreeNodeWrapper (mwtnw) out of the collection I am using. But when I put mwtnw into a Watch in Visual Studio, expand it and check the Node Property (where the TreeNode is) this is what I see:
System.Runtime.Remoting.Proxies.__TransparentProxy
And mwtnw.Node.Text contains this:
error: an exception of type: {System.Runtime.Remoting.RemotingException} occurred
I then get an exception with the following Message (when I try to access mwtnw.Node e.g.):
This remoting proxy has no channel sink which means either the server has no registered server channels that are listening, or this application has no suitable client channel to talk to the server.
If I understand this correctly it means that I cannot do it because the TreeNode cannot be serialized which is what is required by a drag & drop operation between two separate applications.
Please tell me if I am doing something wrong here or if I have not understood how it should properly be done.
Have you tried doing this yourself? If so I would be very happy if you could send me some very simple (or not so simple, it doesn't really matter) test app that does this, and then I will investigate
|
|
|
|
|
 oh ! I though that we was talking about "one application with two MWTreeViews" but... as we talk about D&D between two applications, these articles could be really usefull :
Drag and Drop files from Windows Explorer to Windows Form
Tool for viewing Drag and Drop and Clipboard formats
To be honest with you, I never tried to implement this kind of D&D...
But about "serializing" the TreeNodes, based on my knowledge, I guest that it would be very simple with binary serialisation on a "personal" inherited version of the Windoze.Forms.TreeNode. 
But the problem is, where properly store the generated file after the serialization ? Put in C:\Temp isn't a really clean way... if you don't borded yourself with this detail, I don't mind how you could failed implementing the D&D between 2 applications.
What's you opinion about this "action plan" ?
|
|
|
|
|
One app with two MWTreeViews is no problem.
If you inherit from TreeNode you still cannot have automatic serialization but have to do it yourself. I just haven't bothered with this (yet?). This could be XML serialization e.g. like I mention a few comments up.
When serializing I wouldn't put it into a file at all - just putting it in memory is much better. That way you can achieve proper seamless drag & drop between two applications each with an MWTreeView.
|
|
|
|
|
Yeah, ok.
But how can you "share" an XML object created by serialization directly in memory, without passing by a "physical" file between 2 applications ? Is this a deep .Net trick... 'cause 2 differents applications mean 2 differents and independants memory heap, these heap and their integrity are "supposed" to be managed by the OS... but are you saying that .Net FrameWork offer a kind of bypass about this ? 
If so, are you talking of SOAP ?
|
|
|
|
|
I haven't done it, but it should be possible to pass the XML as a string using the regular drag & drop operations.
As far as I understand you don't have to go any further than that. It should be pretty easy to create a test app that does this.
|
|
|
|
|
Sure, great idea... but if passing directly an Array of TreeNode failed like you said, that will probably be the same thing with a string that contain a "scrypted XML version" of the nodes. 
|
|
|
|
|
A string can be passed I am sure. And what the string contains should be irrelevant.
Unfortunately parsing has to be done, which could slow the whole operation down quite a bit.
Maybe there is some way of checking if the MWTreeViews are in separate applications and only then do you use XML, otherwise a collection of TreeNodes. I am not sure this is possible though.
|
|
|
|
|
I think you are going too far... maybe asking some C# and/or .Net Guru, or directly a Microsoft Certified programmer, will help you much than imaginate a kind of big solution curving the real problem itself... I don't saying that you are wrong, but my opinion and my experience say "wow, there's probably something somewhere we passed through and we missed up an important detail" 
... or maybe you're right, and you have found another great hole in the .Net Framework and his "famous" extremely poor TreeView control (I spent too much time on it, and it's really frustrating). 
|
|
|
|
|
I need to know what is the action doing the selection to differentiate between ui selection and code selection... but your BeforeSelect method loses this Winforms feature... is it a known bug?
Patrick
|
|
|
|
|
Patrick,
BeforeSelect and AfterSelect should not be used with the MWTreeView.
There are new EventHandlers that take their place:
BeforeSelNodesAdd
AfterSelNodesAdd
BeforeSelNodesRemove
AfterSelNodesRemove
But these do not keep track of the TreeViewAction.
This is no bug, I simple haven't cared about the TreeViewAction property. If users want the functionality, I could possibly
consider implementing it.
I am however quite busy at the moment adding drag & drop support to the MWTreeView and finishing off my new 100% owner-drawn
MWMonthView.
I hope this answers you question.
Mikael
|
|
|
|
|
Note that this 'article' is more of a tech demo than an article.
Please consider it as such.
It is provided as a means of finding out what can be done to the original TreeView - not to teach someone how to modify the original TreeView.
|
|
|
|
|
In my opinion, but not making this article help at least a *little* with modifying the treeview, you are holding teh carrot in front of a developer but never letting the carrot being consumed. Yes, this is useful, but I think it would be much more than twice as useful if you had shown at least a few tips on how to make this work.
|
|
|
|
|
I am not quite sure I understand your comment but here we go:
Read the code. If you had, you would see that it is full of comments that could teach you to do the same thing, and probably better.
I had two options when posting this:
1) Post the code, say its a demo. That way I don't have to spend hours on writing explanations about how I did it (especially since its all in the comments for the code). AND people get to use the MWTreeView.
2) Don't post the code. Noone would be able to use the MWTreeView. Noone would be able to get answers as to how to do a lot of the things I do in the MWTreeView (which, like I said, is explained in the comments of the code).
The only developers who cannot 'consume the carrot' as you so eloquently put it are the ones who cannot read a combination of C# code and plain English. Seriously, open up the project and read the code and the comments and you will agree (provided you know C# and English like I said).
|
|
|
|
|
The impression your comment maee on me was this: I thought that you hadn't felt like commenting your code and perhaps there was a little spaghetti code and such. I thought that you were providing pictures only and that the included code would be hard to decipher. That's why I made me previous reply. You have addressed all my concerns.
|
|
|
|
|
There is a little bit of spaghetti code - which in my view unfortunately is inevitable for the TreeView... Let me explain;
The MWTreeView does a lot of (quoting other people) 'very complex things'. It also does this without using any Win32 stuff. In order to be able to provide this kind of functionality for a Control that is written the way the .NET TreeView is (missing events and whatnot) the modification-code has to be 'injected' where the underlying TreeView exposes its 'vitals'.
This is why there is so much code for a lot of the exposed event handlers. And also for a lot of the functionality (where I thought it was important and where I could) I have emulated the TreeView 'to the pixel'.
There are also a lot of things that are not working in the original TreeView which now work in the MWTreeView.
If I did it again I would probably do a lot of things differently though.
You must also understand that this Control has been developed in two 'phases'. One phase a bit over a year ago. Then the new one in the last two to three weeks.
I am not the kind of person who remembers code I wrote a year ago (I have more important things on my mind).
Using the comments in the code for the MWTreeView I was however able to improve it something ridiculously during these last few weeks. Not only adding functionality, but also fixing bugs and improving it in a lot of places.
And if I could do it, anyone else could, using my code comments.
(See the comment from Soliant on the previous 'version' of the MWTreeView: http://www.codeproject.com/cs/miscctrl/mwcontrols.asp#xx823093xx.)
|
|
|
|
|
I'm with you Mikael.
There's a french expression that said "at given horse, don't look at saddle" 
So... sure that should be better if you explain your global idea behind your control ! But like you said, you already have spent so much time on it and if spending more, that will not give you something more.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
