Insert class methods on wire

[TurboPhil]

 The attached LLB provides custom shortcut menu when users right-click on lvclass wires on the BD. It inserts a new "Insert Class Method" menu immediately below the default "Insert" menu item, with individual submenu items for every method VI of the class library.

Initial testing works pretty well, with the following (major) caveat: any time I use this shortcut menu option and then later quit labview, I end up getting LV Crash Report dialogs. 

The crash logs always reference the following DWarn:

"DWarn 0xEFBFD9AB: Disposing OMUDClass definition"

I think the problem is that the lvclass libraries are getting pulled into the application context of the menu builder, and even though I have tried closing all the VI server references explicitly, as well as using "request deallocation" (per the suggestion in the Intro powerpoint), I still keep seeing the crash behavior.

Does anyone have any suggestions for what can be done to avoid the crashing?

(Observed in LV2015 SP1 f10).

[TurboPhil]

Additional notes/clarifications:

• The DWarn only comes up as I exit LabVIEW.
• It seems to be happening when I use the shortcut on a class wire for an lvclass that includes a dependency on another lvclass
  • The warning is specifically calling out the dependent lvclass, e.g. one that is ended up in memory indirectly

If you look at the code implementation, you can see I'm already jumping through some hoops to try to make sure that the class is opened in the main application context, and not the context of the menu builder. But I think the problem is in reading the data type property of the wire; it is pulling in the dependent class into that context and not cleaning it up afterwards.

[McQuillan]

---

Does anyone have any suggestions for what can be done to avoid the crashing?

(Observed in LV2015 SP1 f10).

---

Sadly not, but I thought I would comment to say I am getting the same crashes in LV2018 when using a similar tool. The tool seems to work fine, it's just that the crash screen comes up at the end. I have seen this happen with classes and IDE-extension tools a couple of times (for example the TSVN Project Provider). NI must be aware of this, however, I haven't been able to find a solution.