06-25-2015 05:17 PM
I just encountered a crash that I can duplicate in both LabVIEW 2013 and 2012 (student).
Attached is a project that contains the code I used on 2012. Run the target VI.
(I can get the project I had in 2013, if needed, sometime next week)
Basic steps:
06-25-2015 05:46 PM - edited 06-25-2015 05:47 PM
Haha, I saved your code and ran it while I still had another project open... didn't really think that one through. Thank you, Auto-save.
So it looks like the crash happens at the Create node. I can get rid of the crash by removing the Type Def link from the enum.
I'm not at all an expert in scripting and have only used it a few times. Could a workaround be to get a reference to all of the Controls on the FP and copy the Control with the same Label "Enum" (instead of loading the terminal and creaing a new terminal)? Maybe creating a typedef by data type is what's causing the crash, but copying an already existing control will work.
Cheers
--------, Unofficial Forum Rules and Guidelines ,--------
'--- >The shortest distance between two nodes is a straight wire> ---'
06-25-2015 07:54 PM
Name doesn't matter (tried "Numeric")
Actual control type doesn't matter (Tried numeric and cluster or random things)
Stored the typedef into an indicator, changed that indicator to a constant, piped that constant into the "Create from Data Type". Crash. It's not the way I gathered it.
Apparently it doesn't like TypeDefs
06-25-2015 08:07 PM
Still crashes in the latest LabVIEW version.
I couldn't find any CARs about this behavior but I can file one tomorrow if now one is able to find any documentation that says this is expected behavior. If anything, it would be nice to have documentation in the help file telling people it won't work with type defs.
06-29-2015 09:45 AM
For people who run into this crash, here is my work-around.
Use the Terminal invoke method "Create Constant"
This this sometimes creates a wire between the constant and the terminal. Delete/recreate that wire, or delete a node and cleanup.
(I would have created from the TypeDef path via GetTypedefPath.vi, but that VI didn't return the path when I input the Data Type variant)
06-29-2015 11:44 AM
JW-JnJ,
I filed CAR #534812 to describe this behavior.
An alternative workaround I found was to use the DisconnectFromTypedef.vi in the vi.lib folder. This also holds the ContainsTypedef.vi to check if the variant is from a type definition.