merging FP of children class

[Ben]

Very nice!

How can I knock it, since I did the same?

But changes to the Parent "like only show one decimal point) would have to be duplicated in the Child's GUI as well. I was trying to imagine a way that the Child could use the parents GUI as part if its own GUI.

Ben

[elset191]

---

@Ben wrote:

Very nice!

How can I knock it, since I did the same?

But changes to the Parent "like only show one decimal point) would have to be duplicated in the Child's GUI as well. I was trying to imagine a way that the Child could use the parents GUI as part if its own GUI.

Ben

---

Yeah.  Adding another data item?  Add it to each and every subclass.  Changing the representation?  Change it in every subclass.

Not only that, but the code for each of my children classes is 90% the same.  Load the parents data, load your own data.  At the end, save the parents data, save your own data  (I think in 2009 you can do by reference stuff (right?) so it would be a lot easier, but still on 8.6 here).  New subclass?  Copy the code and change the operations for the child data. 

It's really a poor system I have, but I don't know any other way of doing it.

The following may be getting way off topic...

Back when I was trying to make an XControl for the class which would make a lot of this easier I found an example for dynamically changing xcontrols (here)  Like I said though, I never got to a point where I had one xcontrol, let alone one for each child class taht I would need to dynamically load.  This idea would probably help...

[Ben]

Ok thinking out-loud some more.

Parents know nothing about the children so the Parent can't load the child GUI it would have to be the other way around.

Children methods can call the parents  implementation of a method while still executing the same method (re-cursive calls) so it seems that over-rides are not our ticket either (beyond calling the right flavor for our class)

Still thinking...

Ben

[tst]

Anything wrong with my suggestion?

[elset191]

---

@tst wrote:

Anything wrong with my suggestion?

---

If I understood it correctly, the user would have to start by clicking the parent, and editing it.  Then click the child and edit it, and so on, correct?  Aside from involving clicking back and forth, which isn't really a huge deal, I'd prefer the user not know there's a class structure there that they have to concern themselves with.

[tst]

In that case, I would probably create a VI with N transparent subpanels (10 should probably be enough, although once you have the basic code, you can easily duplicate as many as you feel are needed). For each level, you place the subpanel in the correct position and resize it according to the size of the VI it displays. This way, you place as many SPs as needed one below the other and make all the others invisible. You then display that VI in one subpanel. What you should effectively get is a single display for all the levels, where each level is displayed below its parent, but without any visible barriers between them. Since it's a subpanel, you can place it in a limited area and have the user scroll to get down.

[JackDunaway]

For what it's worth, I've nested SubPanels before - a VI with a SubPanel that contains a VI with a SubPanel that contains a VI...

[Ben]

Hi Yair,

Wouldn't your approach require that the displayed GUI "KNOW" about all of the classes and would require updates when new children are added?

I ask because "Low Coupling" between classes is of interest to me lately.

Ben

[tst]

---

Ben wrote:

Wouldn't your approach require that the displayed GUI "KNOW" about all of the classes and would require updates when new children are added?

---

Not in advance. The structure would have to be fixed (events, making sure all VIs edit the same instance, etc.), but the actual content can be supplied dynamically. The actual config VI would belong to the specific class

To give a simple example, you can use a factory pattern which provides a list of animals: dog, cat, eagle, elephant, spider. You select one of these and pass it into the VI as a parameter. The VI calls Get Config VI Reference.vi on all the classes until it reaches LV Object, then builds them into a 1D array of VI refs.

So, if you selected dog, the listbox would give you Animal.lvclass:config.vi, Mammal.lvclass:config.vi, Canine.lvclass:config.vi and Dog.lvclass:config.vi. Things will become more complicated if you need to modify the class hierarchy from inside the VI.

This design is something I started working on a while back as The Hierarchy Config Dialog To End All Config Dialogs, but I haven't gotten around to finishing it yet, so there are all kinds of missing details.

[tst]

OK, so here's a quick and dirty example (2009). It shows both the concept of having a separate GUI in each class and of putting all of them together in a single dialog.

This specific example uses the one from the previous post and has three classes - Animal, Mammal (which is currently empty) and Dog. As you can see in the image, both the animal config and the dog config appear together.

The video demonstrates the usage - when I run the VI for the second time you can see that putting an Animal object into the VI only shows the config for the animal class:

Like I said, this was a quick and dirty example. It's extensible easily enough (you simply add more classes to the hierarchy), but I think I would prefer having the listbox, if only because it can simplify the code, because it can allow you to "check out" the object once at the start of the config VI and check it back in when you finish or switch to another VI. With all the VIs being displayed at the same time, you have to check out the object for every modification.