jgcode

Really? I had a hunt as to aid the discussion. I could only find this in OPP from your LAVA CR files but I may have missed it? Your snippet obviously is missing your reuse subVIs - do you mind posting? Cheers -JG I also think the we should polymorphize the API here too for the Error Code input.' Should we support an array of Errors In too? This would mean a total of 4 VIs - most likely with the Error In array as a thin wrapper around the above mentioned VIs (no function changes). I have made this into an OpenG Review.

I checked in 2009 and 8.6.1 - with no luck too.

On the topic of B) I use the Min/Max primitive as Ton suggested: E.g. when converting a Start/End Index to Index/Length for arrays, I do the precheck and also output a pass result (if ever of interest). We could do something similar here however, I recommend we depreciate the original VI as this will cause a behavior change of the function. If we depreciate the VI, then IMO we should also do A) and make the inputs required for all new VIs.

FWIW, I have a similar reuse VI in my library (I think it was originally based on one from an NI course) Anyway, I would recommended clearing the error as opposed to using the constant (just in case there is anything NI handles under the hood in the future etc...) I never created an array version (as never have the need) - not saying one wouldn't be useful. Clear Specific Error.vi Code is in LabVIEW 2009.

FWIW, there's two conversion dots there.

What version of LabVIEW are you seeing this in?

Hi kiyuna I like to add the gif to a button with the 'on image' as the gif and the 'off image' as a png-still of the gif. Then I just set the button state programmatically. You could do the same but just use the visible property of the button to show/hide the gif. Cheers -JG

Good to hear you have sorted out your issue. As for the change you mentioned this actually occurred in LabVIEW 2009. I have not had any issues with the config API with respect to this. Given LabVIEW handles the change automatically and the OpenG Config VIs are based on that API (and package versions 4.x have been tested in LabVIEW 2009) it should be all sweet. Cheers -JG

Hi caleyjag I am confused as to whether you are using 2011 or 2010, anyways I have tested this package and it installs correctly in 2011: Have you rebooted LabVIEW after installing the package? This is required to refresh the menu (currently there is no way to do this programmatically etc...) Cheers -JG

You: Similar: Yes, I am a google master.

Personally, when I took the exam, I didn't find it difficult in knowing as to what NI were after - what I found difficult was comprehension of the requirements and implementing the solution within the time limit. After compiling notes, I used a top-down approach - I put together the messaging framework, then UI, then worked on creating modules (specifically API and data-structures), then connecting everything together. I then kept iterating through everything (either adding code or requirement covers) - rather than trying to implement an entire module in one go - because I knew I would be pushed for time (and of course I needed more time). IMO the CLA Prep Guide details pretty well what NI are after (page 9-10), if you can tick off those boxes, you should feel pretty confident in passing the exam.

All I can say is to invest (going with the stock market theme) in OpenG - if you are interested in becoming an OpenG Developer please PM me!

I vote to add an I32 VI (using Jim's code) and polymorphize the API. We can look at supporting more datatypes in the future when there are good enough reasons to do so.

Congrats. Well deserved! :beer:

Good suggestions Ton.

This review is now closed - thanks to Wouter for the original contribution and thanks everyone for their input. Significant contributions will appear in the copyright of the released version. Cheers!

The OpenG Board has decided to use on the following icon and connector pane: Additionally (as suggested in this thread) a Hexademical String output has been added to MD5 Message Digest. This could have been implemented in two ways: Depreciated old VI, create new VI and add additional output Convert to Polymorphic API The Polymorphic API was chosen as it allows for future support of additional outputs (if ever needed). Note: It will not break existing code. The Hexadecimal String is just a thin wrapper around the original VI: I will close this review in the next few days. Thanks for everyone's input!

I would do whatever makes it easy for reviewers to get to the code to contribute to this thread. E.g. post a zip containing everything for a one-click download (as opposed to 30+ clicks)

As I said in the other thread, I liked your implementation better. I wrote this code a while but only just posted it. At the time I was thinking it may be of interest for padding etc... Like I said above, I posted the VI to get a discussion going on functionality so things like these are not that important at this stage.

On the road, so don't have any examples with me however, the JKI Module presentation shows how you can 'fit' a UI onto another module and the old LabVIEW Advanced course showed two examples (Event Structure and Queues) for doing this - if you can get your hands on that book it is a good read. Cheers!

I have updated the LAVA requirements to include changes to the palette location and .bin3 location. These changes are to be inline with Compatible with LabVIEW (LabVIEW 2011) requirements.

OpenG used to support this functionality (by recreating all the NI palettes I believe?) This was something I posted to JKI last year as a feature for VIPM however, I understand it is a limitation of LabVIEW palettes. So, I am all for this Idea happening!!

Yes, it was not a big deal to implement the multi-character functionality (that is what I meant). I did it similar to this when I coded it, but I like the above better. This is the part that will generate some discussion on how to handle it. I have gone ahead and created a separate thread for a Chunking VI so please continue this discussion there (I also posted some code to get the above mentioned functionality). I am going to go ahead and close this review in a couple of days. OpenG will be using the original String To Character Array function (note the name change) as below:

I have started a new thread for the possibility of creating a Chunking VI or similar. Here is some code I wrote to get the conversation started. It may not be beautiful code, but I was just trying to create the functionality described in the cross thread (did I get it right?) I will turn this into an OpenG review if it gets enough interest. Attached is a String Implementation Chunking.vi Example - Chunking.vi Code is in LabVIEW 2009

Cut and paste. I am sure everyone who is interested in the discussion can click to the OpenG archive and read the OP. Keep that thread going by posting in this LAVA thread, no worries.