01-19-2015 05:06 PM
I cannot say exactly why my brain thought that would work. It was one of those things where some neurons in a dark corner said, "Psst. Try this. Don't ask where it came from."
01-20-2015 09:52 AM
Well, that horse is not dead yet, so I'm still beating on it.
I tried this morning, and the same symptoms reappeared.
I had saved the master VI with USER INTERFACE thread selected - I verified that.
It still did not apply the changes to the non-STRICT typedefs.
I put back the delay and it works.
Then I tried taking out the delay and putting the master into SAME AS CALLER (default) - it doesn't work.
Then I put it back into USER IINTERFACE..... and it works.
Something about the TRANSITION between ExeSys seems to straighten it out.
Blog for (mostly LabVIEW) programmers: Tips And Tricks
01-20-2015 10:34 AM
OK, this is weird.
As shown above, I have a "master" VI which calls the script subVI once for each CTL I want.
I saved things with the script SubVI set to SAME AS CALLER, and the master set to USER INTERFACE.
That should make the subVI run on the UI ExeSys, right?
Well, after starting from POWER DOWN, Running the master will work exactly ONCE, and then refuse to work any more.
If I change the MASTER from UI to STANDARD and back to UI again, then it will work thereafter.
If I save the scripting subVI with ExeSys set to UI, then it seems to work, even after a POWER DOWN.
(* crosses fingers* )
Blog for (mostly LabVIEW) programmers: Tips And Tricks
01-20-2015 10:48 AM
At this point, I think I would stick with the time delay unless/until someone from NI has time to dig into the issue.
Unfortunately, there's enough other stuff on my plate, I doubt I have time to do so anytime soon. The only other option is to escalate this through your support channels and get an AE to investigate it -- for me it is a side job, for them, that's what they do all day.
01-20-2015 10:54 AM
Yeah, that's not it either. It's still a "sometimes it does, sometimes it doesn't" thing, unless I use the time delay.
I'll see if I can form a coherent question and go thru proper channels.
Thanks for your ideas, though AQ.
Blog for (mostly LabVIEW) programmers: Tips And Tricks
01-20-2015 04:18 PM
Saving does not apply changes (except for LabVIEW class private data controls). Closing the control VI's window will apply changes.
Well, it turns out that this is not quite true, at least for other cases.
I'm now trying to apply the same steps to a typedef'ed TAB control.
I'm doing the same thing, except for a non-Strict TypeDef, the changes do NOT propagate unless you add a SAVE operation after setting to STRICT.
1... If CtlVIType is TYPEDEF (not strict)
2.... FP.Open
3... CtlVIType = STRICT TYPEDEF
4... FP.Close
5... VI.SAVE INSTRUMENT
6... FP.Open
7... CtlVIType = TYPEDEF
8... FP.Close
9... VI.SAVE INSTRUMENT (either way).
For CLUSTERS, the instances update after step 4 and I don't need step 5.
For TAB CONTROLS, it WILL NOT update (even single stepping) unless there is a SAVE at step 5.
Not Quite Ready for Prime Time, I'd say.
Blog for (mostly LabVIEW) programmers: Tips And Tricks
01-20-2015 06:59 PM
OK, the ONLY thing that will make it work first time, every time is a delay.
Attached is the SAVE part, which I have made into a subVI, so that I can use it on typedef clusters and tab controls, and whatever.
As shown, it works even immediately after a power up.
If I remove the delay, it will fail at some point.
Blog for (mostly LabVIEW) programmers: Tips And Tricks
07-27-2016 02:54 PM
I found that if you adjust the position of the typedef control by reference it will force an update.