Are XControls In or Out?

[Karl Rony]

I am working on an application to simulate eight pieces of plant equipment. I've started down the path of traditional VIs and controls as I'm most comfortable with this approach. The simulated equipment has a simple user interface of number, enumerations, and Boolean lights. OOP could work, but I've haven't worked with LVOOP yet. An XControl could work and I've programmed one of these before.

If I were to experiment with another approach other than traditional VIs, should I learn more about XControls? Would I be better off learning LVOOP instead of XControls?

Thanks for your help,

Karl

[Mark Yedinak]

I would say that both are valid technologies to learn and are not replacements for each other. X-controls are a method for developing complex custom controls. LVOOP, or more appropriately, OOP is a design methodology for developing systems. Objects do not have to be controls on the user interface and are used to encapsulate your system designs into reusable objects. An object is a representation of some item in your system that encapsulates all the data for the object as well as the methods, or operations, on that object. One could argue that an X-control is a specialized user interface object but it should not be viewed as a replacement for LVOOP by itself.

[LAVA 1.0 Content]

We have build XControls on top of LVClasses, where the data was sent in other VIs and representent in the XControl.

Ton

[shoneill]

Having never successfully programmed an XControl, I'd say they are pre-destined to become the UI representation of a LVOOP Class. I think they complement each other perfectly.

LVOOP by design doesn't HAVE a UI component (Not directly anyway). I think an XControl for a LVOOP class is a very good extension of LVOOP abilities.

Again, I might be way off.

Shane.

[jdunham]

QUOTE (shoneill @ Dec 17 2008, 08:35 AM)

Having never successfully programmed an XControl, I'd say they are pre-destined to become the UI representation of a LVOOP Class. I think they complement each other perfectly.

LVOOP by design doesn't HAVE a UI component (Not directly anyway). I think an XControl for a LVOOP class is a very good extension of LVOOP abilities.

I think this is right on, but when I tried to make my first XControl, and having about 15 years of LabVIEW experience, it took at least a full day or two to get it working to my satisfaction. I could easily see spending a week or more on a moderately complicated control, even after getting familiar with the tool. I see lots of benefits for making reusable UI components, but I think the economics don't justify making a lot of XControls. I would love to hear any success stories, though. Anyone?

Bringing this back to the original question, I would focus on OOP first, since it can change the way you think about programming, usually for the better.

[Mark Yedinak]

QUOTE (jdunham @ Dec 17 2008, 12:22 PM)

I see lots of benefits for making reusable UI components, but I think the economics don't justify making a lot of XControls. I would love to hear any success stories, though. Anyone?

I have a fairly complex X-control that has been very useful for us. My team and I write application to test printers which support different communication interfaces. We built a communication class that handles all of the various interface types (built on top of VISA) and therefore allows our applications to work with all the interfaces seamlessly. As part of our user interfaces we need a clean selection process for the user to configure the specific communication interface. The X-control that I wrote supports this. In the past we had to have multiple controls for all the various parameters and code to hide or show what was relevant. the X-control made it very easy for us to do this. In our new application we simply dropped the one control and we were ready to go.

[Val Brown]

QUOTE (Karl Rony @ Dec 17 2008, 07:18 AM)

I am working on an application to simulate eight pieces of plant equipment. I've started down the path of traditional VIs and controls as I'm most comfortable with this approach. The simulated equipment has a simple user interface of number, enumerations, and Boolean lights. OOP could work, but I've haven't worked with LVOOP yet. An XControl could work and I've programmed one of these before.

If I were to experiment with another approach other than traditional VIs, should I learn more about XControls? Would I be better off learning LVOOP instead of XControls?

Thanks for your help,

Karl

I can only reply from my perspective, which I suspect will be quite a bit different from the majority of responses you will hear from other LAVA members.

If it were me, I would stay away from both OOP and X-Controls.

