Detect pop-up using open VI references

hello,
I was wondering if there is a way to detect if a pop-up has occured in a VI, from another VI by using an OpenVI reference.... and maybe some property node. I can't find a way. I can reference controls on a VI, and detect if their values change, but I can't figure out how to detect if a pop-up has occured.
much thanks!

Hi,
I've created a little Project that contains a couple of VI's and a global Variable. One Vi detects a dialog pop-up occurring within the other VI as you asked. Hopefully you can tailor this to your needs.
Hope this helps, and any more problems, or if the solution needs any more tweeks, give us a shout
Regards
Richard.
Richard S
Applications Engineer
Certified LabVIEW Associate Developer
National Instruments UK&Ireland
Attachments:
Detecting POP-UPS.zip ‏19 KB

Similar Messages

Using Open VI Reference to run a VI, on an RT target, with sub-VIs not loaded

I've been using Open VI Reference and Call By Reference Node to remotely run VIs on my RT controller. I
usually wire string data to the vi path input, but this
requires the VI to be in memory. I understand (from LabVIEW help) that I can wire a path to this terminal and specify a VI that is
not in memory, but is on the disk. NI has an example that
confirms my understanding. I get errors when I attempt to do the same
with VIs that have sub-VIs; I suspect that the problem is that
the sub-VIs aren't in memory and that the top-level vi doesn't know where to
look for them (because the paths aren't specified). All of the sub-VIs are on the RT system (in the same directory), they're just not in memory.
Is there a way to get LabVIEW to look for sub-VIs on the disk? I don't want to rely on using a startup application and rebooting to get my VIs into memory.
Thank you,
Jim Carmody
Software Engineer
G2 Technologies
www.g2tek.com
Jim
You're entirely bonkers. But I'll tell you a secret. All the best people are. ~ Alice

Hi Jim,
It sounds like you are going about calling VIs remotely the correct way. It would be very helpful if you could post the errors you are receiving. I also wanted to know if you saw the note at the bottom of the article that says your VI library must contain everything your top level VI calls.
Eric A.
National Instruments
Distributed I/O Product Support Engineer

Open VI Reference for a Project Library VI

Hi,
my code calls some subVIs by reference by using "Open VI Reference" and "Call by Reference" VIs. Now, "Open VI Reference" expects a path to the VI:
When the SubVIs sit in the same folder as the calling VI, it is easy to simply supply the name of the SubVI. However, I would like to call a SubVI that is part of a project library sitting somewhere else on the disk. I could give the relative path, but this make the code pretty inflexible and if the relative path changes all the paths would need to be ammended. Ideally, I want to utilize the fact that I am using a project library. The help for Open VI Reference states that
vi path accepts a string containing the name of the VI that you want to reference or a path to the VI that you want to reference. If you wire a name string, the string must match the full delimited name of a VI in memory on that target. If you wire a path, LabVIEW searches for a VI in memory that you previously loaded from that path on the same target.
I thought that the underlined path was my ticket and tried something like this:
but this did not work and I got
"Error 1004 occurred at Open VI Reference in MainVI.vi:
Possible reason(s):
LabVIEW: The VI is not in memory.
To load a VI into memory with the Open VI Reference function, a path must be wired for the VI Path input."
Wiring a path is not desirable as per reasoning above. Is there a way around the issue?
Thanks in advance!
Solved!
Go to Solution.

tst wrote:
That should work, but you have to pay attention to something that's stated both in the help and in the error - if you use a string, the only way for LV to know what to access is if that something is already "in memory" (sometimes also referred to as "being loaded"). In the case of standard libraries, that means the VI itself or one of its callers has to be loaded. In the case of classes and XControls, loading the library (as in having it in an open project) should be enough to also load all of its members.
Hm, thanks, I am not advanced enough to know about classes and XControls, but I will check it out. My VIs are part of a library but obviously don't get loaded because, as you said, all their calls are dynamic.
tst wrote:
What I usually do is use a static reference to a VI to get its name, because that ensures that it will be statically linked, included in executables, etc. That might not work for you if you want dynamic loading and then you will need to use some other means.
Hm, this actually gives me an idea! I could add an enable input to all these dynamically called VIs so that the logic runs only when enable is ON; otherwise the VI is called but does nothing. Then I call the VI first statically with enable=OFF just to load it in memory and then proceed with my dynamic call. A little ad-hoc, but should work and serve my purposes, I think.
Thanks!!

Open VI Reference Error in the executable version only

Hello folks! I am having a strange issue since I updated to Labview 2014: I have a vi that uses "Open VI Reference" in order to programmatically open the desired vi. It worked flawless also in the compiled version (.exe) of the program until yesterday, when i compiled it again for the first time since my update to Labview 2014. It compiles with no problem, but when i start the exe and load the first vi it already gives me an error "Built Application or Shared Library (DLL): Missing".
The point is that all the VIs that i want to open are inside an LLB that is supposed to be compiled inside the .exe: infact the path that i use to open is:
D:\LabVIEW Data\builds\Sequenzer\Sequenzer2.0.exe\com_lv_sequenzer\trunk\Sequenzer_Functions.llb\Seq_Connect_to_Database.vi
And i get error number 7:
Open VI Reference in Seq_Function_Interface.vi->Sequenzer_Main_2.0.vi<APPEND>
VI Path: <b>D:\LabVIEW Data\builds\Sequenzer\Sequenzer2.0.exe\com_lv_sequenzer\trunk\Sequenzer_Functions.llb\Seq_Connect_to_Database.vi</b>
Built Application or Shared Library (DLL): Make sure all dynamically loaded VIs were properly included in the build specification for the application or shared library.
LabVIEW Real-Time: VIs built into executables cannot be accessed through VI Server calls. Use Source Distributions to dynamically call VIs on Real-Time targets.
The vi Seq_Connect_to_Database.vi is included in my built (as you can see in the attached screenshot and as it has always been).
Do you have an idea of why it is not working anymore?
Thanks a lot in advance!
Dario Cassaniti
Solved!
Go to Solution.
Attachments:
sequenzer.png ‏86 KB

OK, here is where I am confused. You talk about including the llb in the build, but in the screen shot you show a bunch of individual VIs being included. Next, in source file settings where are you telling the app builder to store all those individual VIs? Because they are VIs LabVIEW will, by default, want to put them in the executable somewhere.
Mike...
Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion
"... after all, He's not a tame lion..."
Be thinking ahead and mark your dance card for NI Week 2015 now: TS 6139 - Object Oriented First Steps

How do I use a static reference to keep a VI in memory but then call it in parallel?

Hello all,
I have a MainVI and I want to call from it a SubVI in parallel so that I can have both windows open and responsive at the same time. The SubVI may be closed and reopened any number of times, but only one in existance at a time. I know how to do this using Open VI Reference, providing a relative path to my SubVI, checking its state to see if its already running, and if so bring the window to the front (using Front Panel: Open method with True/Standard inputs), and if not run it using the Invoke:Run method (and optionally opening its front panel programmatically). This method was working fine.
Now I have added functional global variables in my SubVI, and I want to keep them in memory inbetween opening the SubVI window. I can do this by putting a copy of the functional global in my MainVI, even though I don't use it there for anything. This works fine.
By accident, I have come across a reference to a Static VI Reference, which sounded like a vast improvement to my methodology, for the following reasons:
1) Keeps SubVI in memory all the time, eliminating the need to put the functional global in MainVI when it is not used there.
2) Tells LabVIEW to include SubVI when I build my executable, rather than me having to specifically mark it as Always Include in the build specification.
3) Eliminates the need to keep the path and SubVI name updated in a string constant in my code, in order to use the Open VI Reference.
However, trying to implement this solution, I have run into the problem that once you put a strictly-typed static VI reference (strict typing is required to keep it in memory) onto the block diagram, that VI is reserved for execution. That means I cannot run it using the Invoke:Run method. I haven't tried just putting it on the diagram directly as a subVI because I need it to run in parallel to the MainVI. I have searched through these forums extensively, and although there are several references to a static VI reference, none of them say explicitly how to actually run the darn thing! :-P
I very much appreciate any insight into my problem. If I have to go back to the old way it will work fine, but I really like the seeming elegance of this solution. I hope that it is technically feasible and I'm not misunderstanding something.
Thank you for your help,
-Joe
Solved!
Go to Solution.

