Isolate parts of a system in subVis (Architecture for large application)

[Mark_Yedinak]

Once you start using control references you have a tightly coupled system. Use a messaging/event based system. As I suggested before, use messages/events to pass commands and data between the subtasks, the things really doing the work, and the UI. Don't worry about what the UI looks like when developing your working tasks. SImply define what needs to be done, what commands it needs and what data  it will generate and report outside itself. All these items should be a message which is passed via queues or events. The UI is just a presentation to the user. It can be defined later. The approach I am suggesting also allows you to reuse components easier, change the UI to fit the users' needs and not result in having to change your subtasks. If you are using control references your ARE NOT decoupling your code.

[YannickB]

---

@Mark_Yedinak wrote:

Once you start using control references you have a tightly coupled system. Use a messaging/event based system. As I suggested before, use messages/events to pass commands and data between the subtasks, the things really doing the work, and the UI. Don't worry about what the UI looks like when developing your working tasks. SImply define what needs to be done, what commands it needs and what data  it will generate and report outside itself. All these items should be a message which is passed via queues or events. The UI is just a presentation to the user. It can be defined later. The approach I am suggesting also allows you to reuse components easier, change the UI to fit the users' needs and not result in having to change your subtasks. If you are using control references your ARE NOT decoupling your code.

---

Yes, I'm aware of that and this is the approach I have. I actually abandoned the control reference, I was just testing the possibility seeing if it might work.

However in my case I'm not in the design phase and this is at the core of my problem. I have to move code that is already written into subVI and make an architecture for the whole system. I cannot rewrite everything as it would take too much time.

Doing that, the subpanel solution would have been absolutly perfect... if only it was not real-time.

[Ben]

Yes Sub-panels not supported under RT.

If you are looking to simplify the Main VI you can use  GUI Controller for all of your control refs (this is an AE that holds the control refs and optionally act on then eg. Init.) and sub-VI that use dynamic event registration.

Look at the images in this album for some ideas.

If I have some part of my GUI that has related controls I will create sub-VI to handle the work associated with that work. Example: "Config screen" tab.

I admit the sub-VI are tightly coupled but code on the Main to do exotic screen manipulation is as well. Pushing that code down into a sub-VI to support the GUI can really clean-up the top level VI.

The code I posted in this (old) thread demonstrates how to "un-Dock" portion of a GUI using a sub-VI to do all of the dirty work. Please note that code uses a sub-Panel for the demo so just ignore that detail and look at dynamic event registration.

So investigate Dynamic Event registration in a sub-VI.

Ben

[wiebe@CARYA]

---

@Mark_Yedinak wrote:

Once you start using control references you have a tightly coupled system. Use a messaging/event based system. As I suggested before, use messages/events to pass commands and data between the subtasks, the things really doing the work, and the UI. Don't worry about what the UI looks like when developing your working tasks. SImply define what needs to be done, what commands it needs and what data  it will generate and report outside itself. All these items should be a message which is passed via queues or events. The UI is just a presentation to the user. It can be defined later. The approach I am suggesting also allows you to reuse components easier, change the UI to fit the users' needs and not result in having to change your subtasks. If you are using control references your ARE NOT decoupling your code.

---

Well, yes. If you have a graph manager, it is coupled to a graph. That does not have to be such a bad thing as you make it sound.

The other approach, sending events, and then handling those events by updating the controls is still coupling. you're also potentially exposing implementation details (data), which might be worse. This is all very dependent on the exact situation.

When you have coupled the control in a class, and you have 200 graphs, that would actually be easier to copy and reuse then the approach you are describing. You'd have to copy one event from an event structure from the source, and paste it in another event structure of the destination.

I just don't think it's as black and white as you describe. All has to be done in good consideration, and some coupling can be better then avoiding all coupling at all cause. Some middle ground has to be found.

In my application, it would be virtually impossible not have references in classes to manage the UI. There are simply too much different controls and visualization options to handle them in the main without a complex class hierarchy. So even if I got messages from other 'decoupled actors', I'd still need classes to be coupled to the control references.

"The UI is just a presentation to the user. It can be defined later." only works in some projects. If the application leans heavily on the UI, this is a terrible idea.

It all depends...

BTW. Material better discussed over a beer. Not easy over a text medium... No need for a flame war.

[YannickB · Accepted solution]

To sum up this thread and give a solution.

I used to solutions to solve this problem (depending of how the subsystem was written to migrate as easily as possible :

- Event/notifier with AE inside of the subvi. (solution is described in previous answers)

- Control references, with the control in a typedef file.  (http://www.ni.com/example/28769/en/ )