I'm not saying that because I think OOP and/or X-Controls are "bad" in some way. I'm sure they're wonderful and very useful, esp in tandem. It's just that my experience has been with traditional LV dataflow and that's what I feel most comfortable with at this point. I've heard a lot about OOP and "getting the classes right" and how easy that makes the rest -- and truthfully, it probably does. But I've also not seen the value for me in learning OOP and translating over everything that I've done over the last 10 years of LV programming. Then again, I don't need to create reuseable controls to distribute for use by other programmers on a team. I'm a one man operation who sub-contracts at times for others to implement small sections of my code.

I've long been concerned that the push for OOP etc will become an aspect of LV losing its central orientation and commitment to dataflow as it has been done since the beginning of LV. I hope that isn't lost but, then again, I also hoped that complete crossover of code between Mac, Windows, etc wouldn't be lost either. Perhaps that will come back but until then, I'm a bit disheartened by the continued push to OOP and Windows at the expense of the traditional dataflow and cross platform ideal of LV.

[jdunham]

QUOTE (Val Brown @ Dec 17 2008, 11:24 AM)

I'm not saying that because I think OOP and/or X-Controls are "bad" in some way. I'm sure they're wonderful and very useful, esp in tandem. It's just that my experience has been with traditional LV dataflow and that's what I feel most comfortable with at this point. I've heard a lot about OOP and "getting the classes right" and how easy that makes the rest -- and truthfully, it probably does. But I've also not seen the value for me in learning OOP and translating over everything that I've done over the last 10 years of LV programming. Then again, I don't need to create reuseable controls to distribute for use by other programmers on a team. I'm a one man operation who sub-contracts at times for others to implement small sections of my code.

I've long been concerned that the push for OOP etc will become an aspect of LV losing its central orientation and commitment to dataflow as it has been done since the beginning of LV. I hope that isn't lost but, then again, I also hoped that complete crossover of code between Mac, Windows, etc wouldn't be lost either. Perhaps that will come back but until then, I'm a bit disheartened by the continued push to OOP and Windows at the expense of the traditional dataflow and cross platform ideal of LV.

Well at risk of both a thread hijack and a mild flame war, I suggest you take another look at LabVIEW's built-in OOP (usually called LabVOOP). It's pure dataflow. You could also call it clusters on steroids.

As I see it, it adds two features. One is to hide the implementation (i.e. the messy details) of each component of your code from the others. This makes it more likely to avoid bugs, because without this, it's very easy to change a subvi or a typedef and have it break some other code which you were not paying attention to at that time.

The other benefit is dynamic dispatch. If you've ever passed data in a variant (or a binary string, or a cluster with optional fields), and then accompanied that with an enum which tells receiving code how to unpack the variant, then you are better off using LabVOOP/Dynamic Dispatch because it does the same thing with less code and less chance for error.

[LAVA 1.0 Content]

QUOTE (jdunham @ Dec 17 2008, 07:22 PM)

I would love to hear any success stories, though. Anyone?

I have written an XControl for a colleague of mine in rather short time, which we later promoted to be part of our standard library, the most flattering thing he said was 'I didn't even want to look inside the XControl, it just worked'. And there is the catch-line, with XControls you are reducing a lot of code into one control with properties and method.

If you think about the graph and chart as they are currently available, think how they would be in native LabVIEW code... If you would have to do the housekeeping of data, properties, alignments, visibility of items. All these things can embraced by XControls. So my answer would be 'XControls are in', way in.

If I look at the different XControl applications to the http://forums.lavag.org/downloads.html' target="_blank">LAVA CR the diversity of coding styles inside those are good learning points, you see a lot of different styles.

Ton

[Aristos Queue]

QUOTE (shoneill @ Dec 17 2008, 10:35 AM)

Having never successfully programmed an XControl, I'd say they are pre-destined to become the UI representation of a LVOOP Class. I think they complement each other perfectly.