> If I understand you correctly, they can only really be used for re-entrant VIs.
No, a static VI reference can be used anywhere a regular VI reference (property nodes etc.) The reason for the hoop-jumping above is that we are really opening a reference to a CLONE (copy) of the VI identified by the static VI reference.
> Okay, I tried it, and got the code shown below... Any idea why it isn't working?
The VI you want to clone can't be on the diagram as a "normal" subVI. When you run your application you should be able to open that VI and see it just sitting there with a run arrow waiting to run. See attached example (LV2009SP1).
"share clones" vs "preallocate" has to do with whether you want each clone to preserve state (such as in an uninitialized shift register). Generally you use share clones. Occasionally it is useful to have multiple copies on a diagram that each remember some data, like "timestamp of last execution" in a shift register.
Other VIs in your spawned process don't have to be re-entrant unless they are functions that "wait forever". All the built-in G functions are re-entrant. It's pretty common to use a queue to feed data to a spawned process.
Spawning a process is more difficult than just running two parallel loops. It's useful because once you've made 1 copy, you can make 50. If you just want to do two things (vs n things) at once, I would just use two loops.
Attachments:
SpawnProcess.zip ‏20 KB

Open vi reference slow

Hi,
I have developed a packed library *.lvlibp with a few analysis vis which shell be called dynamically by an external exe. I call this vis via the open vi reference. Unfortunately this call (wait until exit of vi) takes very long. My test shows that when I call this vi via the vi-ref it takes 33 seconds - with integration into the external application via sub-vi only 400ms. Is there a way to accelerate this dynamic call? The values to the vi ref are set/get via the control-value attributes.
Any hints are appreciated.
Best Regards,
Joachim

