From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
06-17-2014 10:45 AM - edited 06-17-2014 10:56 AM
I'm running the Passing Data to a .NET Event Callback.vi sample (LV2013SP1).
After stopping the vi with stop button, i can't edit the Callback - EventHappened.vi. This subvi is still loaded and can't be edited.
To edit the callback vi i need to close projet and reopen it.
How can we stop the callback.vi to go in edit mode after stopping the toplevel vi?
When running the same under LV2012, the callback vi can be edited after stop toplevel vi.
Regards
Alexandre
06-17-2014 12:00 PM
Watch the VI heirarchy window running both examples. the Proxy Caller does not leave in 2013.
06-17-2014 12:02 PM
So... is there a way to stop it? Is this indeed a bug, or another example of NI deciding this is better for us?
Mike...
06-17-2014 12:08 PM
Perhaps a side effect to the following bug fixe
429726 | — | LabVIEW crashes when .NET event callback calls a VI that has already been deregistered in LabVIEW. |
06-17-2014 12:44 PM
I believe what we have is an unabortable proxy caller. Playing with some of the other examples it appers to only effect .NET
The Active X event callback ProxyCaller behaves as I would expect. and how both the .NET and active X ProxyCallers behave in LabVIEW 2012. (That is the proxy callers complete execution and go away when the event is unregistered) This is the Heirarchy view after running operating and stopping both examples with 2013SP1
Does that mean bug or new intended operation? That's one I hesitate to answer with the new Event Inspection framework and what I do not know about ActiveX and .NET
12-29-2014 08:24 PM
Have a look at this and you will find a workaround to this bug. It's a known bug of LV2013SP1.
http://www.ni.com/product-documentation/14490/en/#468139_by_Category
Regards,
Sacha.