Bundle marked controls into class control and keep it synchronized

[GoofyWires]

Currently, if I want to create a class control that holds all the front panel controls from a vi I have to:

1. See that all the controls' labels has a single line name or else LV won't be able to create a property node to them.

2. Copy/Paste each control into the class control.

If this operation will be done automatically then I could replace all the references in my BD with a class wire that shares the status of the controls (and if it is a DVR class control then I could share it in parallel.

Moreover, if this class control could stay in sync with a chosen vi FP (add each control from the FP to the class control but let me add stuff to the class control) then is will be very easy to implement a straight forward Model-View-Controller.

[Mr.Mike]

I don't have any trouble creating property nodes for class members when there's a new line in the name.  Could you elaborate on why you need step 1?

[GoofyWires]

If you'll try to create a data member access vi to a control from the calss control that has a label with two or more lines then a vi will be generated but you won't be able to save it.

It took me a long time to understand the source of the bug since I generated many member access vis and just some of them had the problem while this bug wasn't documented at all.

The reason is that a property node name display can have just a single line. If you mark allow access through property node then LV will have a problem and it won't even report it, LV just won't allow you to save the vi.

[Mr.Mike]

Thanks for the clarification.  After your explanation I was able to reproduce the problem.  I filed the bug as CAR 353521.  Unfortunately, it's too late to fix for 2012, but we'll try to get the fix in a later version.  

[AristosQueue (NI)]

I'm glad Mike can help with the property issue. As for the rest of your idea... as far as I can see, it is impossible. Not hard, not tricky for R&D to write, but actually logically impossible.

Each object is an instance of a class. A class has a private data control. The objects *do not* have a private data control. There is no front panel associated with each object. An object's data consists of the fields defined by its class data plus all of the class ancestors, and none of the private data controls by itself even has enough fields to display. Giving every object its own front panel might be a useful debug trick, but that leads us to the real problem: objects are not references. If we, in theory, had a front panel for every object and you opened that panel, and then downstream you forked the wire, which fork would be the panel that is showing? The top fork object or the bottom fork object? Maybe we would open the panel of the forked copy. Now you have two on screen. Which one is linked to your actual user interface?

A LabVIEW object can describe the state of a front panel at a given moment in time, but it cannot ever *be* the ongoing state of a particular front panel because a particular front panel is not duplicated when the object is duplicated, and the objects are duplicated where ever the compiler decides that is needed.

If you have further refinements to offer, please do so, but without some changes to the basic idea as proposed, it cannot ever happen.

[GoofyWires]

Hi Aristos Queue,

thanks for the thoughtful reply!

The case I wanted to use this option for:

1. you have a vi outside of any class that contains FP controls.

2. the new option will wrap it inside a class calling it main vi while adding each FP control to the class control.

3. you could add controls to the class controls but it won't change main.vi.

4. if you add/remove/change a control in main.vi FP it will be added/removed/changed in the class control.

5. the class control is the first input of main.vi.

6. main.vi will work as Model-View-Controller while the FP is the View, the BDs are the Controller and the object instance of the class control is the Model. The FP controls won't be used as a DB anymore since it is not the Model.

7. thus, main.vi will work as a command design pattern template that will convert any access to its own FP with access to the object's data while the write properties (member access vis) will update the FP if needed.

8. the object instance of the class will be handled as a DVR of that and manipulated inside in place structures (in order to parallelize the gui loop and the command handling loop).

As for your concern regarding duplication of the object which will be disconnected from main.vi:

since main.vi is inside the class each object will have its own main.vi with its own FP state.

The problem is how do you tell LV that the object you wire in is the same as the object you wire out. In case we are not talking about class DVR the answer is simple, the object you send out has its own main.vi  and you had to code it correctly so there won't be any branching. If you are talking about class DVR then you have to use the block called "Preserve Runtime Class" and wire the input object to it assuming good writing style or else the user will lose some data.

I have a running example of that kind of MVC with class DVR that allows for inheritance and loading of FPs and thus disconnecting the BD/Controller implementation from the FP/View implementation. As long as a FP has controls with the same names it can be completely different (to achieve that I recursively searched the FP for all the controls).

The idea I posted here is to automate this process as an automatic template since I think it is very useful and can easily replace any spaghetti code automatically using a script.

I simply go over all the wires with FP references and turn them into a single class wire (one db running across any vi like a life line or the jugular vein).

The preliminary version can be found at Lavag:

http://lavag.org/topic/15331-mvc-through-class-control-feedback-required/

The current version uses better control design pattern, PropSaver (to save/load the control properties), popupmenus (for settings while using as little FP controls as possible while not using the FP as a data base), variant attributes for saving/searching the controls and LVLibP plugins into the UI Framework (each of the created classes is one of the modules/plugins that uses HAL).

If I want to add a logger, replay user actions, save/load FP state, error handler or any other function I will add it only to the parent MVC class and automatically it is added to all the modules.

Once this is automated a new user could design a FP and write vis that handle the commands+errors while understanding LV in a very basic level since the implementation will be invisible in the background or open for advanced users. 

If you want me to send you the current version tell me and I'll send you a zip file.

Respectfully yours

GoofyWires.

[GoofyWires]

Aristo Queue,

Reading your reply again I wonder if what you say is:

Once I have two instances of a class and each needs to add controls from its main.vi to the class and create data member access won't I have conflicts between the two instances?

My answer to this is:

Since this sync is done in edit time it is possible to add controls from an instance to its class and check if there is a conflicting control name in other instances while turning the class into a common OO db of controls.

As for "If we, in theory, had a front panel for every object and you opened that panel, and then downstream you forked the wire, which fork would be the panel that is showing?":

since each fork will have its own main.vi with a front panel that represents the state of the object and this main.vi is duplicated with each fork LV will have no problem since it simply depends on which main.vi you open. If main.vi wasn't inside the class you were completly right.

This is obviously not a simple idea exchange with a request for a comfortable usability configuration.

This is a tool I can post on Lavag.

However, only once it is integrated into LV it will accomplish its purpose which is: allow new LV users to benefit from the best practices without an expert to guide them and allow an easy upgrade to old legacy code.

[Jeff-P]

CAR 353521 discussed in this thread has been fixed in LabVIEW 2013. For a more complete list of bugs fixed in LabVIEW 2013, check the LabVIEW 2013 Bug Fixes. You can download an evaluation copy of LabVIEW 2013 at http://www.ni.com/trylabview/ or if you have an earlier version of LabVIEW installed and an active SSP subscription, you will be able to download the latest version of LabVIEW through NI Update Service.

Jeff Peacock

Product Support Engineer | LabVIEW R&D | National Instruments

[GoofyWires]

Thanks.

I have suffered from the class implementation in LV 2011 for the past year and a half.

For every change in the class I had to rename the class and rename it back again or LV would crash.

Glad to see it was fixed in LV 2012 and on but it would have been nice to get a fix to 2011.

I had to move away from classes and I hope to get back to them now.

[Darren]

Any idea that has not received any kudos within a year after posting will be automatically declined.