Caching a QD Plugin

[jgcode]

Sorry I don't mean to bug you when you are on your holidays Darren!

But I will definitely take you up on your offer when you are back in the office

Cheers

-JG

[LabBEAN]

Right, so references (e.g. File, Queue, VI, etc.) are protected by application instances.

I've had success using the Open Application Reference primitive to open a reference to a remote application instance where I wanted the VI to run, but with a few caveats:

(1) You need to know the port / server name of the remote application instance (e.g. 3363 = IDE).

(2) You would need to have a "Managing VI" running in the remote application instance which can call your "VI To Be Run".

(3) You would need an "Enqueueing VI" (see below).

A simple CBR (Call By Reference) across application instance boundaries causes the "VI To Be Run" to immediately become top level.  When this happens, the VI leaves memory after it runs (and shift registers / terminals reinitialize with the next call).  One method I've used to keep the "VI To Be Run" in memory is to use CBR to call an "Enqueueing VI" in the remote application instance.  This "Enqueueing VI" can obtain a named queue reference and enqueue a state which is dequeued by the "Managing VI" I mentioned above.  The "Managing VI" can then call the "VI To Be Run".  As long as the "Managing VI" stays in memory, your "VI To Be Run" will too.

That said, I'm not sure that applying this method can work here.  Maybe it helps you brainstorm?  (or maybe Darren has other ideas...)

[jgcode]

@LabBean - thanks I will check it out.

@ Darren - I have emailed you the code.

I am guessing this is related, but not 100% sure at this stage:

Another issue I may be seeing is that if I cache a VI like this, the GSW does not seem to show when I close all other active windows.

I am guessing because it think a VI is open?

LabVIEW is just minimised in the tray, and I can't get to it (e.g. I have to open VIs from disk to get to LabVIEW RTM).

Cheers

-JG

[LabBEAN]

Have you added HideRootWindow=True to your LabVIEW.ini file?

I've seen similar behavior where I couldn't get an EXE to exit properly without this setting (any VIs that are launched by the EXE end up getting their own taskbar entries unless you set HideRootWindow=True in the INI file for the EXE).  (Not sure why this isn't the default setting...  ?If you were to hide the last remaining top level front panel, maybe this setting causes the VI to leave memory?)

[jgcode]

Thats funny coz I just posted this on LAVA today

I tried it in dev-environment, but I don't recommend doing this as it has undesired behaviour!

LabVIEW is still running (as per Task Manager) but "removed" from tray!

[LabBEAN]

In my case, (if I remember correctly) the Quit LabVIEW primitive wasn't working properly unless HideRootWindow=True was included in the INI.  What is the undesired behavior you're referring to?

[Darin.K]

At the risk of triggering another auto-response, could somebody at NI please put a stop to these replies.  Call France, do something, I don't think I can take two more weeks of this.

"This is the only notification you will receive while this person is away." - I wish.

[Darren]

(I'll apologize pre-emptively for the auto-response that I'm generating right now...)

I've notified the proper authorities about this auto-response nonsense.  Hopefully we can get it straightened out.

-D

[jgcode]

Ok, with the help of Darren (thanks heaps!) I have been able to release a real cache'd plugin - caching a previous plugin to speed it up.

Here is the plugin code (which now acts as the launcher):

On LAVA there is some more info on how it was implemented and there is also a video posted to highlight the speed increase.

Download the example from here

Got the Getting Started Window (GSW) issue fixed thanks to Christina.

So my experiment is complete