I had a dream - multiple personalities

[rmp]

Thanks tbob,

I snooped around Labview a bit, and read a bit on config files, so I understand (basically) what you're saying.

But, I think this would only work if you want front panel objects to appear/disappear, or change other visual attributes.

In my case I want to move some of the objects, say from one tab to a different tab (get them off of the geeky tabs, and move them to more end-user friendly tabs). I see that there is a property for "owner" of a front panel object. I'm not sure yet what "owner" is, but I suspect that it MIGHT be what I'm calling the nearest parent (ie. the tab and tab-page where the object resides). But, this property is read-only, so I wouldn't be able to programmatically move an object from one tab/page to a different tab/page.

[tbob]

I'm not sure if you can move controls from one tab to another.  I don't think you can do it.  But you could create multiple controls and hide the ones you don't want to be displayed.  Like a Numeric1 on tab1 and a Numberic2 on tab2.  Just hide the control on one tab and make it visible on the other tab.  But then you have to write your code to accept the value of the one that is visible.  A real pain.

It may be best to just create different subiv's with the tab controls you want for different situations, and just call the proper subvi.

[rmp]

I don't think the different VIs approach is practical, because that's essentially the "duplicate" set of objects approach. That forces duplicate code which is harder to maintain.

It seems that Lavbiew already has to build this database as you create the front panel. So, it seems like this might most easily fall in their domain. Maybe I'll suggest it and see what happens. I think what I'd be asking for is a front panel database sync function:

 - user provides an input data basefile

 - database sync function then does:

   - for all input objects that don't exist in the current database, create the new objects

   - for all input objects that exist in the current (internal memory) database, change the current database to match

   - for all current objects that are not specified in the input database, do nothing

And, I also want a "save current database to file" function.

I think that would do what I want... am I right? 

[tbob]

Yes, suggest it as a product enhancement.  NI would have to work out the details if they decide to implement it.

[MikeS81]

Hi rpm,

i use different front panels to realize it. The advantage is, that you have the full power of LabVIEW to create the different FrontPanels and you don't need large config file to store control positions or other properties.

I wrote a GUI handler which reads the assigned Front Panel refnums. For all Controls i create dynamically Event refnums to react on the value change or what ever events. For all indicators i store the refnums to change values and properties.

The Front Panel the User will see in the Program contains less to no logic. The only logic is an event structure to keep the vi running after loading or to visualize the button press events.

I assign the real function by the control names. If a value change event occurs, i read the name of the control and send a queue command to the logic which is responsible for this command.

Maybe it helps

Mike

[Ben]

---

rmp wrote:

I don't think the different VIs approach is practical, because that's essentially the "duplicate" set of objects approach. That forces duplicate code which is harder to maintain.

It seems that Lavbiew already has to build this database as you create the front panel. So, it seems like this might most easily fall in their domain. Maybe I'll suggest it and see what happens. I think what I'd be asking for is a front panel database sync function:

 - user provides an input data basefile

 - database sync function then does:

   - for all input objects that don't exist in the current database, create the new objects

   - for all input objects that exist in the current (internal memory) database, change the current database to match

   - for all current objects that are not specified in the input database, do nothing

And, I also want a "save current database to file" function.

I think that would do what I want... am I right? 

---

THat is basicly what I did in my "controls on the Fly" app. Like I said, took more than 1000 VIs to implement. The bonus I got out of it is I can change it and it was written to handle multiple GUIs.

Ben

[James_W]

From what I can see here there are still two fundamental options open to you if you want to do this now:

1) Create different Front panels and pass the data into a common cluster which is handled by a piece of core code which sits inside all of your front panels (bundle by name) - this could be fairly easy to implement depending on what your code does. (have all of the code in the frontpanel VI as a subVI and pass either the values or references to the controls)

2) Use the config file option. You can get around the issue you have of Tab controls by creating a few customised controls that look like tab pages, or even using a large container and a set of (empty?) string controls at tab selectors. Clicking on a "Tab" will cause the program to display the contols on that "Tab" only, inside the container. You can then programmatically resize and position all of your controls, and as long as you are careful, only the selected controls will be visible when you want them to be. (You have just eliminated all conatainers so have no owners issue). This option may be easier to maintain the block diagram of, but the front panel will be VERY messy. (You may even be able to get away with 1 enum and no config file if you want to hardcode all of the control and indicator positions).

However you do this, if will be complacated.

Tip 1: If you want a container that can disappear in some cases, use a system string control with no text, shade the border and make the background transparent.

Tip 2: The last control/indicator acted upon with a property node is the topmost on the front panel at any given point, no matter what you specified when you layed out the front panel. - think about the order you in which you "touch" controls when doing this.

James

Message Edited by James W on 04-14-2010 01:48 PM

[rmp]

Hi Mike,

Thanks for the ideas. I was thinking about this approach also. The idea (if I've thought about this correctly) is to completely separate the front panel from the code function.In the client/server model, the GUIs are the clients and the code is the server. In between is a GUI handler. Multiple GUIs write to server controls. Server controls drive the code function. When the code needs to display info, the code writes to server indicators and then the GUI handler copies the server indicators to client indicators (or "active" client indicator). This allows changes to the code (server) without worrying about multiple GUIs (clients). And,new GUIs can be added by adding events to the GUI handler. That's a pretty straight forward approach, if implemented from the beginning.

But, it seems that another approach to the problem (which I was hoping to find) is to virtualize the front panel. Different front panels could be mapped into a "working" set of controls and indicators. This allows you to use Labview to edit existing front panels into new/additional GUI configurations. The weakness of this approach is that you can't add new controls or indicators because the underlying code will not "see" them. But, perhaps the client/server approach has the same weakness (it can be handled in each case, but is a "special case").

[MikeS81]

Hi rpm,

i don't see these problems with the client/server solution, because the function should be the same or a subset with different front panels. So normally it should handle only specific cases.

If you need more flexibility, then you can combine the different front panel with changeable "logic" vi's. I do this to communicate to different HW I/Os. I use a handler for the hardware and a handler for the GUI. The GUI handler sends the commands to the defined HW handler and make what ever is defined. If the process is ready then if a result exists, this will be send back and the GUI handler redraw the control.

Mike

Message Edited by MikeS81 on 04-14-2010 03:33 PM

[rmp]

Yup, Mike, you're right. You can not only handle the GUI as a client/server, but HW IO devices can also be clients through an appropriate client/server handler.

And, if we need new functionality in the server, then:

 - in your approach, you write that into the server and add any needed front panel objects in the required GUIs (requires minor GUI handler mods)

 - in my approach, the "working" set of code would be modified, and any needed front panel objects would have to be added to the various GUIs.

So, it still seems like the idea of mulitple look/feels could be handled by the programmer (develop a client/server structure to the block diagram) or by Labview in the form of virtualized front panels. Although I like your approach, I'm wondering if the block diagram looks "cleaner" with actual controls/indicators instead of references (or are they signaling properties in the case of indicators?). And, would one approach be quicker to develop and maintain over the other?