Reference Design

[durnek60]

Hi Experts!

I need some advice!

I've been developing LV over 5 years, using OO, singleton, DVR, Plugins, JKI tools in my apps. When I start my new project, I often make UML diagrams to create the backbone of my app, create parent - child classes in order to use override methods and so on...

But when I'm ready with methods, database functions and procedures I'm on the point on to make a connection between my top level methods and the top level vi's controls. i.e buttons, indicators and their prperties. I often use controls/indicators disable properties to keep my program on the right way to run.... ie avoid unexpected function calls and so on...

I'm using classes for modelling the real world item but I dont know what technque would be the best handling the top level controls.

For example, I've about 8 controls and 8 indicators. Some of them only visible on the specific point on my application state. But I think it is very annoying the handle these front panel items in my top level vi block diagram. I saw so many useful solutions and design patterns, but non of handling these controls / indicators references and properties.

Imagine a class, it's attributes and methdos modelling a car. Attribs: number of wheels, color, type, process_class... , Methods,: Move, stop,... and so on.

I wanna create a top level vi for handling cars. When I press the start button, Car class initialized but the car itself is not moving. I set another button to start its engine... When this car is started, I have to disable and grayedout the Car_Init button, in order to prevent my program to create a new car object ....

What could be the best way?

1.) Set these controls references as a class private data In the car class and handle these references on time when a specific method executed,

2.) Create a new singleton object that contains all of my buttons palced on the front panel, defining methods such as Car_Stated and palce this method a specific position on the diagram?

Both solution has so many advantages and disadvantages:

Advantages:

1.) Specify control propery can be handled on time when the right method run. ie: I hit start engine, And Set the the Init_car property disabled on the same vi, or a privete method in it....

2.) In OO desing I would create a class for Controls_ and define some methods for disabling and enabling controls ref. ie. Controls - Start_Engine.vi ( Enable Stop Engine Button Ref, and disable Init Car ref.)

Disadvantages:

1.) I think the control refenrce is not a neccessary attribute of the Car Class so why should I place about 4 or more control reference into my Car class???

2.) If I have a singleton or native LV class, control refrence handling , I have to specify all controls prpperty values in every method...

Conclusion:

I need some implementation desing or suggestion how can the labview professionals handle these things in labview?

I hope I was clear, and u can understand what I really want to say!

Thank you!

[Michael Aivaliotis]

I think it is very annoying the handle these front panel items in my top level vi block diagram.

Why is it annoying? What is your goal?

[jgcode]

What could be the best way?

1.) Set these controls references as a class private data In the car class and handle these references on time when a specific method executed,

2.) Create a new singleton object that contains all of my buttons palced on the front panel, defining methods such as Car_Stated and palce this method a specific position on the diagram?

Hi durnek60

I use a combination of both along with handling it directly on the BD depending on my requirements.

The only issue I can point out with Classes is that you cannot have a XControl reference as private data - well technically you can, but your build will break .

In those cases I therefore use a Class and a MFVI for the X-Control or just use a MFVI for everything.

Of course for small dialogs etc... where I feel I do not benefit greatly from encapsulation etc... then I do stuff straight on the BD cause its easier.

Cheers

-JG

[durnek60]

Why is it annoying? What is your goal?

Dear Michael!

Annoying is handling these properties on the block diagram...

My goal is to try to find a solution or technique how do other LV programmers handling controls prperties in large applications...

I'm sure that when u have a well structured SW implementation and about 15 controls/indicators, I don't think your block diagramm is full of with Visible/disabled porperties and some realsubVIs...

[Michael Aivaliotis]

I use methods and properties on the diagram all the time. However, I also use clusters or arrays of ctrl references passed into subVIs as well.

I don't think it's a good idea to manipulate UI objects from within a class unless the main purpose of that class is to manipulate the UI. Like a UI class.

In your example, I would create a method called Engine State. I would read that state, and if the engine was running, I would disable the button.

[durnek60]

I use methods and properties on the diagram all the time. However, I also use clusters or arrays of ctrl references passed into subVIs as well.

I don't think it's a good idea to manipulate UI objects from within a class unless the main purpose of that class is to manipulate the UI. Like a UI class.

In your example, I would create a method called Engine State. I would read that state, and if the engine was running, I would disable the button.

So, I would create a UI Class, and all the methods could be a predefined UI States (ie. UI Class - Engine State.vi with a flag isRuning) ....yes, its ok!

(last time I've used this technique and I would say it is ok, but I'm interested other developer's opinion)

MFVI? I'm not familiar with all acronyms.... Could you tell me some words about this?

[jgcode]

MFVI? I'm not familiar with all acronyms....

Multi-Functional VI (MFVI) aka Action Engine (AE) aka Functional Global Variable (FGV) that does more stuff etc...

[ShaunR]

Multi-Functional VI (MFVI) aka Action Engine (AE) aka Functional Global Variable (FGV) that does more stuff etc...

You made that up What you meant was LTWAC (Lazy To Write A Class)

[durnek60]

You made that up What you meant was LTWAC (Lazy To Write A Class)

I've never heared this synonym for Action Engine...

[jgcode]

You made that up What you meant was LTWAC (Lazy To Write A Class)

lol... no, it's (MFVI) NI terminology but I like it.

[Michael Aivaliotis]

...In those cases I therefore use a Class and a MFVI for the X-Control or just use a MFVI for everything.

Really? You write Mutha Fucken VIs too?

I write VIs Mutha Fucka (VIMF)

[jgcode]

Really? You write Mutha Fucken VIs too?

I write VIs Mutha Fucka (VIMF)

lol... that deserves a beer.

[ShaunR]

Really? You write Mutha Fucken VIs too?

I write VIs Mutha Fucka (VIMF)

Yup. well worth a rofl point. I have seen quite a few of those VIs.

Edited April 24, 2011 by ShaunR

[PaulL]

In keeping with the Model-View-Controller paradigm we separate the View from the Controller/Model, so our Model classes do not have references to the View elements. (Disclaimer: We do have at least one exception, but that is not important here.) The View communicates via the Observer Pattern (so that we can replace the View with another view or even a separate subsystem).

In practice, we use network-published shared variables (generally) to handle the publish-subscribe communication (i.e., the Observer Pattern). In practice, the indicators on the view change behavior when the state of the system changes operational state, so in our view code we register for a shared variable value change event on the state shared variable. When this changes (i.e., the event fires) we update the appearance of the controls and indicators accordingly (either on the view diagram or delegated to subVIs, e.g., in a View or <ViewElement class>, as appropriate). Updating values on indicators we can usually accomplish simply by binding to the matching shared variables. (If we have to transform the data for display purposes we register for the appropriate value change event and then do the calculations when the event fires.) (More advanced comment: Note that you can actually put the behavior for a specific type of element into class methods and pass a reference for a specific view element to the object, hence arriving at a view that is truly a Composite of individual elements.)

In the opposite direction, when a user clicks a button, this triggers a control value change event, and the code to handle the event sends the appropriate message to the Controller.

The resulting Views only "care" about the data to send and receive and interact directly only with the shared variables (which makes them easy to test, even without the actual system in place).