LVOOP by design doesn't HAVE a UI component (Not directly anyway). I think an XControl for a LVOOP class is a very good extension of LVOOP abilities.

Again, I might be way off.

You're not way off.

QUOTE (jdunham @ Dec 17 2008, 12:22 PM)

Bringing this back to the original question, I would focus on OOP first, since it can change the way you think about programming, usually for the better.

I agree. The XControls are useful only for UI heavy projects. Classes start becoming useful about the same time "Create SubVI from Selection" is useful, and for many of the same reasons.

[Phillip Brooks]

QUOTE (shoneill @ Dec 17 2008, 11:35 AM)

Having never successfully programmed an XControl, I'd say they are pre-destined to become the UI representation of a LVOOP Class. I think they complement each other perfectly.

LVOOP by design doesn't HAVE a UI component (Not directly anyway). I think an XControl for a LVOOP class is a very good extension of LVOOP abilities.

I've created some XControls, but never an LVOOP class. I agree that these seem to be complimentary tools

I like Jeff Atwood's "Understanding Model-View-Controller" blog post. We create and use the MVC pattern all the time and don't even think about it.

QUOTE

Skinnability cuts to the very heart of the MVC pattern. If your app isn't "skinnable", that means you've probably gotten your model's chocolate in your view's peanut butter, quite by accident. You should refactor your code so that only the controller is responsible for poking the model data through the relatively static templates represented by the view.

The power and simplicity of properly implemented MVC is undeniable. But the first step to harnessing MVC is to understand why it works, both on the web, and also within your own applications.

LabVIEW 8.6

LVOOP

represents the

Model

XControl

represents the

View

Front Panel

represents the

Controller

We can use older techniques to do accomplish the same things

LabVIEW 7.0

Action Engine

represents the

Model

Brat* VIs

(sub-vis w/ control references) represents the

View

Front Panel

represents the

Controller

(w/ brat code additions)

*(Ask Norm what a brat is)

[LAVA 1.0 Content]

Re: Graph/chart similar to XControls

QUOTE (Aristos Queue @ Dec 18 2008, 08:23 PM)

You're not way off.

...

Finally admitted in public! I was convinced when I saw some of the bugs in the new version of the LV objects that came with LV 8+ that those would be bugs I would have wriiten if trying to implement graphs/charts/tables myself.

I have experience with XControls and LVOOP but not what I was concider a lot. They have both served well but I have never managed to combine the two in a single app.

I found working with both a good mental exercise. XControls require I think about how to do things "on a shoe string" (refs and terminals only) but still maintian good performance.

LVOOP forced me to change my model for thinking about my functions (where is the data?) but once it started to click, I found myself delivering 2.5 as many classes as the customer originally required*.

Re: "all this talk of OOP..."

I have sensed the same vibes. It feels a little like being a hockey player in a meeting for a figure skating team. "What is with all this talk of perfect figure eights? Just bash the competition into the boards and skate right pass them!" I listen in on the OOP discussions since they "help me expand my repertoire" (maybe I can do a figure eight to get around that defense man).

American Football Story

Back when the Steelers wone their first 4 Superbowls, Lynn Swann was blowing away people with his arobatic catches. It ws common knowledge here in the 'burgh that he had studied ballet as a youth.

And if the OOPish talk just becomes too much, switch over to the Dark-Side for a while. They hardly know how to spell LVOOP over there.

Ben

[Aristos Queue]

QUOTE (neB @ Dec 19 2008, 08:57 AM)

I have experience with XControls and LVOOP but not what I was concider a lot. They have both served well but I have never managed to combine the two in a single app.

Nor have most people succeeded in that domain. Could it be that some crucial connection between the two is missing? Does it feel, perhaps, unfinished...? If it feels that way, yet again, you are not way off...

[Yair]

The 3D graph in 8.6 was implemented as an Xcontrol. I don't remember off hand if it uses classes (although it probably does), but you should be able to see its code by dropping one and selecting Advanced>>Show Diagram from the right click menu.

