jgcode

Great point, but for me I don't normally have a system in place for trapping, reporting and logging warnings though, only errors. Yes, there are designed correctly, IMO that same design should be used when a DVR is connected to a class method, but (the merging etc) should all take place behind the scenes. This is a specific use case, but that has come up frequently for me.

I prefer to use Google, for NI's site as well.

Hi Mike You can also just browse to a path on a VI Refnum constant to get want you want.

Well no, not really, (for the first part) and yes (for the second part) I just want to know if I should set re-entrancy on my class methods. The reason being I believe it will effect debugging by the developer (not functionality). Its just that if you (can) write a resuable function, document it well, have a good interface to it (descriptive controls labels etc..), chances are the user does not have to go into the VI to work out what it does (or that would be the point). However, with classes, I am sure you may want to get in there and have a looksy because it is more complex than a single function. And being re-entrant can make that process a little harder (although it can sure sharpen up your debugging techniques). I like your style! Right now I am looking to release code that e.g. serves as a base each thing I do all the time for my apps. So my use cases are well defined for extending the class. The other thing I do is password protect these distributions on release which serves to hide the private methods (in any library) and no one can accidentally edit those classes. This posses the same problems as the re-entrancy by decreasing the ease of debugging , (if you don't know the password) you can't see block diagram. Does anyone do this? and how do they find it?

Thats interesting I thought NI would recommend re-entrancy and use it too! I thought if I was calling a lot of functions in parallel (i.e from reuse library (vi.lib, OpenG, my library) it would be good to use re-entrancy? Interesting!

Well technically you don't have to merge the error in wire as you have the case structure catching any errors... but I know what you mean. I would like a single class method to accept DVRs. That way I would only have to create one method for ByVal that I can use ByRef If I wanted to string together a bunch of methods inplace then I would use the IPE and suffer the wrath of size on the BD and the error handing Right now I have create another VI just if I want to read one method and it is a PITA. I understand about the consequences, and I want the option. Please vote here to get this one through into 2010!

Thanks Yair. Yes, it will be dependent on the application. I do not (currently ) have performance issues that I am looking to solve. But I am trying to find out what other people do/how other people distribute their reusable LVOOP classes!! FWIW, referring back to my original post (RE: DD methods), a dynamic dispatch VI cannot preallocate a clone for each instance, so it must be set to shared re-entrancy only. Given you post, do you not use reentrancy for you reusable VIs? Cheers JG

Hi Martin - below are a few notes on dynamic process' and building executable that may be of interest. One easy way to launch a dynamic process (whether it is a daemon or a GUI) is to have a launcher VI in the library that has a static reference to the process. This will mean that the process is always included in the build. Otherwise you must specific it under include dynamic VIs as part of the build spec for the executable (or it won't be included). The other reason for doing this is that finding the VI is easy, you do not need to specify a path, as you already have a reference. This is handy as in 2009 the way an executable's internal structure is composed is not like an llb (although there is an option to do that). In the above png I don't have to worry about specifying a path, it is all taken care of by the static ref (the subVI just call the VI Run Method using the path as an input) Additionally the front panel of a VI will get stripped in a build unless otherwise specified. If your process is only a daemon (no Front Panel) this is ok, if it is a GUI then it is a problem. One way to deal with this is to include a property node to a Front Panel control (even if it does nothing), that should guarantee FP inclusion in the build. Additionally I am a big fan of the subpanel design where appropriate. It does depend on screen-to-screen interactions. Do no subpanel screens need to be opened at the same time (i.e. only one can be seen at any one time)? Do all screens have common run-time-menu and/or tool bar options? If yes then IMHO it can be a good candidate for a subpanel design. All main screens are contained in the one top level screen - so I find this to be neat. More work though, but it depends on the application.

Thanks for your reply AQ. As always I like to know what others are doing to make sure I am on the right track. I will keep as is, and stick with reentrancy.

When developers release their reusable LVOOP libraries, do they make all their method VIs reentrant? My other reusable code (functions etc... ) are reentrant unless for a specific reason. But when I create applications that use classes, on a whole, I don't normally have to make those classes' methods reentrant, and I don't feel I have any performance penalties (on a PC target) because of this decision. And these reusable classes are usually a replacement for those classes. One of the quirks of LVOOP is that the dynamic dispatch code must have the same reentrancy level throughout the hierarchy. So the developer who is extending the class is forced to use reentrancy on those overriding methods in their application code. I am trying to weigh up the need for performance versus ease of debugging (as it might not be just me who is using them). I know you can probes wires outside of the class normally, debug clones with breakpoints, and unit tests should be used to validate code etc... so is this really a big issue? Anyone got anyone thoughts on this? Cheers JG

Thats alright, I just thought I was going crazy Great post. I will have to spend some more time looking at what you have come up with before I can comment.

Here you go mate: Select_RTM.zip [LabVIEW 8.2.1]

Hi Martin There is a Current VI's Menubar primitive available in the Functions Palette >> Programming >> Dialog and User Interface >> Menu subpalette. This is a reference to the menu but you will have to pass it down from the Main VI into your subpanel VIs (or use a variable etc...) as it is not exposed through VI Server. Cheers JG

Sweet! I know you said your team was flat out so thanks very much kudos for putting this on. Will you be presenting?

Sweet, I knew I had quickly read it somewhere, I thought it was on the darkside. All good news

From the dark side:

Haven't we all...

Well LabVIEW locked files that where in my Recycle Bin today... weird.

Well... "Development Environment is required to fix error" and "Dynamically launched VI cannot run because it is broken" (or whatever) are cases where LabVIEW is not descriptive enough in my book.

I have 5. You win.

Ok, in the palette I just noticed that the Owning Library is pointing to the .lvclass file - to which the VI belongs - but the class is actually wrapped in a library (.lvlib). Could this be an issue? Is it a bug? Also when I view the palette through Advanced>>Edit Palette Set there are no red crosses. I will try scripting the palette with the new Mnu File API and setting the Owning Library to the .lvlib file and see what happens.

I will need to. I didn't know that feature went back that far. I try not to use 7 as much as I can, unless I have to program src for a client that won't upgrade... hmmm that topic sounds familiar....

Sorry, I thought you mentioned it on an NI forum. It must have been someone else. I am under the opinion that all VIs in a class get loaded into memory, but not all VIs in a library do. Can someone confirm this please (AQ )??? Great post, thx, its cool to hear someone else's approach to reuse. Do you distribute your reuse code in packages (e.g. .ogp or vip) to your developers? Sorry about the ambiguity, I was interested to know if you updated the reuse module, and you wanted you application code to link to this new version, how would it be handled automatically (which you have answered). I am purely looking at the benefits for namespacing, so I meant more beneficial when compared to a single class... ...but obviously access scope is the major plus if that is required, for a particular release.

No, nothing from my documentation. The Control Palette is fine (no crosses) and they are in the same library and have the same scope (public) as the functions???

You can namespace the class by wrapping it in a library. This is more beneficial if you have multiple class (in one distribution) that you want to rename for distribution.