LabVIEW APIs Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

How to apply changes from TypeDef

Hey - I have finally found a use for scripting!

Been lurking for years but everything I wanted to do via scripting was a one-off and would take less time to do it manually, than invent a script.

Now I have my first practical use of it.

I have several TYPEDEF'ed clusters, which all need to be the same size, for cosmetic reasons.

I have the attached procedure, which opens up each one, unscrolls the window, moves the cluster to a standard position, sets the window size, sets the cluster size, and saves the CTL file.

Some of these are STRICT typedefs (because I prefer them that way).  Some MUST be non-strict, because I need to diddle them at run time (example: Disabling the CUSTOM RTD fields unless the user chooses CUSTOM RTD.

On the STRICT typedefs, this procedure works OK, except for question 1.  It does all the things I ask, and the instances within the program automatically update.

On the NON-STRICT ones, it updates the CTL file as expected, but not the instances within the program.

Script.PNG

QUESTION 1: Why is it that, if I shrink the STRICT TYPEDEF by say, 20 pixels vertically, the instances of it change their POSITION to increase their margin by 10 on the top and 10 on the bottom?  In other words, the center of the new thing remains where it was, but BOTH the top and bottom move inwards?

I see that when doing it manually, so I guess it's not a script fault, but is there a way around it, or do I simply have to re-position all instances of it?

QUESTION 2: When I do this manually, I have to change the CTL file to STRICT, then APPLY CHANGES, then change it back to NON-STRICT and then save it.  I don't see a way to set STRICT/NON-STRICT or to APPLY CHANGES, from the scripting tools.

Any advice?

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 1 of 18
(12,205 Views)

OK, it's amazing what the POST button does for me.

I was looking in the properties for the cluster - wrong.

In the properties of the VI itself, there is a CtrlVIType property.

I suppose I have to set it to STRICT, SAVE it (which will apply changes), set it to NON strict, and SAVE it again.

That means all instances must be open, or the changes won't be seen.

Is there a better way?

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 2 of 18
(8,462 Views)

Saving does not apply changes (except for LabVIEW class private data controls). Closing the control VI's window will apply changes.

Message 3 of 18
(8,462 Views)

Closing the control VI's window will apply changes.

OK, I added the attached code to basically duplicate what I do manually.

However, if I don't wait long enough after the CLOSE, the changes don't take effect.

In this case, waiting 50 mSec never works and waiting 100 mSec always works, but what does that depend on?

Likely it's the size of the CTL file, the number of instances, the speed of my machine, who knows what all else.

Is there a better way?

Script 2.PNG

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 4 of 18
(8,462 Views)

> Is there a better way?

I think yes. After you call FP.Close, call FP.Open again. The open won't happen until the close is fully committed. For "State", use "Hidden" instead of "Standard" (use that on your first FP.Open call also so you don't get windows flickering).

And then, of course, you'll need another FP.Close after you change the type a second time.

0 Kudos
Message 5 of 18
(8,462 Views)

After you call FP.Close, call FP.Open again. The open won't happen until the close is fully committed.

That didn't work.  The behavior didn't change. (see attached pic).

If I wait 100 mSec before step 22, all is well.  If I don't, it just doesn't apply the changes.  The CTL file itself is changed, but it doesn't get propagated.

If I single-step thru it, or even run with highlighting on, it works.  But at full speed it fails.

This is LV2013, BTW. 

For "State", use "Hidden" instead of "Standard" (use that on your first FP.Open call also so you don't get windows flickering).

Yes, that was just so that I could see that it's opening the window.

Script 3.PNG

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 6 of 18
(8,462 Views)

Even if I do:

FP.Open - Set STRICT - FP.Close - SAVE - FP.Open - Set nonSTRICT - FP.Close - SAVE

It fails, unless I put in a WAIT before setting it back to nonSTRICT.

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 7 of 18
(8,462 Views)

Guten Tag,

Ich bin im Uraub bis Dienstag den 03.02. und in dieser Zeit auch telefonisch nicht zu erreichen.

Wenden Sie sich in dringenden bitte an Elke Härtel (Tel: +49 (4202) 9 53 53 -0).

Mit freundlichen Grüßen

Thomas Bartels

--

<thomas.bartels@ltm-data.com

0 Kudos
Message 8 of 18
(8,462 Views)

Ok... I have one last idea to try. Open your scripting VI. Open the VI Execution Properties and change the Preferred Execution System to "user interface", as shown in the picture. Run it without the time delay. Does that work? If it doesn't, I'm out of ideas.

Untitled.png

0 Kudos
Message 9 of 18
(8,462 Views)

YES!

Putting the parent scripter into USER INTERFACE ExeSys (it was in the default "Same as Caller" ExeSys).

fixes it, even without a time delay.

It takes longer to run, but I don't care about that.  It is reliable.

I'm back to the sequence:

FP.Open - Set STRICT - FP.Close - FP.Open - Set nonSTRICT - FP.Close - SAVE

And it works reliably. 

I wonder why.   It would seem that the FP close stuff would by nature be required to work on the UI ExeSys.

Perhaps the scripting SET nonSTRICT part was working on the default ExeSys and was executing before the changes had propagated.  This change forces it in line.  I suppose.

Thanks, AQ !

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 10 of 18
(8,462 Views)