You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, there is no check to see if the VI being set as the Top Level VI actually belongs to the project or not. That is a bug.
Steps to reproduce:
Create a blank project (you can also do it with a saved project, but why modify it?). Save the blank project somewhere, Close the project.
Create a VI and save it or open a saved VI.
Now, from the File menu, open the recently created blank project. As the VI created (and still open) in the above step is saved, it will not get added to the project you open here.
Now, try setting the top level VI. Even though the project is empty and has nothing in it, the VI from step 2 is assigned as the top level VI.
Running the top VI opens a new window in the project's context and it runs. It also gets added to the project under Dependencies>Items in memory. But the actual project window remains blank. So we now have a top level VI in a project without VIs. Or worse, if this is done with an already opened project and VI, one could potentially add a VI from another project into a different one as a Top Level VI.
I believe checking for this using the following property nodes and adding the appropriate case structures can help in resolving this.
The text was updated successfully, but these errors were encountered:
I believe I have a fix for this that involves getting the project reference from the VI reference instead of just getting the "Active Project" in the main plugin VI. This will also have the benefit of working when multiple projects are open as, from what I can tell, the last opened project is the "active" one. I will put a build in the Discord for people to test out before I put in a pull request.
crossrulz
added a commit
to crossrulz/top-level-launcher
that referenced
this issue
Nov 29, 2024
Currently, there is no check to see if the VI being set as the Top Level VI actually belongs to the project or not. That is a bug.
Steps to reproduce:
I believe checking for this using the following property nodes and adding the appropriate case structures can help in resolving this.
The text was updated successfully, but these errors were encountered: