XControl Using Display State Change for temporary internal data storage

[Michael Aivaliotis]

I understand that the Display State control of an XControl can be used to store the current internal state of the XControl. One thing I don't like however is that every time you update this data from within the Facade and set the State Changed? value to TRUE, it triggers the caller VI using the XControl to show an asterix in the Titlebar which indicates that the VI has changed. I understand why this is happening, however it's not desirable if you're just keeping some temporary internal values in the XControl which only last for the current lifetime and you don't care about saving them.

One alternative I guess would be to use an un-initialized shift register on the Facade VI to keep these variables and not use the Display State data. One limitation with this method is that the data would only be accessible from the Facade and not from the Methods and Properties. Another possibility would be to create a LabVIEW Class for the XControl. I want to avoid that since I don't want to open another can of worms. I'm already having enough trouble trying to get my XControl implemented in the first place.

[LAVA 1.0 Content]

I'm already having enough trouble trying to get my XControl implemented in the first place.

Aren't we all?

I used the USR for an example located here. I'm gonna have to make time to learn about LVOOP sooner or later, but I wanted to make it a bit later... I wish XControls behaved more like a control than "fancy transparent subpanels with a single terminal input/output" :thumbdown:

[Aristos Queue]

I wish XControls behaved more like a control than "fancy transparent subpanels with a single terminal input/output" :thumbdown:

That's what custom probes effectively are. We prototyped the XControls along the same lines -- an enum in to say what to do, a set of values out that were evaluated depending upon what value of the enum was used. Looked a lot like a functional global. Didn't work so well... when it only runs occassionally, as custom probes do when they have data values to update, you lose a lot of the live display potential of the XControl.

[Michael Aivaliotis]

I wish XControls behaved more like a control than "fancy transparent subpanels with a single terminal input/output" :thumbdown:

Well, I'm not too upset with the current implementation. What I find a little annoying is to make all those Method and property VI's. Then you need to do more work in the Facade. What I would like to see instead is just let us register the methods and properties RIGHT INSIDE the Facade event structure. Then we can do the work in one place. This could potentially be done along the same lines as dynamic event registration. An additional side benefit would be that you now will know exactly what property fired and when.

[Grampa_of_Oliva_n_Eden]

"fancy transparent subpanels with a single terminal input/output" :thumbdown:

Thank you LV Punk for flipping that switch for me.

At first I thought I was dealing with a snake, and then I thought it was a tree, and then again I thought it may have been a wall. :headbang:

Ben

[robijn]

when it only runs occassionally, as custom probes do when they have data values to update, you lose a lot of the live display potential of the XControl.

Yes, right now they are called as a handler. NI could change the behaviour and make them run continously. I have often many windows running in parallel, handling their own events. New data could arrive in the event structure.

I like the idea for registering properties, creating custom events.

Joris

[LAVA 1.0 Content]

NI might not like my description, but it's how I've come to look at them. They aren't bad, just a bit awkward for a left-handed dyslexic like myself .

Michael's info regarding the ability to group/tree the props with the colon : in the name is a nice feature, but a perfect example of the general lack of documentation for XControls.

I think eControl (editable Control) or iControl (to denote personalizable) might have been a more appropriate name. When I think of XControl, I think EXTREME like wrestling, skateboarding, or my own global free, sequence structure free and better than you coding style :laugh: .

I've imagined using XControls, LVOOP and Jarrod Slocum's Linked Object List in LabVIEW 8.0 Using XControls technique to create a configurable toolbar or ribbon consisting of icons, rings and such. I don't spend a lot of my time programming for the UI, but I think the parts exist to make such a thing.

[Michael Aivaliotis]

When I think of XControl, I think EXTREME like wrestling, skateboarding, or my own global free, sequence structure free and better than you coding style

When I think of XControl, I think of XWife or XArcade. It used to be a control...

[Aristos Queue]

When I think "X" anything, I think "Marketing."

[Jim Kring]

When I think "X" anything, I think "Marketing."

I heard that the "mx" in "DAQmx" stands for "Marketing eXtension"

[robijn]

I think X was meant to stand for "the unknown, the mysterious", like in the X-files...

Things that noone really completely understands, but are very interesting to explore.

Joris

PS. I do like the concept of X controls !

[LAVA 1.0 Content]

When I think "X" anything, I think "Marketing."

If so, I hope I NEVER hear the term "LVOOP-X"

[crelf]

Things that noone really completely understands, but are very interesting to explore.

Just like Generation-X

[Aristos Queue]

If so, I hope I NEVER hear the term "LVOOP-X"

How about LVXXX for "LabVIEW XObject-XOriented XProgramming"?

(this is pronounced L'vexsssssss, by the way)

[crelf]

How about LVXXX for "LabVIEW XObject-XOriented XProgramming"?

(this is pronounced L'vexsssssss, by the way)

Sounds a little eXcessive to me...