I had a dream - multiple personalities

[tst]

I didn't read the entire thread, but you can probably save yourself a lot of time by using Property Saver, which basically does what you want, if I understand correctly, and should work as far back as LV 6.1.

[rmp]

Thanks tst,

But, nope, that tool does not save position information. I tried this test after downloading his tools:

 - run his "Generic Example"

 - save current properties (all controls)

 - stop program

 - move "button" control off of tab and on to main panel

 - run program

 - load saved properties

 - button did not move back to tab location

I'm hoping to find a tool that saves/loads the entire look & feel, without introducing duplicate controls/indicators. Here is a really simple example:

 - make a VI with two tabs (not one tab with two pages), a numeric control and a text indicator

 - place the numeric control and the text indicator on one tab

 - I'd like to be able to save that look & feel

 - now, move the numeric control and the text indicator to the other tab

 - if you loaded the saved look & feel, the numeric control and the text indicator would move back to the original tab location

 - note: other properties like color, size, fonts, etc would also be saved/loaded. And, there are some other special cases like what if a saved look & feel has (or doesn't have) a control or indicator as the current look & feel?

I'm thinking of this concept as "virtualizing the front panel": I'd like to be able to map a saved/virtual front panel into the current/actual front panel.

[Ben]

1) Different fixed layout to choose from (sub-panels)

2) Property node everything (from ini and use off-screen objects)

Are the standrd solutions. If you really want an unlimited set of options "on the fly" then I strongly urge you to forget the native FP object and implement your own that has the ability to be integrated as you desire. 

Now I realize I may be sounding like I am beating a dead horse but I have walked this path and want to share my experiences. So here are some diagrams that illustrate the way I implemented it. There are about 100 other diagrams that go with these but I can't give it all away.

Domain Model

RUI - is the top level app the user interacts with.

Picture - Active Object that handles mouse clicks on a picture control that fills the FP.

ObjMngr - Creates and destroys objects that are dropped on the screen. Handles all virtual connections (these are virtual virtual wires)

DB - Serves all I/O functions as if they are just a DB

Object - Any one othe available object developed for the app. Dynamic dispatch allows adding new object to an existing exe without changes to the exe.

Start-up

Loads and creates all of the support functions used to load, save and run "designs".

Load-Layout

Shows how a new design is loaded and started.

Note:

Although the above only illustrates two Picture controls (one for virtical display one for horizontal), the design was implemented to allow for an unlimited number of pictures (GUI regions) and different or coordinated designs can be loaded and running in each.

SO I could have one "design" running in one picture while I am editing another at the same time.

I hope that gives you something to chew on.

Ben

[rmp]

Ben,

Wow!.... I mean WOW!!!!!!!

More than my little brain can handle (it will take me a while to digest this).

My first thought is: it seems like you've created a "programming environment". In fact, if I've gleaned properly, it seems like you've created the Labview programming concept of "you get to place things on the front panel; move them around; and decide what plays with what".

If I've got this correct, then it seems that NI has also developed 90% of a similar environment (but they didn't give the end user as much control as the developer).

I'm thinking that NI has probably already developed 99% of what I want because they've already (probably) got the database of attributes for all controls/indicators. I'd like to keep/use the incredible Labview programming environment to develop/edit the different look&feels. And get access to the (probably) existing Labview look&feel attribute save/load functions. It seems like NI would do a MUCH better job managing this than I can. And, it seems like something that many developers would use. And... what a cool differentiating feature; that amplifies the benefits of a graphical programming paradigm (OK, sorry, now I'm baiting the marketing folks...).

[rmp]

I'm starting to think that a clearer description of what I'd like is the ability to:

- save  a front panel without any block diagram

- load a front panel and have it attach to a given block diagram (I think it's easier to think of the loaded front panel replacing the front panel that went with the block diagram).

- this implies that:

       - all block diagram controls/indicators are accounted for in the front panel (or errors get reported, like deleting a front panel control when there is block diagram use of it)

       - if I have front panel controls/indicators w/o block diagram use of them, then there will be no error reporting of this case

       - if I want to change control/indicator names, I can't; but I could use captions to make it look like names had changed (less geeky names, for example)

Message Edited by rmp on 04-15-2010 08:50 AM

[Ben]

---

rmp wrote:

Ben,

Wow!.... I mean WOW!!!!!!!

More than my little brain can handle (it will take me a while to digest this).

My first thought is: it seems like you've created a "programming environment". In fact, if I've gleaned properly, it seems like you've created the Labview programming concept of "you get to place things on the front panel; move them around; and decide what plays with what".

If I've got this correct, then it seems that NI has also developed 90% of a similar environment (but they didn't give the end user as much control as the developer).

I'm thinking that NI has probably already developed 99% of what I want because they've already (probably) got the database of attributes for all controls/indicators. I'd like to keep/use the incredible Labview programming environment to develop/edit the different look&feels. And get access to the (probably) existing Labview look&feel attribute save/load functions. It seems like NI would do a MUCH better job managing this than I can. And, it seems like something that many developers would use. And... what a cool differentiating feature; that amplifies the benefits of a graphical programming paradigm (OK, sorry, now I'm baiting the marketing folks...).

---

I used LV as my model but allowed for what LV did not support.

AS far as NI exposing the under-lying stuff. They have exposed scripting to let you get at tht stuff.

RE: getting at the tables under the hood

THat sounds like it would be an exercise in parsing data structures and would far less enjoyable than working with LV. You would have to pay me to do that project.

Ben

[tst]

---

rmp wrote:

Thanks tst,

But, nope, that tool does not save position information. I tried this test after downloading his tools:

---

I haven't dug deeply into the tool. A quick look indicates that it does have a reference to properties from parent classes and I assume it would be easier to expand on that existing code than to rewrite everything from scratch, but hey, it's your time.

[rmp]

Good point... worth pursuing. Thanks