LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Programmatically move project item without dialog

Solved!
Go to solution

Hi everyone,

 

I am developing a tool that automatically moves existing project items (VIs, Controls, virtual folders, libraries...) to a project library (.lvlib). This is a refactoring tool, so I want it to be tolerant in case some VIs miss dependencies or contain "esoteric" objects like XControls or XNodes.

 

The only way I found was to use this private method:

raphschru_0-1716818803368.png

Unfortunately, under certain circumstances (like missing dependencies), the execution of this method results in showing loading dialogs, which may allow the user to interfere with the scripting (e.g. by clicking the "Stop" button), on the top of taking a lot more time in case the dependencies cannot be found.

Even worse, sometimes a Save dialog appears, asking to save some caller VIs that are leaving memory. I tried ignoring them, but if I perform several "Move" in a row while ignoring these dialogs, it can lead to instabilities and completely freeze LabVIEW.

 

I have found this other private method that might hide the project dialogs, but was unable to make it work. I don't even know on which project item I have to call it (on the moved items, on the potential callers, on the project root or on all project items ?)

raphschru_1-1716819644957.png

 

Any help would be appreciated. With these annoying dialogs, automation is quite restrained. Ideally, I would like to automatically "Ignore All" on loading dialogs and "Save" VIs leaving memory without explicitly clicking on the dialog box.

 

Attached is a small example project that reproduces the "Save dialog" problem. The script just moves "SubVI.vi" inside "Library.lvlib" and reverses it on the second execution. In both directions, a save dialog appears right after calling the Move method.

Important info: I've added a dummy XControl as a dependency because this may be the cause of the appearance of the save dialogs. However, I want it to work even in the presence of an XControl.

 

Regards,

Raphaël.

0 Kudos
Message 1 of 9
(325 Views)

<RED_HARING_ALERT>

Not tested, this could all be a WoT.

</RED_HARING_ALERT>

 

I guess if you know the destination, you can add the subject to it:

wiebeCARYA_0-1716890643724.png

 

Don't know if that gives you dialogs...

 

You might need to remove it from it's original owner first (I don't know).

0 Kudos
Message 2 of 9
(272 Views)

If you can predict which VI's will trigger the dialog, this seems to have some effect:

wiebeCARYA_0-1716891609089.png

 

I set the property for a hard coded path of Caller.vi, and it's not asked to be saved anymore.

Message 3 of 9
(267 Views)

Thanks,

 

I've tested the public "Add Item" / "Add File" methods, but the item has to be deleted from the project first, so this is impractical in case I want to move an entire virtual folder. Also, Save dialogs still appear either at the "Delete" are at the "Add".

 

I've tested the "DoNotShowSaveChangesDialog" property on the 2 VIs that are giving me the Save dialogs (actually the "SubVI.vi" itself and the "Caller.vi") and it seems to work. However, it seems I need to open their ref first, then set the property to True, then do the Move, then save them on disk and close their ref.

 

Now it brings 2 more problems:

    1. I need a robust way for finding the callers in the project, even if not in memory, which it seems is not trivial at all.

    2. I need to open their reference, which can take ages in case of missing dependencies (maybe an App -> "Open.VI Without Refees" can help).

0 Kudos
Message 4 of 9
(251 Views)

@raphschru wrote:

Thanks,

 

I've tested the public "Add Item" / "Add File" methods, but the item has to be deleted from the project first, so this is impractical in case I want to move an entire virtual folder. Also, Save dialogs still appear either at the "Delete" are at the "Add".

 

I've tested the "DoNotShowSaveChangesDialog" property on the 2 VIs that are giving me the Save dialogs (actually the "SubVI.vi" itself and the "Caller.vi") and it seems to work. However, it seems I need to open their ref first, then set the property to True, then do the Move, then save them on disk and close their ref.

 

Now it brings 2 more problems:

    1. I need a robust way for finding the callers in the project, even if not in memory, which it seems is not trivial at all.

    2. I need to open their reference, which can take ages in case of missing dependencies (maybe an App -> "Open.VI Without Refees" can help).


That's scripting...

 

'Rowing against the stream' doesn't quite cut it. More like rowing through a sequence of brick walls.

 

Sorry, I don't have any answer ready.

 

It might not be feasable, or even possible. Even if you drag drop from the project tree, you 'll get a dialog.

0 Kudos
Message 5 of 9
(232 Views)

Well, I finally got it working using the private App property "App.SaveChangesAutoSelection":

 

raphschru_0-1716919319352.png

 

I have only tested it in some restrained use cases, but it has these advantages:

 - No need to know the callers of the moved item(s)

 - No need to load VI references

 - No need to perform some user interface "hacking" using user32 functions...

 

Regards,

Raphaël.

0 Kudos
Message 6 of 9
(204 Views)

I'd read the property, write 1 to it, and restore the original value, but nice find!

0 Kudos
Message 7 of 9
(175 Views)
Solution
Accepted by topic author raphschru

I think I solved my problem completely:

 - Removed searching for missing dependencies (by setting "App.SearchPaths" to an empty array).

 - Removed save dialog (by setting "App.SaveChangesAutoSelection" to 1).

 - Prevented instabilities by waiting for the save progress dialog to disappear.

 

raphschru_1-1717007240653.png

 

The only tiny flaw that may subsist is in case the "Progress" dialog name is localized. I don't know if there is a more robust way to find the dialog window.

 

Regards,

Raphaël.

 

0 Kudos
Message 8 of 9
(160 Views)

@raphschru wrote:

The only tiny flaw that may subsist is in case the "Progress" dialog name is localized. I don't know if there is a more robust way to find the dialog window.


I'd turn the name format on short names of CLFNs. Not sure why it's off by default, while for .NET and AX nodes names are on by default.

 

This might avoid the CLFN.

 

You can open any VI's FP (modal, tiny, and\or 99% transparent if you don't want to see it), and check if it's front most:

wiebeCARYA_1-1717057376207.png

If a dialog is open, it won't be front most... At least not when I tested it with a normal save as dialog.

0 Kudos
Message 9 of 9
(124 Views)