LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Callback VI for "Value Changed" event

Well, I would have thought that the "Value" in a "Value Changed" Event is kind of likely to be required......

Message 11 of 20
(473 Views)

@Intaris wrote:

Well, I would have thought that the "Value" in a "Value Changed" Event is kind of likely to be required......


Yes. But sometimes you want the old value, sometimes the new value. Sometimes both, sometimes neither. So it might be inconvenient, but including both might also be undesirable as this might cost resources.

 

Those callback events are a nice hack, but AFAIK almost never suitable for serious things.

 

The filtering events stopped working (crashing LabVIEW) in LV8, and where not fixed until LV13, IIRC.

 

Now it sort of works. But in some situations still crashes LabVIEW (multiple layers of clones in subpanels). Pretty annoying when you make a library that works, passes all tests, and then crashes your application (exe only) when you scale up...

 

So even fixing\changing this event data wouldn't make me use them. I've been burned too often...

 

Starting a dynamic VI is a bit more work, but easier to deal with. And it doesn't make LabVIEW crash.

0 Kudos
Message 12 of 20
(455 Views)

I reworked the implementation I uploaded earlier - now one event handler per control, and with a simpler API - no need to explicitly close the handler. See the Sandbox.vi for an example use. 

0 Kudos
Message 13 of 20
(441 Views)

Are Event callbacks officially labelled as a "hack".

 

I thought it was a perfectly viable programming tool.  I certainly was not aware of this differentiation.  I have used quite a few Callback VIs (with User Events) on many occasions.

 

The nice thing about callback VIs is that you have a 1:1 relationship between VI and Event.  With a parallel VI, this is not normally the case.  Of course one can make it so, but I actually prefer the callback approach.  Just my 2c.

 

So, accepting that for reasons of buffer copies how do I implement a Callback VI which, upon the first call, has access to both "Old Value" and "New Value"...... preferably a method which is more efficient than using "Value" properties.

0 Kudos
Message 14 of 20
(433 Views)

@paul.r wrote:

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


This isn't about a solution or workaround. Your solution\workaround is good, btw.

 

It is about callback events that are missing new\old values. Or, AFAIK, the option to return old\new values.

 

 

Those callback events would be convenient if they didn't crash. And arguably if they had more event data. You don't have to worry about dangling clones and they are faster to make.

0 Kudos
Message 15 of 20
(430 Views)

I've only seen crashes when I made changes that resulted in the callback's connector pane not matching what was expected.

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

My executable crashed reproducibly when I registered mouse move callback events in a clone VI inside a subpanel of a clone inside a subpanel of a clone.

 

The moment there where pending events while the VI's got removed from the subpanel and\or the clones got removed from memory, the executable would crash.

 

Didn't look further to investigate. As these events where part of a reusable library, I could not dismiss this situation as 'farfetched' or obscure either. And after all, it happened in my application.

 

Not sure if it is the clone that got dismissed, or the removal from the subpanel, or the subpanel being in a clone that causes the crash. I even unregistered the callback events before closing the rest, but even that did not work. I decided to rip off the bandage and continued with proven techniques...

 

Just a friendly warning...

Message 17 of 20
(394 Views)

Wiebe, when I read this post, my takeaway from it is "Sub-Panels cause all kinds of problems", not neccessarily that Callbacks cause all kinds of problems.  But as with any point of view, it's personal and non-transferable. Smiley Tongue

0 Kudos
Message 18 of 20
(376 Views)

@Intaris wrote:

Wiebe, when I read this post, my takeaway from it is "Sub-Panels cause all kinds of problems", not neccessarily that Callbacks cause all kinds of problems.  But as with any point of view, it's personal and non-transferable. Smiley Tongue


Could be the subpanels. Could be the cloning. Could be the combination.

 

I can't do without the subpanels nor the cloning, so I replaced the callbacks. I had this probelm in a reusable user interface library. So I can't leave it in there knowing it will crash in certain situations, especially when those situations are likelly to be used in combination with the library.

 

I think I had similair problems with XControls when I first tried them. Granted, in 8.0, so that didn't help. Could also have been the subpanels and\or clones... Never used XControls them again though.

Message 19 of 20
(371 Views)

XControls. The one personal preference story which appears to be tranferrable indeed.

 

Loved the idea.

Wrote a few.

Died inside trying to get them to do what I wanted.

Never touched them again for anything but the most trivial of tasks.

Message 20 of 20
(367 Views)