jgcode

I like the sound of this feature being integrated. However, it would not help if your constructor required inputs??? Thinking out loud... Would it be possible to flag a method VI as a constructor and somehow check that there are no constants on the BD (sounds tricky) What about when you drag and drop the class/control onto a BD it could automatically drop the flagged constructor VI instead?

(Just to clarify the above example has Static connections with the class Input as optional)

I agree, the API is not the best - having wrappers around each method (init, read, write) that only exposed the required inputs would be nicer, but you could always do that. Anyways, to answer your question, you only need to supply the information required for each method e.g. if you are reading from the buffer you do not have to input data. This image (ref: ni.com) sums up an example best:

I haven't used them in coding, but know you can do it. I can imagine it would be a nightmare to track and make an edit in a large app. Tomi showed me the above here and I have been using it ever since It does not need a Class input (that is optional but can be used by child classes that need to call it) The only thing I can think of is that if you have a plugin architecture and you need to call this you will need to wrap it in a DD VI anyways. Is it not a constructor? Well maybe not a real one, but close enough in a LabVIEW context? Please discuss - does anyone do anything similar, different etc...?

Hi Leonardo That's the link I would have posted too It shouldn't get more easier than that - the code is already written for you. If you are still stuck, maybe it would help to post some specific questions on what are the issues you having and we can try and help you out with those

Anyone recommend any good Sports Bars near the Convention Center (NI Week). Walking or cab distance. I am thinking big screen TV and who play Versus. ??? Cheers -JG

I managed to fix this issue now, thanks to Christina's post. My experiment of caching a Quick Drop Plugin is now complete!

Version History (Changelist): 3.3-1 2010 07 26 - Fixed (): Getting Started Window now shows when plugin cached in the background and no other VIs are opened - Added (): Reset to Original Theme Color button - Added (): Reset All Settings button

You can sort of...

Hi Shoneill One way could be to create a constructor for the Child class that sets the data to the default values you want.

Hi Christina, Thanks for your reply. That is good to know the exact criteria - which is what the issue would be here: My process does have a GUI so the FP can be opened, therefore I use the FP.Hidden state to hide the window in-between calls. (I was thinking it may be faster to load and I was also experiencing some issues using FP.Close and memory that I have since fixed) Anyways, I have changed this around now so the FP.Close is called each time and now the GSW window pops up with the process still running in the background! Thanks heaps!!

Thanks Ton, I don't want to manage showing the GSW etc, I am hoping it can be all handled by LabVIEW by flagging that VI to be ignored or something similar. I will check out the app props, in the meantime I have contacted Christina. Cheers -JG

[cross-posted to ni.com] Howdy ! I have run into the following issue when creating a tool for LabVIEW that continually runs in the background (daemon/process VI): By default, LabVIEW shows the GSW when all other files (project, VIs etc...) are closed. However with the process running in the background, it does not show the GSW! Has anyone run into the issue before? Is there a way to set LabVIEW to 'ignore' my Tool and get the GSW to show normally? The VI is running in the NI.LV.Editor application instance (the Tool is launched by Quick Drop). Cheers -JG

I asked the same thing - check out Darren's blog comments for his response.

Me too, I am worried I won't be able to get it all down on the BD in that much time!

Hi Tim Check out this topic here too. In it Mads has posted an external link that explains your options. Cheers -JG

Well, I am off to read it then

In case you didn't know.... The exam format for the CLA has now changed from: 40% written and 60% coding, to 100% coding. The exam is still four hours and the new one now requires you to track requirements too.

