jgcode

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 think it should be added. It can be added easily to the current code. Just make the 1 constant a input variable and set 1 as a default.

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

On my OpenG Comparison Tools palette, there is one item (Data Changed).

I would suggest that since there are no 'typical' nodes that we could standardize on a the larger 'Select' triangle along with a 5-3-3-5 pattern.

Rationale:

OpenG comparison functions will be extensions of existing functions and require additional inputs/outputs.

5-3-3-5 allows us more choices for the inputs and outputs.

The larger node provides additional room for text inside and differentiates the node from the native node.

Comparsion.vi

We could also make it an Express VI

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?

> Our could we hack some update code in congregation with NI?

You don't have to hack...

...This is why upgrading from no library to library is easy. It is why upgrading to a different library ownership requires the same machinations as renaming the VI file itself.

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

And for what it's worth, I got my results yesterday and I passed!

Well done :beer:

Edit: I misread part of your last post, doesn't look like there is an abstracted file interface. What can I say, it's late and I'm tired. Also appears not to be a way to "like" a post from the mobile version of the site. /sadface

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.

That's true, that it's implied by virtue of it being in the string palette, but it's name is not scoped to "OpenG String.lvlib" so there's the possibility of a name collision with some other OpenG VI. Also, if someone is using QuickDrop (Darren Rocks!!!) then they won't know that "to Character Array" takes a String as an input.

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.

Should this VI be called "to Character Array" or "String to Character Array"?

.

'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

I'd heard hearsay (and I honestly remember from where) that the CLA and CLD were getting easier. Take this with a grain of salt, YMMV.

My friend went to a CLD prep session at NI week and I can confirm that they are providing the front panels now with the tests and you save your work to the flash drive.

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

You did raise a good point about check the length first (I thought that it should be faster) but it seems the original VI wins out by a tiny margin. Weird.

I guess it would only win if its invalid?

It seems that NI has changed the format for the CLD exam. They give you a USB stick with some VIs and controls to get you started. Nice time saver!

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...?

Does anybody know if the CLA exam format has changed? I saw something in the prep guide about classifying requirements

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

Considering the alternatives, yes. I would be very tempted to make that connection optional.

That was always an error (by me) - it should be optional.

Do you like the CP style (was my question tho)?

Well then try not to let that happen again.

lol

I saw the word Regex thrown around which to me means PCRE (Perl compatible..).

That was me (but it was too slow compared to MP).

The Strict Case? input looks fine to my eye, although it appears to be required now.

Yes, that is just an example (not uploaded to the repo) for discussion only (at the moment) - my LabVIEW options are set as CP Required (apologies for any confusion - I have edited the image).

So you like it in the middle of the Comparison icon?

Just because NI f'ed up bad with those functions does not mean we have to.

No I meant OpenG... Ha!

Clearly you are not digging too deeply into what makes a valid MD5 hash

Can you go into detail please?

Sorry, I'm on 8.6 with no time or resources to have 2009 around.

That's no dramas, I would want the code review to stay in LabVIEW 2009.

Anyways, you can easily contribute (if you want to) CP ideas from 8.6.

Here I got you started

Comparsion.vi

Code is in LabVIEW 8.6.1

If I recall correctly, the code in the disabled structures is treated the same as a comment in text based langauges. It does not get included in the built executable.

Yes, this is what the help says:

Diagram Disable Structure

In the Diagram Disable structure, shown as follows, LabVIEW does not include any code in the Disabled subdiagrams when compiling.

LabVIEW does allow you to build a 'debug' exe. I don't know if the disabled code would be included or not...

I would have assumed debug mode to be similar to edit mode - but it probably doesn't matter what it does because you can't edit the code (obviously).

- HillCipher, available also somewhere on the web

Christian Loew implemented it for Reference Design for Adding Licensing to LabVIEW Real-Time Applications (I have used the code for a licensing requirement - its really good) and he also has it available here.

FWIW this is a work around I use at the moment when I want a human readable file.

Adding a non-type def cluster to group the items I want to flatten to disk

Here is (part of) a Class API

The Read From Disk method delegates read/writing to another object (so I can change file format etc...)

In this example the Base File Class writes a config file (OpenG style) I have a reuseable VI from my own library:

That is a wrapper for the OpenG VIs to guarantee certain functionality

I can handle file versioning to (not shown here).

In this example this creates a nice config type (settings) file.

The cool thing about OpenG is that this supports inheritance - as long as the variable names are unique up the chain - I can write to the same section.

I have found that MGI VIs do not allow this as they write the section as a string as opposed to key-value pairs (config API).

I have to say using the native XML is much easier tho.

----

Jim have you done any prototyping of your idea?