[ragglefrock]

I'll throw in another very useful aspect of XControls. They're extremely useful in custom probes, because they allow the probe's panel to remain in an active state after the data has passed through the probed wire. This is very useful for analyzing reference-based data, because you don't have to know exactly what you're looking for before the data passes through the wire!

[gb119]

QUOTE (Aristos Queue @ Dec 20 2008, 12:37 AM)

Nor have most people succeeded in that domain. Could it be that some crucial connection between the two is missing? Does it feel, perhaps, unfinished...? If it feels that way, yet again, you are not way off...

QUOTE (ragglefrock @ Dec 21 2008, 11:03 PM)

I'll throw in another very useful aspect of XControls. They're extremely useful in custom probes, because they allow the probe's panel to remain in an active state after the data has passed through the probed wire. This is very useful for analyzing reference-based data, because you don't have to know exactly what you're looking for before the data passes through the wire!

I've had some success when using XControls to make probes for LVOOP classes, but I've also badly bitten myself. Problems start happening when you have an XControl that uses class members and then use that XControl in a probe that is itself part of the class. The result is an uneditable class (at least in 8.5 and 8.2 - I haven't tried the sequence in 8.6) which needs manual editing of the .lvclass to rectify. The general issue is that the facade of an XControl runs in a spearate application instance and runs even if the containing vi is idle. It's then very very easy to get a class that is locked because it is in use in another application instance, but the vi that is causing this is itself a member of the class. One can see the logical necessity of all the individual steps but the end result is spectacularly irritating.

If you manage to avoid shooting yourself in the foot, then yes it all works really nicely for class data because of the flexibility in manipulating the presentation of the (often complex) class data after the data has passed through.

[LAVA 1.0 Content]

QUOTE (Aristos Queue @ Dec 19 2008, 06:37 PM)

Nor have most people succeeded in that domain. Could it be that some crucial connection between the two is missing? Does it feel, perhaps, unfinished...? If it feels that way, yet again, you are not way off...

Here are just some thoughts. I'll let others judge their validity.

I have only delivered one LVOOP app to date and I had to teach myself enough OOP to implement same. Since I only have one to base my opinion on I will share what I had to do since I did not know how to do it the right way or the the tools where lacking.

App Descrition:

"Create Controls on the Fly" application deployable to any Winodws machine that allows for additional "screen object" deployment without modifying the application.

I choose to develop it using LVOOP since it allowed dynamic dispatching in a built app. The "additional screen object" (Things like buttons meters... we called them "plug-ins") could be loaded dynamically. When I had new object ready for deployment I just added folders and classes as required. This was GREAT! It was probably the biggest feature that finally allowed me to get a buy-off from management to use LVOOP. But I am digressing...

So my applicaiton consisted of a set of "Core" classes that provided a vinella flavored interface to the Plug-ins that let them recieve/send updates from/to whatever while also allowing user interaction. Most of the work I put into developing the "Core" focused on keeping all f the "plugins" running independently while also being efficient.

To maintan independence between all of the plug-ins I choose to create sepearte background processes for each Plug-in. This allowed me have a while loop a the heart of every Plug-in. The while loop gave me two things. 1) It gave me shift-registera so that I could control my memory usage to my hearts content. The SR stored the class state data for that instance of the class "Plug-in" 2) It allowed me to create chlildren of the Class "Plug-in" that where capable of "tickling" themselves. In my cases a scrolling marquee of class Plug-in >>> Text >>> Indicator >>> Scrolling that would update its image regularly.

Each instance of the class Plug-in was insatciated by the Core by creating command, responce and update queues and then "instanciate" the object by loading a template of the selected class. The queues allowed other parts of the appliaiton to invoke methods for any of the Plugins instaces. So this represents my adhoc by reference architecture. There is alot more built into the core but is enough detail to touch on what seemed missing cumbersome etc.

