Can classes "make" controls and indicators "appear" on the front panel.

[Dominick_8.5]

This is what I was hoping to do. I would define a parent class called signal that was really just an interface class. All of the child classes, analog in, analog out, digital in, etc. would have to override the VI’s in the signal class. So, the first thing that the program would do is to read a text file line by line, and on each line there would be a tag telling the program which type of signal to create. Next the newly created signal would be casted up to the parent class and put into an array. Once I have my array of signals, on the front panel I would have an array of text boxes. The text boxes would be displaying the names of the signals. In a search text box, the user can type some of the characters that are in the name of a signal, and the array would reduce the list until the user finds the signal they want. Here’s what I can’t figure out. I wanted the user to click a button next to the text box, that is listing the name of the signal they wanted, and the controls for that type of signal would appear to the right of the text box. How do I make the controls appear to the right of the text box? The controls are basically an indicator for reading an analog input or several controls that allow for ramping or stepping an analog output or setting a digital output or reading a digital input, etc. I’m hoping that the class can “make” the controls and indicators “appear” on the front panel. Any suggestions?

Thank you!

 

[Jarrod_S.]

Do the controls and indicators you want to make appear depend on the type of signal child class created?

Your best bet is to use subpanels cleverly. Have a method in the parent called subpanel UI that you override in the child classes. In the overrided methods, put the controls and indicators that you want to display when a signal is selected. Then write some helper methods in the base class that make it very easy to insert a given child class's subpanel UI into the subpanel.

Finally, just put a subpanel in your top-level VI of your application next to the list with the signal types.

I've done this before and it worked really well. Let me know if this sounds promising.

Message Edited by Jarrod S. on 01-16-2008 08:04 PM

[Dominick_8.5]

"Then write some helper methods in the base class that make it very easy to insert a given child class's subpanel UI into the subpanel."

How do you do that? Are there any examples

Also, can you have the parent's subpanel UI VI inserted into multiple subpanels?

Thank you.

[Jarrod_S.]

I'm posting a simplistic example that demonstrates one method of using a class to dynamically insert VIs into subpanels based on which class was selected. There are really multiple ways of accomplishing this type of problem. I like this one, because it is easy to create multiple child classes after you go through the trouble of defining the interface in the parent class.

You can have as many child classes as you want, and each child class' Subpanel UI method can be loaded into a different subpanel at the same time. Right now this doesn't support having the same child loaded into multiple subpanels. We'd have to brainstorm that. The difficulty is that I use a class dynamic method for my VI that goes into a subpanel, and you can't make those fully reentrant.

Take a look at the example. I wrote it pretty quickly, but I hope it gives a basic idea of a strategy to take. Let me know what you think. (Written in LV85)


Message Edited by Jarrod S. on 01-17-2008 05:54 PM

[Dominick_8.5]

I understand the example, but

"Right now this doesn't support having the same child loaded into multiple subpanels. We'd have to brainstorm that. The difficulty is that I use a class dynamic method for my VI that goes into a subpanel, and you can't make those fully reentrant."

That's what I really need, having the same child loaded into multiple subpanels...

Any ideas?

Thank you.

[Jarrod_S.]

I think one solution would involve making the Subpanel UI VI itself not be a member of the class and not have dynamic class input and output terminals. The class would then have some member function that provides a path to the external Subpanel UI VI, or perhaps a reference to the VI. At that point, it would be safe to make the Subpanel UI VI fully reentrant, and you could have any number of copies of it loaded into separate subpanels.

There are a few things to consider here:

1. If the Subpanel UI VI isn't part of the class, it can't access private class data. It will need to use Accessor VIs rather than directly unbundling class data.
2. To open a reentrant copy of a reentrant VI using the Open VI Reference function, you will need to wire the value 8 to the Options input.
3. Find some way to keep track of all the reentrant VI references you open, so you can close them when they're not needed anymore. This will help prevent excess memory usage.

(After thought)

After rethinking my message, I think it might be a little easier to still have the Subpanel UI VI be part of the class, but it won't be inherited from the base class. Each class will have to manually create their own Subpanel UI VI, rather than overriding one from the parent class. Don't make this Subpanel UI VI dynamic, so that you can make it reentrant. That avoids problem number 1 listed above.


Message Edited by Jarrod S. on 01-21-2008 03:00 PM

[CharlyStardust]

Hi

Sorry to wake up a one year old thread.

I tried to add a third child class to Jarrod's example but I get an error that I can't fix so far.

Basically in the project manager I created a child C.lvclass then I changed its inheritance to inherit from the parent class. I also created a Subpanel UI.VI from the default template and saved it in a child C folder.

The main vi gets a broken arrow because of the Subpanel UI.VI  of the parent class.

I though I copied the connector terminals correctly but I have this error message on the Subpanel UI.VI  of the child C class: " This VI doesn't match other VIs in the method, Connector Pane Terminal(s) are different. All VIs that implement a method of a LabVIEW class must match Connector Panes. To correct this, compare Connector Pane of both this VI and the VI of an ancestor class that implements this method. "

I don't get what is wrong. I may have created the the Subpanel UI.VI  of the child C class in a different way than Jarrod.

I enclose Jarrod's example I'm trying to change.

Cheers

Charly

[CharlyStardust]

Message Edited by CharlyStardust on 01-14-2009 01:22 PM

[SMeserve]

Hi Charly,

I took at look at the ZIP file that you posted.  The problem exists on the Connector Pane of the SubPanel UI.vi for Child C.  As indicated in the error message you posted, the Connector Panes are not the same.  In classes A & B, there is an additional input, a message queue.  The Child C class VI does not have this input, so the connector pane does not match and the VI is broken.  Hopefully this solves your issue!

[CharlyStardust]

Hi Stephen,

Good catch, unfortunately it doesn't fix the broken arrow. I also change the object connection to "dynamic dispatch inputs (required)"

Could you try to create a child on this project? There is something I'm missing and I don't get it.

Charly