jgcode

Just guessing: Is it because you are not initializing that local variable and you have a race condition? .

Don't worry it's not like we never went through the same exercise figuring this out. Learning is fun!

Another example includes making skinable UIs - if you want to have two different UI themes or resolutions etc... The UIs should be thin (to avoid redundancy) and you have an engine VI to handle events. I have made a thin UI before so as to disassociate the UI from engine. Its more work but can be beneficial.

It allows for code reuse. It's use is really going to be dependent on your class structure / project.

I think the issue is that you are expecting that data in the Child Class in being acted when you call Call Parent Method (i.e. your bottom solution) but the data that is actually being acted on is going to be in the Parent Class (i.e. your top solution) - which makes sense as the Parent does not know anything about a Child. What you need to do is set the data in the Parent Class by calling the appropriate method (assuming that you have such an attribute as you haven't posted class' data members) then call Call Parent Method.

Thanks for the information David. I will update the Team LAVA requirements in the near future to be inline with these requirements. I like the idea of grouping all toolkits under the one LAVA palette as (from looking at the LAVA-CR) a lot of submissions are unique. If a developers has a package that fits a NI palette then it should go under that palette (providing we have access of course). However, I would still like that palette under the LAVA palette as well, so I can find everything in the one spot. What do others think?

I would also like to conclude this review with the original (simple) code as well. As Darin pointed out, there are a few behaviors to consider. Would this 'chunking' feature be better suited to a new function? If so, let me know, and it could be reviewed in the future. Cheers -JG

I know it is a small change, but I don't think that is a good enough reason to justify a(ny) feature.

There are some good reasons there - I looked at the Select Case node type too when reviewing what to use. I would argue that a NI comparison is more familiar to users than the Select Case - and we are still doing a comparison but there are more inputs. What are others take on this?

That's cool. But what about if the name changes e.g. the dist code is namespaced whilst the source is not. We now use the Library Name to namespace the code and want to remove the original VI namespacing. E.g. "an_openg_function__ogtk.vi" becomes "OpenG Library:an_openg_function.vi" - then we would be needing some tool (something I have already given thought to) to handle this.

Just a quick note: I want to make sure we avoid feature-creep (in any review), just adding features we think we need. Keeping in mind we can always update VIs in the future if needed. Having said that, if you feel strongly that a feature should be added, now is the time to let everyone know about it. Cheers -JG

Well done :beer:

I am on iphone and can like using the button on the top right hand corner of a post (tick symbol). I might be misinterpreting 'Abstract File Interface'? But the File Interface Class is a dependency from another package. The Interface Class' default behavior is to use OpenG format (as using LVOOP why just have an functionless based Class and extra Child? - I prefer less work ) One issue with the implementation is that the interface (as in a Connector Pane context this time) is a variant. This may seem a little dirty but it means the Cluster does not have to be a type-def (preventing issues of a TD Cluster in a Class) and that the File Interface can be re-used across or in other Classes.

With a reference to QD you have won my vote No, I think they are all valid points you have made to update the name 'if' it only accepts string input. Also a valid case for .lvlib namespacing.

. 'If' this VI is in the string palette and only accepts string (as is) then this can be implied - much like Trim Whitespace (from string)? I am open to this change.

I think we have some good code. I will change this review to pending and close it in a few days if there are no further comments. Then add this VI to an upcoming OpenG String Library package release. Cheers -JG

For hellos... ...You may already know him, but I wanted to give a shout-out and a warm LAVA (ha! get it?) welcome to David Ladolcetta (check him out on NI or LAVA). David has taken over from Chris Bolin (NI, LAVA) in the role of Partner Producer Engineer. He is the go-to man for LabVIEW Tools Network and along with Will Schoettler has been helping me out - kudos! If you want to get your code published under your own brand etc. he is the person to contact (having said that, for all publishing though LAVA please contact me). So, on behalf of the Community welcome to LAVA David! And for goodbyes... ...Chris Bolin left around NI Week and was very helpful and supportive of OpenG and the LabVIEW Community in general and will be missed. Among other things, Chris was the original author of the OpenG Toolkit which gives OpenG a presence on the LabVIEW Tools Network and links to the OpenG Libraries - you can read more about it here. I would personally like to wish Chris all the best on his endevours post-NI (I heard he's off to MIT!) and that his work at NI was much appreciated. Kind regards Jonathon Green

Did your friend say it was easier? - Given they have something to compare it to of course (previous attempt, sample exam etc...)

I guess it would only win if its invalid?

I (hope not and) highly doubt that they would have made the exam easier, as that would water down the process. It may be the case the the new CLD exams are harder, or that they want to help streamline the marking protocol by providing these starter VIs etc...? The CLA Exam Preparation Guide has been updated as evident by the July 2011 footnote. If you are taking the exam and are unsure on changes I would be contacting certifications (certification@ni.com) for clarification.

Check out the new Team LAVA logo in this Article, created by LAVA's very own Vugie! The logo incorporates the LAVA name and logo into a community/team theme. I love it! If you want to get... View the full article

Download attachment: Team LAVA logo.png Attached are various formats. Download attachment: Team LAVA logo.zip Click here to view the article

Check out the update Darren has done to the Quick Drop Plugin "Move Terminal Labels". It now supports moving Reference Labels, Nested Diagrams and Selections. He is adding it to LabVIEW 2012 but has released a LabVIEW 2011 version. Love it! Cheers -JG

That was always an error (by me) - it should be optional. Do you like the CP style (was my question tho)? lol That was me (but it was too slow compared to MP).