front panel customation of a xcontrol

[Dirk J.]

Reasonably late, I have the ability to play with Xcontrols per our latest LV8.6 upgrade. I figured I'd start with an XYgraph that displays error bars. First step was dropping an XYgraph control on the Facade VI, and nothing else.

If I place this Xcontrol on a front panel, it appears that I can change some stuff (such as the bizarre grid colors if the native XYcontrol), and the axis labels; and can't change other stuff such as the XY graph label. I can change the line style/color/etc of a graph if the plot legend is visible, but I can neither resize the plot legend, nor show or hide it altogether from the front panel in the 'usual way'.

Not that it actually matters, because when I save everything, close, and open it all again, all xcontrols are defaulted to the Facade VI.

So am I right to conclude that Xcontrols are a kind of "type def control"? Only the definition can be changed, not the individal controls? I realize that they can be changed programatically, but that requires a lot of coding. Or to put in in another way: I used to implement my "xcontrols" by means of subpanels. What is the actual benifit of having XY controls as user interface elements, over that approach if you can't customize the individial controls just as you would customize a native control?

/dirk

[Mark Yedinak]

There are several advantages to using X-controls. First, you can do just about anything you want with them (yes, there is coding involved) and your custom control is now a nice and self contained unit that is easy to reuse. I doubt there would be significantly more coding than what you would be doing using your sub-panel approach. However, when implemented as an X-control you can trigger off events using the event structure just like any other normal control. You can save the state of the control if you want so state information can be preserved. Most of the changes you have mentioned could easily be achieved using custom properties for the X-control. One thing that I have found very useful about X-Controls is that for complex controls that I ended up reusing often I was constantly copying and pasting code from one application to another or passing references to subVIs. With the X-Control I simply drop the control on the FP and I am good to go. It makes reusing complex custom controls much easier. It simplifies the UI for complex controls. If I was only going to do it once I probably wouldn't create a X-control but for things I reuse they are quite nice.

[Grampa_of_Oliva_n_Eden]

QUOTE (Mark Yedinak @ Apr 14 2009, 04:05 PM)

There are several advantages to using X-controls. First, you can do just about anything you want with them (yes, there is coding involved) and your custom control is now a nice and self contained unit that is easy to reuse. I doubt there would be significantly more coding than what you would be doing using your sub-panel approach. However, when implemented as an X-control you can trigger off events using the event structure just like any other normal control. You can save the state of the control if you want so state information can be preserved. Most of the changes you have mentioned could easily be achieved using custom properties for the X-control. One thing that I have found very useful about X-Controls is that for complex controls that I ended up reusing often I was constantly copying and pasting code from one application to another or passing references to subVIs. With the X-Control I simply drop the control on the FP and I am good to go. It makes reusing complex custom controls much easier. It simplifies the UI for complex controls. If I was only going to do it once I probably wouldn't create a X-control but for things I reuse they are quite nice.

Agreed.

A custom control is probalbly what you really want. With an XControl you have to code a bunch of stuff including (if you want it) how the control reacts to is facade being re-sized.

Ben

[Dirk J.]

Mark: I hoped that using Xcontrols would mean less coding. I agree that the 'simple dropping' of an Xcontrol is certainly an asset. My intention was to create a control (or subpanel-based, lvoop handler) that accepts an (Xarray,Yarray, Error_array) cluster as data. I'm very willing to write code for the functionality - I'm doing that in my subpanel implementation. I kind of expected that the user interface part would be handled similarly to conventional LV controls (in the IDE, not programatically). Note that the subpanel approach also allows event-structure based implementations, so I don't see any differences there. I know that the customizations I listed can be implemented relatively easy in code; but for 'normal controls' they don't require code at all.

QUOTE (neBulus)

With an XControl you have to code a bunch of stuff including (if you want it) how the control reacts to is facade being re-sized.

That's another issue, indeed.

Maybe I was wrong to assume that an Xcontrol was a "user interface" benefit. Maybe an Xcontrol is just a 1/3 lvclass; it has encapsulation, but no inheritance and polymorphism.

[Francois Normandin]

QUOTE (Dirk J. @ Apr 14 2009, 04:50 PM)

Mark: I hoped that using Xcontrols would mean less coding. I agree that the 'simple dropping' of an Xcontrol is certainly an asset. My intention was to create a control (or subpanel-based, lvoop handler) that accepts an (Xarray,Yarray, Error_array) cluster as data. I'm very willing to write code for the functionality - I'm doing that in my subpanel implementation. I kind of expected that the user interface part would be handled similarly to conventional LV controls (in the IDE, not programatically). Note that the subpanel approach also allows event-structure based implementations, so I don't see any differences there. I know that the customizations I listed can be implemented relatively easy in code; but for 'normal controls' they don't require code at all.

That's another issue, indeed.

Maybe I was wrong to assume that an Xcontrol was a "user interface" benefit. Maybe an Xcontrol is just a 1/3 lvclass; it has encapsulation, but no inheritance and polymorphism.

Well, XControl means less code somewhere in the future... but more right now.

And you're right, from a comment written by AQ some months ago, we should expect the classes and XControls to converge in the future. So it's up to you to see if you want to wait for more convergence before spending time on this. Anyhow, it's entirely possible to use lvclasses inside the XControl, but I haven't gotten to experiment that just yet...

[Aristos Queue]

QUOTE (normandinf @ Apr 14 2009, 05:47 PM)

And you're right, from a comment written by AQ some months ago, we should expect the classes and XControls to converge in the future.

The long future, not the short future. Short = 2 years.