LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Callback VI for "Value Changed" event

I recently had a clever idea.  As with a lot of my clever ideas, it doesn't seem to work.

 

I have a bunch of UI elements and want to react to changes to their values via Event Structure.  Instead of statically linking all of them into their own case or statically linking them all into a single case (and then somehow working backwards to find out which instance was triggered) I decided to create a callback VI for each control, initialise it with an Index field and then use it as a passthroughvia User Event, effectively adding an "Index" field to the Event received in the Event Structure.

 

Doesn't work.

 

When I create the Callback VI for a "Value Changed" Event, the "Old Value" and "NewValue" are not available (These should be in "Event Data", right, but the connector pane is empty - no such control on the FP).  Yes, I could go via the control reference to get the value, but that completely destroys the performance of the code.

 

A callback VI for "Mouse Down" for example DOES include the Event Data.  Here, the "Event Data" control is present and connected to the FP Terminals.

 

I can't believe I never ran into this before.

 

Edit: Changed Title.  Where on earth did the Forums get the original title from?

Message 1 of 20
(1,555 Views)

I'd say performance is the reason the data is not there. Ironically.

 

In an event structure, it's up to the programmer if the data gets copied. But in the callback, it would always be copied. That could (on the average use case) be slower then getting it from the property.

 

Not sure why it is there for the mouse down event. Probably because that data is fixed, so damage is limited and fixed.

0 Kudos
Message 2 of 20
(1,518 Views)

Sorry, that just doesn't add up.

 

The callback VI is equivalent to a frame of the Event structure (to my understanding).  Whether the data is made available in the Event Structure or in the Callback VI, the effect is the same.  Also, a property call is typically WAY more time-consuming than a simple data copy.  Bear in mind a property call ALSO makes a copy, but has a thread switch on top of that........ Like I said, that doesn't seem to add up to me (unless I'm completely off-track here).

 

Regarding fixed-size.  More fixed than an SGL scalar?

0 Kudos
Message 3 of 20
(1,511 Views)

You could use OOP and the event structure instead - each control is mapped to an object. Your event handler grabs the object that maps to the control reference when the value change occurs, and you pass that object to the dynamic dispatch event handling method with all the event inputs you want. We wrote something similar for a teststand UI framework at a prior job, but I'm not sure if it ever got any use. 

0 Kudos
Message 4 of 20
(1,500 Views)

IIRC, the Value Change callback used to have Event Data, but that was deleted some time around LV 8.

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

Put together a little demo of this including some silly control action classes. The code would need some cleanup but gives you the idea of what I was getting at.

0 Kudos
Message 6 of 20
(1,486 Views)

@Intaris wrote:

 

The callback VI is equivalent to a frame of the Event structure (to my understanding).  Whether the data is made available in the Event Structure or in the Callback VI, the effect is the same.  Also, a property call is typically WAY more time-consuming than a simple data copy.  Bear in mind a property call ALSO makes a copy, but has a thread switch on top of that........ Like I said, that doesn't seem to add up to me (unless I'm completely off-track here).

 

Regarding fixed-size.  More fixed than an SGL scalar?


The value could be an array. So the data could be huge.

 

In the event structure, if new or old value isn't used, there might not be a copy. If it is used, there needs to be a copy, but that's the user's choice.

 

If each callback always had both old and new value, there would always be a copy of both. And that could be expensive.

 

How expensive? That depends on the data. A SGL scalar wouldn't be a problem...

 

Adding this to the callbacks would make it troublesome for large data structures. The mouse down isn't a large data structure, so someone decided to include the limited data. 

 

Didn't say it was a good reason nor that there shouldn't be a solution (maybe optional old\new value somehow?). But I think it is the reason it is how it is...

0 Kudos
Message 7 of 20
(1,456 Views)

Seems like a (pardon my french) stupid design decision if that is the case.

 

I mean, why allow a Value change event at all if you don't include the Value in the event data?  It makes the whole thing completely pointless in my opinion.

 

All workarounds involve at least the same magnitude data copy as the implementation would be trying to mitigate, as such it fails in its task.  I'm frustrated at the moment.

0 Kudos
Message 8 of 20
(1,448 Views)

Is there a reason you can't just implement your own callbacks using OOP like I showed or even VI server?

0 Kudos
Message 9 of 20
(1,429 Views)

@Intaris wrote:

 

I mean, why allow a Value change event at all if you don't include the Value in the event data?  It makes the whole thing completely pointless in my opinion.


That's only true if you need the value. I'm not sure if that's "always" the case, or if not how often it is the case.

 

If it was there in LV8, and it got removed, I'd say there must be some dialog about it? Somewhere...

 

Almost every time I used callback VIs, I ended up replacing them with for a dynamically started clone). When done correctly, it works pretty much the same. The dynamic VI stops and is removed automatically when the caller stops, as there is no open reference anymore.

 

The way CB VIs block when the CB is in a class, the thereby entire class, even when not used, is terrible. And they tend to crash when used in recursive clones in subpanels. But only in executables, when you think you're done...

0 Kudos
Message 10 of 20
(1,421 Views)