Hi Joachim!
Maybe your vi is simply taking 33s to be loaded.
Try the following:
- embed your analysis vi in the main vi, in a section of code that is NEVER executed (e.g. FALSE case of a case structure, with a constant TRUE wired to it)
- try again to use "open vi reference" and check if this time is "quicker" (since the vi should be already loaded).
Regards,
Marco

Open vi reference by string in executable

Hi all,
Scenario: A top-most vi (main.vi) calls two subvis (subvi1.vi and subvi2.vi) separately such that they run in parallel. subvi1.vi has a front panel that appears when called, subvi2.vi does not.
subvi2.vi uses Open vi Reference to get a reference to subvi1.vi. It then uses this reference in a loop and continually polls the property FrontPanel.IsFrontmost to determine if the front panel of subvi1.vi is frontmost. When it is frontmost, it performs certain actions. When it isn't frontmost - it doesn't.
This all works great in the development environment, but as soon as I build this 'scenario' into an application I get the following error:
subvi2.vi is generating the reference to subvi1.vi using the string "subvi1.vi" as an input to the path terminal of the Open vi Reference function. Why does this cause problems in a built executable?
P.S. Clearly this scenario is actually a part of my much bigger project, hence I don't have any simple vi's to attach
Message Edited by Thoric on 04-27-2009 01:06 PM
Thoric (CLA, CLED, CTD and LabVIEW Champion)
Solved!
Go to Solution.
Attachments:
crash.jpg ‏28 KB