(I decided to make this its own topic in case anyone wanted to search on it later etc...) With the help of Darren (well, he did most of the work really) I have been able to cache my Quick Drop plugin. The reason I wanted to cache the plugin was to decrease the wait to load the plugin each time. This wait was just long enough to be annoying (and hey, to be honest I am just not that patient to start with). And is due to the plugin containing a UI, libraries and classes etc... Here is some side chatter in the Community (darkside) about caching a plugin if you want to check it out. The plugin uses VIs from a VI Analyser toolkits to maintain the QD's VIs reference between LabVIEW application instances (as the reference was becoming corrupt) There is also some handshaking to keep the launcher in memory so as to stop the spawned VI from going out of memory or not load the UI (another issue I had) - this was the easiest form of handshaking So if you are interested please check out the latest version: Known Issues: When the plugin is cached, the Getting Started Window (GSW) will not appear as a VI is still 'open'. I currently to do not have a work around for this, only to use (Ctrl + Shift + X) on a call to the plugin to uncache it and then the GSW will appear. If you have any feedback please post. Check it out the increase in speed, quick enough I say: <object id="scPlayer" class="embeddedObject" width="1065" height="838" type="application/x-shockwave-flash" data="http://content.screencast.com/users/jgcode/folders/LAVA%20CR/media/f9b0763c-d66b-4619-9732-ea809ddf773f/jingswfplayer.swf"> <param name="movie" value="http://content.screencast.com/users/jgcode/folders/LAVA%20CR/media/f9b0763c-d66b-4619-9732-ea809ddf773f/jingswfplayer.swf"> <param name="quality" value="high"> <param name="bgcolor" value="#FFFFFF"> <param name="flashVars" value="thumb=http://content.screencast.com/users/jgcode/folders/LAVA%20CR/media/f9b0763c-d66b-4619-9732-ea809ddf773f/FirstFrame.jpg&containerwidth=1065&containerheight=838&content=http://content.screencast.com/users/jgcode/folders/LAVA%20CR/media/f9b0763c-d66b-4619-9732-ea809ddf773f/Caching%20a%20Plugin.swf&blurover=false"> <param name="allowFullScreen" value="true"> <param name="scale" value="showall"> <param name="allowScriptAccess" value="always"> <param name="base" value="http://content.screencast.com/users/jgcode/folders/LAVA%20CR/media/f9b0763c-d66b-4619-9732-ea809ddf773f/"> </object>

New Version Version History (Changelist): 3.2-1 2010 07 20 - Fixed (): Caching the plugin caused an error whereby the QD'd VI's Reference become corrupted between application instances. This was fixed using VI Analyser functions (mad props to Darren who sorted this issue out for me). Known Issues: When the plugin is cached, the Getting Started Window (GSW) will not appear as a VI is still 'open'. I currently to do not have a work around for this, only to use (Ctrl + Shift + X) on a call to the plugin to uncache it and then the GSW will appear. See this topic for more info on caching.

Hate to raise an old post... NI even used a Val(Sgnl) PN to cover a requirement in their CLA solution example !

Please post when you have time ! I love reading your stuff. Sorry, thats my fault, I will try not to take stuff so literal Wrt the internet - that is the one thing I still have trouble grasping. Gees, sometimes I don't even know where I am coming from! I have found, that this architecture is great (theres that word again) for the backbone of my screens (dialogs, data entry etc...) in most of my apps. I find that using LVOOP I can encapsulate so much, that using a QSM as a Top Level VI can work fine in a small-to-medium size app. As I have found it's pretty clean, when I am just (as Justin puts it) sequencing things. But I have also seen its limitations or how it can be implement badly to create garbled code (with the points you raised thus far) and try to avoid those. Also, programmers have been creating Large Applications for a long time, before LVOOP was around, so I trust the veterans, and am confident that these design patterns are quite robust and have been used extensively. On the flipside, I am, as mentioned above, very interested in seeing the new breed of LabVIEW design patterns, most likely implemented in LVOOP (as it really is so powerful), that the community will develop / already have. I am excited to see these and there seems to be a big push for it in the community, that hopefully they will start getting fleshed out, shared, standardised. and supported real soon.

It would have been cool if she belted out a tune at the end. Maybe they should have got these guys to do it?