jgcode

I (personally) think this VI is a good OpenG candidate. Therefore I have OpenG'd the code and included a Test VI. Please discuss. I was unable to optimise the code further - can anyone make it faster? To Character Array.vi TEST - To Character Array.vi Code is in LabVIEW 2009.

Ok, I built the exe and it ran fine on my PC. Do you want to upload an exe compiled on your PC too, and I will run it here just to check?

Aside from VI Shots (as you already mentioned) there is a HAL example here that might help (pdf + code).

Have you tried other PCs? - What is the result? I have seen weirder stuff happen before. Also, you could upload your code, so other devs can quickly build the spec and see if they get an error.

I have taken this on board however, I checked with other similarly named LabVIEW primitives in e.g. Comparison palette - there is no is/an prefixing (hence I renamed the VIs). Also added a noted about Hexadecimal String as I will be updating the MD5 Digest with a Hexadecimal String output as previously requested to compliment this VI. Thoughts? MD5 Hash.vi TEST - MD5 Hash.vi Code is in LabVIEW 2009.

What benefits are you looking for by storing the string data in binary files?

Yer, at the moment I can only see negative connotations with introducing such a change. I really think it is on the user to define unique names when using this API. FWIW, section names can be specified using the API, so even if two clusters that the same name you can override this (that's how I like to do it personally).

I concur! If anyone is interested here is Darren's suggestion implemented. (It doesn't change functionality) but I am also one to try/learn new things/VIs Thanks again D! Check OpenG Library for Recursive VIs.vi Code is in LabVIEW 2009

Please keep this thread on topic. But, by all means, create a new thread to discuss new ideas (other than moving to vi.lib)!! In this case, this thread already exists here: Migration of OpenG Projects to LabVIEW Project Libraries? Cheers -JG

I am going to go ahead and close this topic as it already exists here: Migration of OpenG Projects to LabVIEW Project Libraries?

I quickly wrote a tool using Traverse Refs (thanks D!) to scan the OpenG Library to discover CallBeRef node and if Re-entrant. Here are the results: Please comment if you think tool may have missed any VIs etc... I can add these to DB to be fixed based on outcomes of this performance benefits discussion. Check OpenG Library for Recursive VIs.vi Code in LabVIEW 2009.

FWIW, when I have to do this I like to use the following convention: If the Label is red (BD and FP), its dependent so don't go changing it. I think I copied it off someone after seeing it on LAVA (thanks to Olivier I think )

Likewise (to everyone who's posted too) I changed everything else you mentioned but to be consistent I use the variable names so MD5? instead of Is an MD5? Is an MD5.vi TEST - Is an MD5.vi Code is in LabVIEW 2009.

Well, lets get this party started then...

The OpenG Board will make the final decision on changes related to the direction of OpenG, but by all means, everyone's opinions, ideas and feedback are very much welcome and respected - so please keep them coming.

I would think most definitely (this is just my personal opinion at the moment).

Great points, thanks for the feedback. If the user linked to the VIs correctly this will not be an issue (i.e. will not break any code). There is a OpenG VI that defines the OpenG directory. Therefore, for this move it is noted that: The OpenG Library VI will need to be updated Underlying sub folder structure will not change This should be ok? Given that the user chooses to upgrade to the newer version, they will need to except that a recompile will be required. LabVIEW should handle this automatically (as reported earlier from my testing). However, we could even provide a VI to be downloaded that is an OpenG VI Tree containing all OpenG VIs so the user could open it first, then open their project code. The VI Tree will have the OpenG VIs in memory and LabVIEW will link to these on opening the user's code. (then they just do a save). Yes, we have been using that feature since switching to VIPM and will continue to do so. As mentioned above, this would also be a major release e.g. v5). I (personally) cannot think of a reason users would have both installed? So I am thinking upgrades would be preferable for this.

You can track this bug here: ID: 3409853

What are people's thoughts on this (does it cover all use cases)? Is an MD5.vi TEST - Is an MD5.vi Code in LabVIEW 2009

Now that you bought it up... This has been on my radar as it sure would make distributing OpenG (and my own) Array code easier. I checked and the idea exists on the IE, so I would really love to see Provide a Better Way to Implement a Polymorphic VI voted up enough to get enough visibility. I like what AQ has posted and would love to see it in 2012. What I really want to do is run a campaign for it like AQ and Darren did for Create SubVI From Selection. Now, I just need to find some high profile devs to help promote it and make it happen...

I would like to see a tool/exe like this developed.

Doesn't having identically named values in a cluster cause you issues when developing? Anyways, IMHO identical items should not be used. One problem I can see with this is that INI files are designed so that order of the sections/keys in the file does not matter (hence the name-value paradigm). E.g. If in the future, the first item was removed from your cluster, then on reading an existing config file, the API would now return the first item's value when reading the original second item, and therefore introduce a bug into your code.

Yes I do sometimes, but I always consider the lifetime of the code/application and what the trade-offs are (e.g. doing it now vs later etc...).

So, to summarize, the majority of users would support this move (and that we would do it atomically all in one release avialable at the same time)?

Hi Guys These are the latest I have saved on my HDD oglib_openg_object-1.0beta4-1.ogp ogrsc_active_obj_tmpl-1.0beta1-1.ogp ogrsc_pure_abstract_ref_class_tmpl-1.0beta1-1.ogp ogrsc_ref_obj_tmpl-1.0beta1-1.ogp ogrsc_val_obj_tmpl-1.0beta2-1.ogp