jgcode

Yes.

Google VIPM

I like to use libraries when appropriate. In the first part of your question (not RT issues) - yes .lvlib file will be loaded along with the called VI(s) but can you go into detail about what problems this is causing you?

Very cute. Well done mate!

No last night it said 'Forbidden' (whatever http.status that is) - so I wanted to check if others had this issue. This morning it's working. So it could have been an issue on my end (mobile). Either way, all good now Thx.

Link doesnt work for me?

Ha! Looks like more like language barrier issues.

I'll take any opportunity to razz you up

You did what!?! ...Lol

I do the exact same thing - separating data from UI. I just like don't have issues with using locals to update a control when it comes time to push state data to the FP. There is one particular use case where I use them for the wrong reason but it's hidden - but yes you are right! However, normally I don't and don't need to break that rule

Whats wrong with locals? I usually prefer them over references to update a control. However, I the rule I use is: one per control on each diagram (in the case of e.g. a state machine).

The Shared Variable API is a bit more polished IHMO and recommend using it over DS as well - better error information etc... Although for reasons that escape me, I have used DS over SV-API for particular use cases in the past.

Well done!

Thanks Jim

I am not sure if that entirely true - you should be able to convert one datatype to another e.g. using a transitionary string and making sure the URLs are correct (as they are different).

You can't do this. If creating plugins like this the Parent Class is the 'interface' so you should design it to use DD to add new behavior from Child Classes - as opposed to case structures as you mentioned. Is a Control or View an Instrument? I would say no - so maybe you should look at a different type of relationship. For example setting the e.g. view with the instrument data rather than inheriting from it etc...

I haven't used it for a while - but if I remember correctly after the first read/write, it's a pretty similar speed. Should be pretty easy to test tho.

This package will be available for download through VIPM in a few days and contains new VIs for working with LVOOP data created by drjdpowell. The API has been designed with optimization improvements available in 2012 in mind. The palette has been approved by asbo [NEW] 3484610 - New LVOOP Data Functions Kind regards Jonathon Green OpenG Manager

Thanks everyone for their input - especially James for his donation of VIs. This OpenG Review is now closed. Please start a new thread to discuss new changes to this VI. Please PM me if there are any issues with this thread.

I have added a new version to the LAVA-CR - v1.1.0.39 which contains the following new features: - New (): Added 'New Templates' feature - New (): Added 'Methods Sandbox' feature - New (): Added 'Refresh Icon' feature There are now in built templates I use - you can pop-up on a Class and select New Template to add a template to that Class If there are other common templates, please post and I can look at adding them By placing your own templates in the Templates Folder... ...You can script new Class Methods with them Pop up on a Class and select Methods Sandbox This UI will allow you to quickly script either the inbuilt or custom templates to create new Methods: The last feature allows you to pop up on a Class Method to quickly refresh a Method's icon without having to open the Class Properties Dialog and refresh all icons

I have added a new version to the LAVA-CR - v1.0.0.23 This version supports LabVIEW 2011 and integrates into the LabVIEW Project Provider API The previous version was broken in 2011 as the Icon Editor API was not supported due to a switch to PPL 2011, so this functionality will not be included at the moment. I started playing around with the Provider API with Create Child Class which was a good plugin to start with. Along the way I found out that there was a limitation preventing me from releasing individual packages under one 'banner' so I will just be upgrading this package with new functionality in the future. And therefore won't be updating the Create Child Class package I posted - it will be done in this package. I've also moved the Rename LVOOP Labels code into this package as it more intuitive to use with the Provider. I need to brush up some stuff (examples etc...) but it this package is ready for feedback so please post So, in summary v1.0.0.23 supports: Rename LVOOP Labels Create Child Class Clone Method Right-click on a Class or Class Method VI to access the plugins: Go to Tools>>LVOOP Assistant to access other stuff: It also uses the Preferences code I OpenG'd up Enjoy!

Actually you could add links, text, pictures or even code. And the Community could maintain and add to it as opposed to an individual someone. Currently code in the CR is reviewed which I don't see the point of (too formal as you say) and a dedicated forum seems a bit of overkill?

In the past I've used .NET and the VI mje describes. I also using scripting to update a VI pre-build with the info programmatically. I generally use the latter approach for tools but it would work in an exe, it's just I have re-use code for the exe. I have posted a LabVIEW Project API and a build script on LAVA (sorry no link on mobile too) that you could look at as an example.

I guess the choice will depend on if you want to track the code and related posts (comments etc...) or just the code.