LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

XControls - Can I use them or will I hate myself later?

Solved!
Go to solution

Following the recent very interesting post by paul_cardinale here, and with reference to the now 4-year old poll on LAVA (XControls?), I'm again considering a use-case which seems perfect for an XControl, but I'm cautious about plunging in... (It's also interesting to note that mike_porter gave a presentation on XControls at NIWeek 2012 seemingly advocating their use, but by Feb 2015 was highlighting their difficulties in his blog)

 

My intended use is as follows (some previous discussion on the storage formats for this collection of classes can be found here, but reading that shouldn't be necessary for this discussion):

  • I want to display information about an array of 'positions' for measurement in a control, which will be used from two separate VIs, each embedded in a subpanel (which might or might not be visible, but I don't intend to have both simultaneously visible).
  • In one subpanel, the user's interaction should only be to choose a point, and either move there (and make no measurement), or move there and make a measurement, or perhaps display the last measured data from that position.
  • From the other VI, options for editing the positions, or reordering them within the array should be available. Both VIs need to reference the same array of position objects.
  • My actions are carried out using custom right-click menus (one for each VI), with a single VI handling the event generated. This allows me to code the event handling only once, but allow or disallow different actions in either VI based on the RTM files.

I had planned to display this data using a Multicolumn Listbox. My implementation so far uses an MCL with 0..N selections and an array of values, but now I realise (somewhat belatedly) that to change the visible values, I need to use a property node and the 'Item Names' property. This is ok, but I also don't seem able to trivially edit the values shown as strings. 

 

Looking at paul_cardinale's XControls documentation, along with the Simple Dual Mode Thermometer example, I see that similar functionality might be used in XControls, and further that it should be possible (I think?) to use an array of clusters with numeric controls for X,Y,Z and a timestamp for my time rather than a series of strings, which simplifies access from the Position.lvclass (which stores numeric values), and probably simplifies storing values (although I haven't coded that in the existing arrangement yet, since I found I couldn't input strings to the MCListbox, necessitating a new dialog VI for the editing of positions).

 

Which brings me full circle to my question:

XControls - Can/should I use one, or will I hate myself later?


GCentral
0 Kudos
Message 1 of 19
(5,943 Views)
Solution
Accepted by cbutcher

@cbutcher wrote:

 

XControls - Can/should I use one, or will I hate myself later?


Well I certainly hate myself when I use them.  I've seen some awesome useful XControls that are very reusable.  But these are usually controls where you only display data (simplifying the UI and UX), and have very limited scope.  When working with XControls I'm always finding UI limitations, or work arounds to get it to work the way I want.  Which is a bit frustrating because for me an XControl is usually already trying to work around some UI or UX issues to begin with so I'm trading one set of issues for another.

 

Take a look at this XControl for example.  The idea is to have a multicolumn listbox that you can click the headers and cause the columns to be sorted.  It also has a filtering option, and alternating row coloring.  I saw this and thought it was the best thing since sliced bread.  That is until I realized I wanted to have individual cells to be colored.  Well since XControls don't inherit from a base control, that means implementing all the properties and methods again, or using a scripting tool to do this for you.  Okay so every property and method you want implemented you need to write code to handle, not to terrible of a plan.  What about ways of knowing causing work to happen based on a user event?  Well that sorta works with some extra work arounds.  Then there are the myriad of other UI oddities where things don't work right in an XControl, but the normal control works just fine.

 

I hope I'm not steering you into a too negative direction because as I mentioned there are great XControls.  One of my favorites is the Variant Probe, which displays the data in a variant in a nice colored tree.

 

A good sign of reusable code is that you don't have to keep going back to it and updating it for other use cases.  If you spend enough time investing in making some reuse thing work well, you shouldn't need to go back and update it very often.  The problem with XControls for me is I will spend way too much time working on them, fixing use cases, and making them do everything I can possible think they should need to do.  Then the first time I go to use them I realize I need a ton more work to make them work in this case.  So I spend the time and make it work, and the second time I go to use it I realize...it still needs a ton more work.  I took that MCLB XControl from earlier and have been updating it for several years, adding new functionality, colored cells, tab and return control to go to other cells, allowing for drop downs or other custom data types, auto column width, adding drag and drop for reordering, and copying to other MCLB XControls, and reordering array of cluster data based on sorting, and creating the MCLB display based on a cluster data type.  And the result?  I've never used it on a real program.  It feels close, but never complete, just like XControls in general.  Contrast this with something like an XNode where you could also spend a lot of time investing in making the code reuseable, and spending a while meeting the needs of the developers, and in the end you have a very useful reuse nugget that just seems to work because its uses are much more contained.

Message 2 of 19
(5,875 Views)

I avoid using XControls. Reuse code is great, but I've seen enough stability issues with XControls being used in large, often class-based applications where I cannot advocate their use.

0 Kudos
Message 3 of 19
(5,856 Views)
Solution
Accepted by cbutcher

Sure, you can end up chasing your tail.  The trick is to know when to stop.  Sometimes that means having an XControl with some limitations, and sometimes that means throwing in the towel & not using an XControl.

But you can do some nice things with XControls.  Here are some examples.

"If you weren't supposed to push it, it wouldn't be a button."
Message 4 of 19
(5,833 Views)

Thanks you for sharing some of your XControls.  The Micro Error, and Super Error indicators seem most useful, and cover all the cases I can think of and I could see using those in an application in a debug window, or a status one maybe.  

 

The Audible Tweak is the most limiting.  Doesn't resize, fit to pane, can't change font size, or style, or arrow color, make transparent, etc.  That's not to say it isn't useful, I just see its uses so limited, that a subVI taking in a value change.  Beeping on a range of values could be more useable in a subVI since the amount of time tweaking the XControl for every application isn't going to add much benefit where a single subVI can be used everywhere regardless of the UI design.  Similar comments on the other XControls.  While coloring a Text Ring is super useful, the fact that every UI may need tweaking for each system makes it less useful.  Imagine if I have to use these XControls on a touch panel UI with large bold fonts for example.

 

I'd like to emphasize that this isn't meant to be a criticism of your work but a criticism of the limitations and uses of XControls.

 

Oh and you may want to put a minimum pane size on the Super Error indicator, if it is fit to pane and the pane gets really small objects are hidden behind other objects.

0 Kudos
Message 5 of 19
(5,819 Views)

Thanks for the examples Paul - I can see lots of the things you discuss in the Word document on the other thread I linked being used in the xcontrols you added here and so it's nice to be able to see some more demonstrations of those patterns. It's particularly interesting to note that the examples you gave are obviously designed for pretty heavy reuse - not just one or two places. The variant probe that Hooovahh linked to presumably also shares this property. My case is unlikely to qualify for significant reuse in my code - I expect just the two places in this project file and possibly one other (related) project file. As a result, perhaps I'm going to be better working around problems with more simple/reliable components.

 

The general response seems to largely match what I expected when I wrote this question, and even after only a half-day coding up an xcontrol to use in place of my previous MCLB, it seems like I'm going to be trading one set of issues for another, possibly less desirable set of problems. Probably it can sit in a lonely branch of the repository until my opinion wavers again and I give it another shot.

 

If anyone has more/additional/further opinions or insights, I'd love to hear them. XControls seem every time I look at them to be just what I need, until I look at them a little more...


GCentral
0 Kudos
Message 6 of 19
(5,789 Views)

I have used a few XControls but have to say that although I implemented a few with strictly limited scope, I am currently removing them and replacing them with similar functionality with "standard" LV code instead of XControls.

 

We had trouble with (take a deep breath) XControls inside an XControl inside a Tab inside a VI inside a Subpanel....... We were seeing crashes when stopping the VIs containing this construct and simply removing the XControl seemed to solve the issue.  When crashing, the last several thousand entries in the DETT log were XControl entries so I'm presuming it was a causation thing and not purely correlation.  Since I removed them, the crashes are gone.

 

I also ran into a problem where each XControl needed 1 second to initialise on the FP of a VI, and seeing how I had XControls in XControls, this upped the ante to 2 seconds per control.  Seeing how I was instantiating 24 of these VIs in series, this increased loading time of the application by 48 seconds!  Ugly workarounds ensued.

 

XControls don't solve problems, they just relocate them and rename them.  Some of the problems you only rediscover long after you would even still hint at a connection with the XControl itself (As in my case).  I used to think they were weird and mgaical, then I grew to love the idea, then I implemented a few, then I got annoyed with limitations and then after a long time I have now essentially given up on them for all but the most piddly tasks where even having an XControl almost is not worth it in my eyes.....

 

XControls, nice idea, bad implementation

0 Kudos
Message 7 of 19
(5,731 Views)

This might be of some interest.  It's an unclean XControl that I just threw together to illustrate something.

The properties of the control on the Facade (a  graph), are all accessible (via a reference from a property node),

and they are preserved across saves of the owning VI.  This is done without having to replicate the entire set of Waveform Graph properties.

The very large down side is that it uses private methods (though these particular methods have been behaving the same since at least LV 7).

"If you weren't supposed to push it, it wouldn't be a button."
Message 8 of 19
(5,699 Views)

@paul_cardinale wrote:

But you can do some nice things with XControls.  Here are some examples.


Oh another tangent I thought of.  Have you ever turned that Super Error indicator into a probe?  Because you should.  You can still have the ability to breakpoint on an error, but having an error history on a wire sounds like a very useful tool.

0 Kudos
Message 9 of 19
(5,634 Views)

@Hooovahh wrote:

@paul_cardinale wrote:

But you can do some nice things with XControls.  Here are some examples.


Oh another tangent I thought of.  Have you ever turned that Super Error indicator into a probe?  Because you should.  You can still have the ability to breakpoint on an error, but having an error history on a wire sounds like a very useful tool.


Well, no, I haven't turned it into a probe.  And "sounds like a very useful tool" isn't enough motivation for me to do it.  Since it was your idea, go for it.

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 10 of 19
(5,621 Views)