LabVIEW
How do I add a title bar to a sub panel and make it movable?
If a crash is happening, it is probably happening for a reason and I'd suggest trying to figure out why and fixing it. That being said the simple solution (because you are just exiting) might be to just task kill the application, once you are sure all hardware and file references are closed. Of course having a crash might indicate that you aren't actually closing all references so that might be something to look into.
I think this link describes a way of taskkilling:
https://decibel.ni.com/content/docs/DOC-28012
and here is a discussion on LAVA about why you probably shouldn't need this:
https://lavag.org/topic/16737-application-task-kill-on-exit/
In all the custom Windows functions I've used that deal with the pointer HWND I've never had to do anything with closing it in LabVIEW. I assumed it was just a number referencing a place in memory, and that number would point to a non valid HWND when the window went away. I suspect your problem isn't with not closing the HWND reference. You can write a simplified VI that uses this and I suspect you wont have a crash error on exit.
If you do a FindWindow() call the returned HWND is not refcounted at all but simply returns the handle. Same about reading the FP.NativeWindow property. Therefore you should not attempt to close that HWND yourself but it will rather be closed by whoever created the window in the first place.
However you will notice that the FP.NAtiveWindow property is an uInt64 value. That should not let you fall into the trap of defining the HWNDs to SetParent() function as an unsigned 64 bit integer. On LabVIEW for 32 Bit that certainly will mess up your stack. But defining it as 32 bit integer is equally wrong if you ever intend to run the VI in LabVIEW 64 bit. The correct configuration here is a pointer sized integer which will take care to adapt to the bitness of the current LabVIEW version.
Now another thing you should be careful is that if you have set the parent of a Window you should also take care of unparenting the child window before you destroy the parent. This happens by calling SetParent() again with a NULL HWND for the hParent value. Otherwise Windows will attempt to pass events up to the now inexistent parent window and that can explain some of your crashes.
And last but not least you may have to do some extra work when parenting and unparenting a child window. The documentation to SetParent() on MSDN states specifically that you should also adjust the WS_CHILD and WS_POPUP windows style flags when parenting and unparenting a window, since Windows doesn't to that itself automatically for compatibility reasons, but these flags do have an effect in how windows events are handled for parented child windows.
Use whatever signedness is returned by FP.NativeWindow. It shouldn't really matter in practical use but avoids a coercion dot, which is always nice to do.
