LabVIEW
Programmatically deleting a splitter crashes LabVIEW
This simple code crashes LV in every version I have tested (LV2016-32bit, LV2021-32bit, LV2023-64bit):
I'm looking for a way to programmatically delete the entire splitter hierarchy from a VI's front panel.
Regards,
Raphaël.
I believe your problem comes from the fact that you use a static reference. As such the VI is part of the executing VI hierarchy and therefore is put in reserved mode. However scripting on VIs that are not in edit mode is not possible.
You need to open the VI reference explicitly through an Open VI Reference node and the correct path to your VI.
I take that back, the Splitter seems not possible to Delete. It also can't be selected in the front panel and deleted. You explicitly have to select the "Remove with Adjoining Splitters" menu but there seems no corresponding scripting method for that.
Hi rolfk,
Thanks for your response. Having a static VI reference in a script diagram forces it in memory but does not put it in reserved mode when the script is running. I've always done scripting like that without any problem. Also, opening the VI by path with "Open VI Reference" makes no difference.
Regards,
Raphaël.
Continuing further my investigation, the VI method "Empty" (that empties both the BD and the FP) also makes LV crash when there is more than 1 splitter to remove in the FP.
Thanks for the suggestion, but I can't even delete a single Splitter without crashing LV, and the only way to access the splitters in through the Front Panel's "Splitters[]" property.
As mentioned before, splitters seem to be a special object unlike other front panel objects. Apparently it's not so simple to just delete them, since they do interact with each other and the window itself to support the various resizing options. So deleting the object requires to inform all adjunct splitters and the window to be informed about this. And there is a special method for that in the pop-up menu. In the front panel the delete seems explicitly disabled for a splitter (selecting it and pressing delete doesn't do anything unlike for other objects) but in the scripting interface this has been overlooked.
The fact that the Delete method for that object simply crashes is definitely a bug. Even if it would be not possible to implement that method for some reason, it should be stubbed out and produce an error rather than going off into lala land.
@rolfk wrote:The fact that the Delete method for that object simply crashes is definitely a bug. Even if it would be not possible to implement that method for some reason, it should be stubbed out and produce an error rather than going off into lala land.
Completely useless, but...
Produces the expected error:
Search LabVIEW like a graph!
wiebe@CARYA wrote:
@rolfk wrote:The fact that the Delete method for that object simply crashes is definitely a bug. Even if it would be not possible to implement that method for some reason, it should be stubbed out and produce an error rather than going off into lala land.
Completely useless, but...
Produces the expected error:
In this case it is the Panel that is not deletable, just as the block diagram. It has nothing to do with splitters.
@raphschru wrote:
wiebe@CARYA wrote:
@rolfk wrote:The fact that the Delete method for that object simply crashes is definitely a bug. Even if it would be not possible to implement that method for some reason, it should be stubbed out and produce an error rather than going off into lala land.
Completely useless, but...
Produces the expected error:
In this case it is the Panel that is not deletable, just as the block diagram. It has nothing to do with splitters.
🌴🙄 (:palmface:)
Shouldn't (try to) do scripting right after lunch.
