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.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

.net event callback VIs - Why do they never leave running state?

Solved!
Go to solution

You don't need a constructor, just an invoke node.

 

GC_Collect.png

Message 11 of 33
(2,412 Views)

Does this unlock callback VI's for LabVIEW events as well? Don't see why it would...

 

The Register Callback Event node can be used to register events for control, pane, VI, etc references. However, when the callback VI's are in a class, they will never unlock, and since one VI in the class is locked, the entire class stays locked. Closing the project is the only way out.

0 Kudos
Message 12 of 33
(2,401 Views)

Why would this be a thing?

This messes up my workflow…

________________________________________________________________________
"When I need the side of a building to view all the code..." -Mark Yedinak
"...when you need a navigation window to view the navigation window..." -Jeff Bohrer
0 Kudos
Message 13 of 33
(2,345 Views)

@UFOslava wrote:

Why would this be a thing?

This messes up my workflow…


Why would what a thing?

What messes up your workflow?

0 Kudos
Message 14 of 33
(2,318 Views)

Restarting LabView after each run of my code.

________________________________________________________________________
"When I need the side of a building to view all the code..." -Mark Yedinak
"...when you need a navigation window to view the navigation window..." -Jeff Bohrer
0 Kudos
Message 15 of 33
(2,314 Views)

@UFOslava wrote:

Restarting LabView after each run of my code.


I think closing the project is enough, but yes, it's a pain.

0 Kudos
Message 16 of 33
(2,309 Views)

It seems that in some scenarios this problem exists for LV controlls callback Events. VI can not be unloaded and upon exit labview crashes...

 

<DEBUG_OUTPUT>
2019-01-14 15:21:39.408
DWarn 0x30EA5E5C: no master part
e:\builds\penguin\labview\branches\2018patch\dev\source\panel\fpinval.cpp(235) : DWarn 0x30EA5E5C: no master part
minidump id: 237f3a14-5287-4877-ae3b-dca69607e6e2
$Id: //labview/branches/2018patch/dev/source/panel/fpinval.cpp#1 $

 

Is there known CAR reported for this or workaround?

0 Kudos
Message 17 of 33
(2,169 Views)

Hello pawhan11,

 

The CAR number for the original post is 493624. Have you tried implementing the workaround listed? It should still work.

 

Also, I would suggest that you make a new forum post for your particular issue because it seems to be different than the original post and this thread is an older one. Moving to a new thread will potentially get more attention by active users on the forums.

Gerald M.
Applications Engineer
NI
0 Kudos
Message 18 of 33
(2,147 Views)

The only workaround, Collect, only (potentially) works for .NET callbacks. AFAIK, there is no workaround for hanging callback events on native LabVIEW objects.

0 Kudos
Message 19 of 33
(2,137 Views)

Thanks for pointing this KB article out this has helped me. I'm using LV2019 I found no other way to fix this other than calling GC.Collect() after calling the Unregister for Events. If anyone knows of a more proper fix for this I'd appreciate it.


0 Kudos
Message 20 of 33
(1,869 Views)