Could we add "active Objects" to LVOOP?

This would require creating instanciating the object and creating the by reference method infatructure (most of what I described above).

Re: The XControl-LVOOP combo

Not yet but someday. The only short-coming I see in the XControl is you have to go through gyrations to get them to "tickle" themsleves.

BTW: if any of you would like to tell me why my above described approach is wrong PLEASE straghten me out.

Just my 2 cents,

Ben

[crelf]

QUOTE (neB @ Dec 22 2008, 11:33 AM)

"Create Controls on the Fly" application deployable to any Winodws machine that allows for additional "screen object" deployment without modifying the application.

I choose to develop it using LVOOP since it allowed dynamic dispatching in a built app. The "additional screen object" (Things like buttons meters... we called them "plug-ins") could be loaded dynamically. When I had new object ready for deployment I just added folders and classes as required. This was GREAT!

That sounds really cool Ben - any chance of seeing a demo?

[LAVA 1.0 Content]

QUOTE (Karl Rony @ Dec 17 2008, 04:18 PM)

Would I be better off learning LVOOP instead of XControls?

QUOTE (Aristos Queue @ Dec 19 2008, 02:23 AM)

I agree. The XControls are useful only for UI heavy projects.

And LVOOP only for heavy data projects. :headbang:

What XControls need is their own Stephen Mercer, AristosQ. Someone that is very proud and convinced of their possibilities, keeps discussions on a high level, write several XControl Frameworks with thoughts when to do what.

QUOTE (neB @ Dec 22 2008, 05:33 PM)

Could we add "active Objects" to LVOOP?

This would require creating instanciating the object and creating the by reference method infatructure (most of what I described above).

I think one of the OpenG infrastructure have this.

QUOTE

Re: The XControl-LVOOP combo

.... The only short-coming I see in the XControl is you have to go through gyrations to get them to "tickle" themsleves.

Ben,

What is it that you exactly mean by 'tickling'?

An option would be user event from the owning application that runs in a timed loop and is triggered every run.

One question about your application, what was the FP element that represented the dynamic object?

Ton

[LAVA 1.0 Content]

QUOTE (Ton @ Dec 22 2008, 01:41 PM)

...

Ben,

What is it that you exactly mean by 'tickling'?

An option would be user event from the owning application that runs in a timed loop and is triggered every run.

One question about your application, what was the FP element that represented the dynamic object?

Ton

Re:Tickling

Yes you read me correctly. Yes a timed loop can be used to do the tickling but then the XControl is dependent on something outside the XControl to work properly.

Re:

I used a Picture Control for the only FP object. Mouse down/up/move Event triggered similar methods for the object associated with that portion of the screen. The Plug-in interpreted the methods and responded accordingly including sending image update to the Picture so the user could see the knob turn etc. Again this highlight the strength of LVOOP for an app like this. The Instance of the Class Picture knows nothing about the Plug-ins it hosted. It only knows "If the user wiggles over here" that area belongs to this widget so I'll pass it along" and if it gets a screen upate it should update the image in that area.

CRELF wrote "That sounds really cool Ben - any chance of seeing a demo?"

My app is just a re-architected version of the demo Tomi posted (See here for drawing demo and here for Plug-in ). Special thanks to Tomi by the way! I just built his demo into an exe in order to convince my boss LVOOP was the way to go.

Ben

[LAVA 1.0 Content]

Hi Ben,

thanks for your info.

Tickling can be started by an asynchronous VI started in the Init instance.

If you look at my 'LabVIEW toolbar' example here, I use a similar approach like you, only I used user events for 'click' actions.

Ton

[shoneill]

QUOTE (Gavin Burnell @ Dec 22 2008, 12:41 AM)

