LabVIEW Scripting Main Board

[AristosQueue (NI)]

Finding out if a control is on the conpane is easy. Finding out which slot it has on the conpane is considerably harder:

[GregSands]

It seems that "Search 1D Array" will also find the index, and returns -1 if not on the conpane.  What seems a little strange is that the numbering is from the bottom-right corner, working up and left.

[crelf]

Odd - I would have thought it perhaps be in the order that you connected your FP nodes to the connector pane.

[DFGray]

The ordering usually starts from the bottom right at 0 and works it way across the connector pane.  This assumes you have not rotated the connector pane.  Here is a bit of documentation to give you the real story.  Unzip to a directory of your choice and open the HTML file.

[AristosQueue (NI)]

Wow. I have been looking under the hood of LV too much lately... I actually forgot about the Search 1D Array prim and wrote it out in its component parts. Doh!

[TiTou]

Hi

I'm using scripting to add cases to a state machine. My aim is to duplicate an existing frame, rename it and then change its position (like a "rearrange cases").

At the moment I use the "Duplicate Frame" method follow by the "Frame Names" property. It works fine but what suprises me is that after doing this the VI in which I edited the case structure has a broken arrow and does NOT have the "star" that says it has unsaved changes, then if I hit "ctrl + S", the modification is saved and the arrow is no longer broken..

What do I have to do to keep the arrow "not broken" and to get the "star" to tell me that my VI has unsaved chnages?

Thanks for any help

[Darren]

In order to get the "star" (also called a "doc mod" or a "dirty dot"), you have to set up an undo transaction around your scripting operation.  See my blog post about undo transactions here.

As for the broken run arrow, I don't know why that's happening.

-D

[TiTou]

Hi Darren,

I DO have the undo transaction, and it works, if I undo, the changes made by my utility VI are "canceled" and the VI is runnable again...

When I run my utility VI, as I said, the changes are made and the arrow is broken, but if I clic the broken arrow, as the VI is actually runnable, the VI starts running normally... Odd!

Side note : I've found out that many strange behaviour will occur when editing VIs in the NI.LV.Dialog context, for instance, if I select a part of my code and do "Edit > create SubVI", then I can't save it...

[Darren]

Ah, I see what you're saying.  Yes, even though the undo transaction is set, the doc mod does not appear in the title bar.  I think it's just a cosmetic issue, though, as if I try to close the VI right after making the scripting change (and the VI had been saved right before the scripting change), I still get prompted to save changes.  And if I cancel the Save Changes dialog, then the doc mod appears.

Still not sure about the broken run arrow, though.

-D

[TiTou]

Hmm.. the broken arrow after scripting is quite suprising... at the end of my scripting, if I use the "VI Linker Error" property on the scripted VI, it says "The VI is not executable.  The full development version of LabVIEW is required to fix the errors." and the arrow is broken.

BUT if I :

- save the VI, the arrow comes back to "not broken"

- clic on the broken arrow, the VI runs...

Is there a "scripting way" to force LabVIEW to update the VI's executableness? Maybe a re-compile?

UPDATE BEFORE POSTING :

YES ! Forcing the VI to recompile (scripting method > compile) brings back the arrow "not broken", BUT the doc mod is still off and if I close the VI, the save dialog doesn't show up and the VI close without saving the modifications