Thoric wrote:
Norbert B wrote:
Thoric,
it's disturbing that LV is crashing on your system due to this error. What version of LV do you use?
LV 8.6.1 at least (i don't know which version was the first one) creates the following error:
LabVIEW: Open VI Reference no longer matches VIs in memory by filename. A filename is no longer sufficient because the full name of a VI now includes any owning libraries.
This error occurs even in the developement system.
I asume that the crash itself is created by handling of invalid references.
hope this helps,
Norbert
Norbert,
I am using LV 8.6 (not 8.6.1). I am using strings to identify vis, not paths. I believe the error you are encountering only relates to using paths for referencing vis.
If your assumption is correct and my crash is due the handling of invalid references, then I need to generate a path to the vi, rather then using it's name. But generating a full (non-relative) path might be tricky? If within subvi2.vi I use the 'current vi's path' function and strip it to determine the executable path, then add subvi1.vi, should that get me the path to subvi1?
THis really depends on how you did your build. If VI1 ends up as dynamic file vs part of the app, the paths will be different. Easy enough to check. Look at where your exe is and figure out if VI1 is there in the support/dynamics. If not it is probably inside the exe to the path would then be "My.exe.VI1.vi".
But I am speculating thats the issue so try to get more info.
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

"Open VI Reference" Option "Prompt user to find missing subVIs"

I am using "Open VI Reference" to dynamically load a VI. For the "option" control of the "Open VI Reference" node, I pass "0x10" or "10" in hexadecimal, which supposedly "prompt user to find missing subVIs." Nevertheless, I don't get a prompt message dialog when I intentionally pass an invalid or missing VI path. Instead I just get an Error Code 7. What does this option "Prompt user..." suppose to do?

Make sure you set the properties on the integer input into the “options” control to the “Open VI Reference” to be a Hexadecimal format (right-click on the “options” control input, select Format and Precision…, then select Hexadecimal). Now, if you re-run your VI and wire in a VI with a missing subVI, the Open VI Reference will appear with a dialog that will prompt you to browse to the missing subVI. This is exactly the same message LabVIEW displays when it attempts to open a VI and cannot find its subVIs.
I’ve attached a simple example program to demonstrate. Enter the path to the “number extractor.vi” as the VI to open. You should see a dialog prompt appear asking for the “Search 1D Array – Complete.vi”.
Hope this helps!
Attachments:
openVIRefExample.zip ‏20 KB

Open vi reference in executables

My application requires to run two sub vis in parallel , Even though the VI is running the executable is showing reference.
I am using open VI reference to open the sub vi from the main vi
please reply..urgent

I guess your problem is related to the vi path. You should create some indicators for debugging. One indicator for the path, and some indicators on the error output. Then you can build your aplication for testing.
Besides which, my opinion is that Express VIs Carthage must be destroyed deleted
(Sorry no Labview "brag list" so far)

VI Server - Open VI Reference is using local path, not remote

First time posting to NI Developer Zone, so bear with me.
I have a PXI-1050 chassis with a PXI-8187 controller that runs LabView RT. I have set up this PXI system to utilize a VI server on port 3363 and opened access to my host PC which runs LabView 8.2 with the RT module.
I am having trouble openning a remote VI using the VI Server and the "Open VI Reference" function. I am fairly certain that the VI server is connecting using the "Open Application Reference" function, but it seems that the vi I wish to run cannot be found.
Here is the error that is thrown back to me
"Error 7
Possible reason(s):
LabVIEW: File not found. The file might have been moved or deleted, or the file path might be incorrectly formatted for the operating system. For example, use \ as path separators on Windows, : on Mac OS, and / on Linux. Verify that the path is correct using the command prompt or file explorer.
=========================
NI-488: Non-existent board.
VI Path: D:\LabView_Projects\VI_Server_Test_Project\/ni-rt/startup/temp_1.vi"
You will notice that the "Open VI Reference" is prepending the local path 'D:\LabView_Projects\VI_Server_Test_Project\' to my remote path. If I specify the path using Windows style path, e.g. 'c:\ni-rt\startup\temp_1.vi', again the remote VI cannot be found. I think I am missing something trivial, but I don't know what it is.
Thoughts?

Several things:
1. When u open the vi reference u must use and invoke node to make the Run vi, if you dont make it the vi is loaded but not running.
2. Insert correctly the path on your RT and the IP of your RT target
3. is better to have the variables on your HOST than on your RT becoz of two things:
- Not to use resources of your RT system as memory etc... is better to use the host ones that are more available
- The library needs to be deployed when running the vi on the host. If you put it on the RT it would need to be redeployed, so it is better to leave it on the host becoz of that.
4. Then as the library is on the host it needs to be deployed with the proper invoke node inside a stacked sequence to ensure is the first thing you do.
5. The enable RT fifo on the variables is used only to pass data between different vi's or processes inside the RT, it has no sense to enable it when sharing data RT - Host coz it is not possible, Shared variable work with TCP/IP not as RT FIFO.
See the attached vi for extra info.
I give u these extra links for your info:
http://digital.ni.com/public.nsf/websearch/F4010DD5C8D1B13D862565BC007384E9?OpenDocument
http://digital.ni.com/public.nsf/websearch/04D9A85B6967EE87862571140065EEC6?OpenDocument
http://digital.ni.com/public.nsf/websearch/48D244EC86971D3986256BD4005CCC28?OpenDocument
Regards,
Jaime Cabrera
NI Applications Engineering Spain
Attachments:
Compartida.zip ‏66 KB

Can anyone tell me how to get rid of tlb search? it unfortunately entered into my mac. Whenever I use safari, a pop-up window opens with some ads. Please help me to find a way to remove this malware.

Can anyone tell me how to get rid of tlb search? It unfortunately entered into my mac. Whenever I use safari, a pop-up window opens with some ads. Please help me to find a way to remove this malware.

You installed the "DownLite" trojan, perhaps under a different name. Remove it as follows.
Malware is constantly changing to get around the defenses against it. The instructions in this comment are valid as of now, as far as I know. They won't necessarily be valid in the future. Anyone finding this comment a few days or more after it was posted should look for more recent discussions or start a new one.
Back up all data.
Triple-click anywhere in the line below on this page to select it:
/Library/LaunchAgents/com.vsearch.agent.plist
Right-click or control-click the line and select
          Services ▹ Reveal in Finder (or just Reveal)
from the contextual menu.* A folder should open with an item named "VSearch" selected. Drag the selected item to the Trash. You may be prompted for your administrator login password.
Repeat with each of these lines:
/Library/LaunchDaemons/com.vsearch.daemon.plist
/Library/LaunchDaemons/com.vsearch.helper.plist
/Library/LaunchDaemons/Jack.plist
Restart the computer and empty the Trash. Then delete the following items in the same way:
/Library/Application Support/VSearch
/Library/PrivilegedHelperTools/Jack
/System/Library/Frameworks/VSearch.framework
~/Library/Internet Plug-Ins/ConduitNPAPIPlugin.plugin
Some of these items may be absent, in which case you'll get a message that the file can't be found. Skip that item and go on to the next one.
From the Safari menu bar, select
          Safari ▹ Preferences... ▹ Extensions
Uninstall any extensions you don't know you need, including any that have the word "Spigot" or "Conduit" in the description. If in doubt, uninstall all extensions. Do the equivalent for the Firefox and Chrome browsers, if you use either of those.
This trojan is distributed on illegal websites that traffic in pirated movies. If you, or anyone else who uses the computer, visit such sites and follow prompts to install software, you can expect much worse to happen in the future.
You may be wondering why you didn't get a warning from Gatekeeper about installing software from an unknown developer, as you should have. The reason is that the DownLite developer has a codesigning certificate issued by Apple, which causes Gatekeeper to give the installer a pass. Apple could revoke the certificate, but as of this writing, has not done so, even though it's aware of the problem. This failure of oversight is inexcusable and has compromised both Gatekeeper and the Developer ID program. You can't rely on Gatekeeper alone to protect you from harmful software.
*If you don't see the contextual menu item, copy the selected text to the Clipboard by pressing the key combination command-C. In the Finder, select
          Go ▹ Go to Folder...
from the menu bar and paste into the box that opens by pressing command-V. You won't see what you pasted because a line break is included. Press return.

I have a VI A. I want A to call another VI B and execute. After B executes, I want it to close automatically and go back to A. Is this possible ? I tried using open reference and those methods, but I am not able to do it. Can someone help me ? Thanks !

Thanks !
Kudos always welcome for helpful posts

Re: I have a VI A. I want A to call another VI B and execute. After B executes, I want it to close automatically and go back to A. Is this possible ? I tried using open reference and those methods, but I am not able to do it. Can someone help me ? Thanks !Hi Stephan ! Thanks ! I guess I explained my question not so right. I've created a customized menu and at the instance of me selecting a menu, a VI should load itself dynamically. I am using call by reference. Sometimes it works and sometimes it won't. In short, what I want to achieve is load VIs dynamically and close them dynamically once they finish executing. Thanks !
Kudos always welcome for helpful posts

Why does "open vi reference" wait for "mouse up"?

Hello,
I need to dynamically load a reentrant subvi as soon as the user hit's a button. I'm using an event structure which I dynamically register for processing a "value change" event. Inside the even structure I placed an "open vi reference" vi. I set it's options to "8" to prepare the subvi for reentrant run and the program steps into the event case as expected. The problem is, that "open vi reference" doesn't execute before the mouse button is released.
Is there any possibility to get "open vi reference" to execute while the mouse button is still pressed? (lock front panel... is disabled, "mouse down" event doesn't work either, static vi reference is not possible because I need several instances of the subvi).
Any idea would be welcome.
Thanks in advance,
C. Halbgewachs

There is something strange here, that has the smell of a bug...
The mouse down event is detected as soon as the event occurs, but the corresponding case is NOT processed entirely if the mouse button is kept pressed.
Most operations are immediately executed, EXCEPT the Open vi ref, or the File dialog vi, and probably some others...
For the File Dialog, this is normal, since a dialog window has to be opened (interaction with the operator) while the operator is still acting on the button.
But that's not normal for the Open vi ref.
First I thought that this hads something to do with file management or disk access. Wrong : Files are opened and read immediately.
The attached vi demonstrate this strange behaviour.
Enjoy !
Chilly Charly (aka CC)
E-List Master - Kudos glutton - Press the yellow button on the left...
Attachments:
Event Bug ?.vi.zip ‏19 KB

Error 7 occurred at open vi reference in New Report.VI

Hello!
I use the report generation toolkit on LabView 7.0 to create a report in Excel. The program works fine until I make an executable version. I the get the error:
Error 7 occurred at open vi reference in New Report.VI
I use the New Report.VI, Bring Excel to front.VI and Save Report To File.vi
Can you pleace help me!!!

Most likely, you did not include the required libraries in your build script. When building an executable in which you use the Report Generation Toolkit, you must include the _Word Dynamic VIs.vi from _wordsub.llb and _Excel Dynamic VIs.vi from _exclsub.llb as dynamic VIs on the Source Files tab.
Check this article for more info.
http://digital.ni.com/public.nsf/3efedde4322fef19862567740067f3cc/86256a47004e16d186256a84004cb883?OpenDocument
Daniel L. Press
PrimeTest Corp.
www.primetest.com

"Open Vi Reference" generates a Error 7

Hello,
I am getting "Error 7" from the "Open VI Reference" vi, the name of the vi is wired vi path input. The "Error 7" means that the vi cannot be found. So I went to "Tools ===> Options ===> Paths" and modified the Path so that Labview can find it. But for reasons I do not understand the vi I want to get a reference for cannot be found. So it leads me to beleive that the "Open vi Reference" does not use the path option to find a vi. Any ideas what is going on?
Regards,
Kaspar
Solved!
Go to Solution.

Hello,
Thanks for getting back to me. I have attached a file fo the screenshot of the Block diagram. The "Open Vi Reference" is in the upper left hand corner, which generates a error when I have updated the path options to point to where the file exists.
Regards,
Kaspar
Attachments:
vi_error.GIF ‏21 KB

Detect pop-up using open VI references

Similar Messages

Maybe you are looking for