I've had some success when using XControls to make probes for LVOOP classes, but I've also badly bitten myself. Problems start happening when you have an XControl that uses class members and then use that XControl in a probe that is itself part of the class. The result is an uneditable class (at least in 8.5 and 8.2 - I haven't tried the sequence in 8.6) which needs manual editing of the .lvclass to rectify. The general issue is that the facade of an XControl runs in a spearate application instance and runs even if the containing vi is idle. It's then very very easy to get a class that is locked because it is in use in another application instance, but the vi that is causing this is itself a member of the class. One can see the logical necessity of all the individual steps but the end result is spectacularly irritating.

If you manage to avoid shooting yourself in the foot, then yes it all works really nicely for class data because of the flexibility in manipulating the presentation of the (often complex) class data after the data has passed through.

I just ran into a similar problem. I wanted to replace the default LVOOP controls and indicators in my classes with some simple XControls to give some visual feedback (especially when debugging) on the FP of my LVOOP VIs.

I created the XControl (which uses some of the VIs of the class it is displaying) but when I wanted to place it on the FP of one of my LVOOP VIs, it locked the entire class (actually the entire class hierarchy!)......

I was able to right-click the XControl and select "unlöock for editing" but I still couldn't edit the VIs which were being used in the XControl. If anyone wonders why XControls haven't been used more extensively in conjunction with LVOOP well there's a pretty clear answer for you. It doesn't seem to work. I tried in 8.2.1 and 8.6. The result was the same in both.

Note that I did not incldue the XControl IN the class as it seems this is not possible. If I was able to add the XControl to the class, I could access the data of the class directly without having to use any of my LVOOP Accessor VIs. This might get aroung the locking problem.

Has this been fined as a bug? I see it as a major problem as it makes LVOOP and XControls almost mutually exclusive whereas they shoiuld really be a perfect match.

Shane.

[Aristos Queue]

QUOTE (shoneill @ May 19 2009, 05:19 AM)

Has this been fined as a bug? I see it as a major problem as it makes LVOOP and XControls almost mutually exclusive whereas they shoiuld really be a perfect match.

Less a bug and more an incomplete feature. But, yes, it is a known issue. I've discussed it elsewhere.

An even bigger known issue: Do not create a circular link from your XControl to your class. In other words, write your class completely and then write your XControl using the class... do not put the XControl or any property/invoke node for the XControl into member VIs of the class. The circular load leads -- sometimes, most commonly in a built app -- to VIs that are permanently broken and no matter what you do the run arrow will not become fixed.

[jdunham]

QUOTE (shoneill @ May 19 2009, 03:19 AM)

Has this been fined as a bug? I see it as a major problem as it makes LVOOP and XControls almost mutually exclusive whereas they shoiuld really be a perfect match.

I also have to pipe up and say that some of this wouldn't be needed if the default probe information shown on an object's wire could be made visible on the VIs front panel. The relative difficulty of debugging is a serious barrier to adoption of LVOOP.

[shoneill]

QUOTE (Aristos Queue @ May 19 2009, 07:31 PM)

Less a bug and more an incomplete feature. But, yes, it is a known issue. I've discussed it elsewhere.

An even bigger known issue: Do not create a circular link from your XControl to your class. In other words, write your class completely and then write your XControl using the class... do not put the XControl or any property/invoke node for the XControl into member VIs of the class. The circular load leads -- sometimes, most commonly in a built app -- to VIs that are permanently broken and no matter what you do the run arrow will not become fixed.

Thanks for the info on that. I THOUGHT I read something on the topic before. Could you give me a link, I can't seem to find it. I wasn't certain if I HAD actually read something because with such a good memory, sometimes I remember things which didn't even happen!

So XControls are for visualisation OUTSIDE of the class?

Shame since it would seriously help debugging if we were able to replace the standard LVOOP terminals with XControls. That would be so nifty.

I suppose I'll have to work another way around my problem. I have exactly the circular link you are referring to. I don't have a broken arrow, but I have several uneditable VIs. :headbang:

Now where's notepad again.....?

Shane.