|
|
Home » U++ Library support » TreeCtrl » hierarchical tree data structure & binding to TreeCtrl
hierarchical tree data structure & binding to TreeCtrl [message #12445] |
Thu, 01 November 2007 08:35 |
solareclectic
Messages: 2 Registered: November 2007 Location: USA
|
Junior Member |
|
|
I've a few questions/ideas I'd like to bounce of those more experienced with U++...
I've more than a few applications to write that all want to have a hierarchical tree-like data structure as their primary structure. I see that TreeCtrl has the Key/Value (which, handily, take a Value) and all the requisite add/remove/count/find child/parent functions that one should expect in a Tree. At first glance, I thought I'd use whatever TreeCtrl inherits from- expecting to find a "Tree", to which Tree"Ctrl" then added all the GUI aspects; but, alas, I find it all in TreeCtrl.
Now, it just so happens that these tree data structures are, in fact, meant to be directly manipulated by the user; and it would be the simplest matter to just use the TreeCtrl directly as the data structure and add/remove my various other objects into the Key/Value "Values," using .Is() to determine the class of object that had been stuck in to a Node previously, and ValueTo<MyObject> to get them out and call their functions.
Perhaps there is an easier way, still, to call functions of their common base class with out doing the ValueTo<MyClass> bit?
I had tried making my common base class "Rich," but wasn't entirely successful, and wasn't sure it was actually necessarily any easier.
Now, to the real question... I'm looking for an obvious way to keep that Model/View/Controller separation that we've all been compelled to accept as gospel. I find no compelling reason (for my applications) or examples of TreeCtrl keeping the MVC separation with an datastructure internal to the application (the filesystem is an external datasource providing hierarchy, an other sample populate it with assorted labels - but no "linking" to internal datastructure). Can I just use TreeCtrl as my datastructure, as it provides all the functionality that I require, including the GUI stuff? Or if MVC separation must be maintained, is there a harm in using two TreeCtrls - one for the View, and one for the Model that just never gets shown?
And, a bonus question... (though for different widgets)
Since I'm taking shots a MVC separation anyway, I'm finding a similar situation with U++ nifty EditField derived widgets, which have all of the range/notNull checking, etc. that I want on to protect my Model object fields from getting set incorrectly, from the GUI or otherwise. If I want to keep, say, an Int datamember in one of my objects AND I want the user to manipulate it, why wouldn't I declare that datamember as EditSpin, instead of Int? Then when I want to present it to the user for editing, I simply have it draw itself?
Are there major performance/memory issues with this behavior?
Now I do, honestly, understand and respect the value of MVC separation, but since U++ has so conveniently packaged obviously useful behaviors together, I thought I should ask you all to see if I'm just making things harder on myself and overlooking the obvious "U++ Way" of doing things.
Thanks for any insight any of you can provide regarding best use of U++. Regardless of this answer, U++ has restored my interest in programming for FUN again.
shannon
|
|
|
Re: hierarchical tree data structure & binding to TreeCtrl [message #12635 is a reply to message #12445] |
Sun, 11 November 2007 23:38 |
|
mirek
Messages: 13975 Registered: November 2005
|
Ultimate Member |
|
|
[quote title=solareclectic wrote on Thu, 01 November 2007 03:35
Now, to the real question... I'm looking for an obvious way to keep that Model/View/Controller separation that we've all been compelled to accept as gospel.
[/quote]
Well, I am afraid, if you are looking for rigid MVC model, you are in the wrong place here...
Quote: |
Can I just use TreeCtrl as my datastructure, as it provides all the functionality that I require, including the GUI stuff? Or if MVC separation must be maintained, is there a harm in using two TreeCtrls - one for the View, and one for the Model that just never gets shown?
|
Actually, why should your model be another TreeCtrl?
Make a real model and refill (or modify) TreeCtrl as required...
Quote: |
And, a bonus question... (though for different widgets)
Since I'm taking shots a MVC separation anyway, I'm finding a similar situation with U++ nifty EditField derived widgets, which have all of the range/notNull checking, etc. that I want on to protect my Model object fields from getting set incorrectly, from the GUI or otherwise. If I want to keep, say, an Int datamember in one of my objects AND I want the user to manipulate it, why wouldn't I declare that datamember as EditSpin, instead of Int? Then when I want to present it to the user for editing, I simply have it draw itself?
Are there major performance/memory issues with this behavior?
|
I am not quite sure I understand the question. Anyway, maybe the answer is that U++ is desgined in a way that you usually do not need have "variable-widget" pairs (using variable to store the data, only use widget for GUI interaction). You do not need the variable, you can store the data directly in widget. You can even think about widgets as "value with possible GUI editing"...
I guess this also replies your "second TreeCtrl" question.
In short, using U++ widgets for other purposes is OK
Mirek
|
|
|
|
|
Re: hierarchical tree data structure & binding to TreeCtrl [message #12764 is a reply to message #12668] |
Thu, 15 November 2007 05:46 |
|
mirek
Messages: 13975 Registered: November 2005
|
Ultimate Member |
|
|
Novo wrote on Mon, 12 November 2007 14:56 |
luzr wrote on Sun, 11 November 2007 17:38 | I am not quite sure I understand the question. Anyway, maybe the answer is that U++ is desgined in a way that you usually do not need have "variable-widget" pairs (using variable to store the data, only use widget for GUI interaction). You do not need the variable, you can store the data directly in widget. You can even think about widgets as "value with possible GUI editing"...
|
I think that separation of concepts (like graphical data representation and data itself) is very useful. Developing something more or less complicated without that is hardly possible.
|
Hey, only because you CAN do something does not mean you HAVE to do... There obviously are scenarios where it is better not to store data in the widget:)
(This is the same as some people insisting that you cannot allocate U++ widgets on the heap. Of course you can, but unlike other toolkits, you are not required to).
Quote: |
Making clear separation of concepts requires a lot of experience in software design. That is not easy. But using good designed software is real fun !
|
Well, I just think that sometimes, people go over the roof here. Obviously, in some cases the separation is the right thing to do, but to do it always only leads to added complexity without any real benefit to the program reliability or user experience.
Mirek
|
|
|
Re: hierarchical tree data structure & binding to TreeCtrl [message #12765 is a reply to message #12764] |
Thu, 15 November 2007 08:27 |
|
Quote: | Well, I just think that sometimes, people go over the roof here. Obviously, in some cases the separation is the right thing to do, but to do it always only leads to added complexity without any real benefit to the program reliability or user experience.
|
Amen
PS: That should be my 666 mesage on this forum..
|
|
|
Re: hierarchical tree data structure & binding to TreeCtrl [message #12821 is a reply to message #12764] |
Mon, 19 November 2007 15:10 |
Novo
Messages: 1358 Registered: December 2006
|
Ultimate Contributor |
|
|
luzr wrote on Wed, 14 November 2007 23:46 |
Hey, only because you CAN do something does not mean you HAVE to do... There obviously are scenarios where it is better not to store data in the widget:)
(This is the same as some people insisting that you cannot allocate U++ widgets on the heap. Of course you can, but unlike other toolkits, you are not required to).
|
I think that is a little bit different. If you cannot allocate U++ widgets on the heap, that is a design decision, which won't affect performance.
If you have to allocate hundreds megabytes of RAM every time you want to show your data, that is different.
If a widget (I mean ArrayCtrl) has an API to retrieve data, one can implement an algorithm, which won't keep all data in memory. That will let to display data tables with billions of records without significant memory impact. And memory allocation/deallocation never was fast (probably not in U++ ). And data sorting can be moved out of the widget. IMHO it should be moved out because there are too many ways to do that.
The same with trees, although they usually much smaller than tables. But I can imagine situation when one wants to display whole gene ontology in a tree widget. And it is vvvvveryyyyyy big.
May be I'm wrong, but ...
And I do not want to say that data containers, which are built into widgets, is a bad idea. In 95% of all cases they are the best solution.
Regards,
Novo
|
|
|
|
|
Goto Forum:
Current Time: Fri Apr 26 00:37:19 CEST 2024
Total time taken to generate the page: 0.97885 seconds
|
|
|