Search the Community

Hi, I am facing a weird situation and would like to get your insights. My application is quite large (>1000 VIs). When I run it, an initialization phase takes place, and around 10 or 20 objects are created (LVOOP). Most of these objects start their engine using the Open VI Reference and then the Run method. If they encounter any warning during that phase, they enqueue a message to display, and a dedicated VI keeps checking this queue and opens a LV Dialog (with just a OK button) when it finds an element. The purpose is to allow the initialization phase to continue instead of waiting for the user to acknowledge the window. Then when the init phase is complete, the user can just acknowledge all the dialogs one after another. (usually there is like 1 or 2, not much more). I ran my code this morning and was surprised to see that the init phase would still wait for me to acknowledge the dialog. A few probes showed me that the application was stuck in one of the Open VI Reference call. After I acknowledge the window, it would process normally. I am wondering what is causing this behavior and whether it is a known issue. Could it be related to the fact that the Dialog is modal and somehow holds the thread in which the Open VI Reference executes? This is weird, because other complex operations (connecting to a database,...) manage to execute while the dialog is open... Thank you very much for your help Emmanuel

I have a tool I'm creating and it searches the active project for all VIs recursively. I have found if I try to use Open VI Reference to an unsaved VI it fails (I am wiring up just the VI name as a string). It gives me error 1004, VI not in memory. However, if I go to that specific project and create a new VI and do open VI Reference with "Untitled x" wired as a string, it opens the reference fine. Does the tools menu somehow run in a different context where it can't open a reference to an unsaved VI? Is there a way to make this work? I should add, there are no problems when it's saved to disk and wired up as a path (somewhat obviously).