Jim Kring

1) Download and install VIPM here:

http://jki.net/vipm

2) click on this link:

<a href="vipm://openg.org_lib_openg_toolkit">vipm://openg.org_lib_openg_toolkit</a>

3) Then click "install"

4) After this completes, you'll have an "OpenG" category in your Functions palette with all the good stuff

That did the trick - thanks!

Great! I'm glad that will work for you

Unfortunately, the float format string is global for all floats. You can't choose a different value for each one, individually. You might get good mileage using auto-formatting like this: %#_16g -- it will use 16 significant digits, hide trailing zeros, etc.

So moving from MacOS to Linux fixed the issue?

Hehe... no. It's just that the bug was seriously hampering me on Linux, so I fixed it there and overwrote the installed VI (which is generally a bad thing to do). Then, in order to get a screenshot of the original, buggy VI, I needed to go to a different LabVIEW installation and the one on my Mac was handy

But in all seriousness, I completely understand how this affects users. It's good to note that this would happen in the basic, standard use case of just opening a opening a config file, writing a value, and closing, all with the public Config file functions in the palette. You've narrowed down the root problem in Save Config (a non-palette VI), but users would see this bug in Close Config (a palette VI).

Yes, that's exactly right, Chris.

Thanks,

-Jim

I think I found a bug in "<LabVIEW>\vi.lib\Utility\config.llb\Save Config File.vi" (the Configuration File VIs)...

When saving a config (INI) file, the original file is "replaced" (deleted and then a new file created in its place, as opposed to simply opening and flushing the contents of the original file).

The problem with this are as follows:

1) A user might have write permission on the file, but might not have permission to create new files. So, attempting to replace the file will cause a file permission error, even when the user has write permission on the file itself.

2) The new file might have different permissions than the original file. When the original file is deleted, all its permissions/ownership settings are lost. The replacement file will have default permissions based on the user creating the new replacement file.

Here are some screenshots of the buggy version and the fix for this issue:

And, here's the fixed VI:

Save Config File -- FIXED.vi

OK, I can see that it is for now an irrelevance for OpenG. My personal experience of LabVIEW 2010 & this separation feature is only to the good I must say.

In answer to this part, hopefully developers of packages in general ARE keeping their source code in some sort of SCC, and it is from this they build thier packages. So if they are working in LabVIEW 2010 they will get the benefit for themselves in maintaining that code. It provides no benefit as you say to the end user of the package.

Danny

I can see a couple possible benefits to end users:

1) No modifications to installed VIs allows easier validation -- if the installed VIs are never modified (at the installed location), then it's easy to validate that no inadvertent changes have occurred.

2) No modifications to installed VIs when deploying to multiple targets -- when the same VI is used in multiple targets (RT, FPGA, My Computer), then it will show unsaved changes and need to be recompiled each time it is run on the target in question. Keeping the compiled code separate will avoid this.

Any others?

While upgrading the OpenG LabVIEW Data Tools to LabVIEW 2009, we noticed that the unit test for Remove Typedefs from Variant was't passing.

Currently, the (buggy in LabVIEW 2009) code looks like this:

The comment references a bug in LabVIEW 6.1 related to Variant to Flattened String. Basically, the old (LabVIEW 6.0) method we used was to call Variant to Flattened String and then to Flattened String To Variant as shown here:

In 6.1, we changed the Flatten/Unflatten method with a call to Variant to Data and this did the trick (removed Type Defs from the variant). However, it appears that somewhere along the way, this stopped working (perhaps this "feature" was really a "bug" that got fixed by NI).

Now, can anyone think of a reason that we wouldn't want to go back to using Variant to Flattened String and Flattened String To Variant? Can anyone think of a better way to remove typdefs from a variant?

The Vis for converting between common and specific paths are not working in Mac OS X (App.TargetOS = "Carbon"). The frame that handles the Mac path conversion should also include "Carbon", as shown below:

"ZLIB Specific Path to Common Path.vi"

"ZLIB Common Path to Specific Path.vi"

Congrat's! John

For anyone interested...here is what I came up with, a variation of the ZLIB Delete vi which uses the Move Raw vi to transfer each file in the archive to a temp archive without having

to decompress and re-compress, very clever! Instead of deletion by omission, I simply rename the identified file. It still seems like there should be a way to do this directly within the original archive, but this will do for now.

This seems like a good solution. There might be some low-level way to modify the name of a file in a zip archive, but I don't know off hand.

Actually a better fix is to apply the correct logic in ZLIB Store File.vi itself, since in there is already code to detect if the entry is a file or directory. I will look into this as soon as I have finished setting up the essential tools on my new machine, since the old machine is kind of dieing, I rather don't want to use it for any work anymore.

That sounds like a good way to do it. Thanks for your work on this.

Crelf has proposed a minor update to the OpenG Comment in the OpenG String library.

I'm friendly to this change. However, I'd probably keep the text short, like /* YOUR_COMMENT_HERE */

There's a bug in "ZLIB Compress Directory" where it fails if a password is specified.

If you try it, it will result in a file permission error:

I fixed this error by not passing in a password to the "ZLIB Store" for directories, and only passing in the password for files (as shown below).

Here's the fixed VI.

ZLIB Compress Directory__ogtk -- BUGFIX.vi

Thanks for your support, guys. I'm looking forward to seeing what's in store for OpenG, too. There are exciting things in the works...

It looks like you need to adjust the keystone

Update: I just tested this in LabVIEW 2010 SP1 and it seems to be fixed The CAR Number (252210) is also in the list of LabVIEW 2010 Service Pack 1 Bug Fixes. Thanks NI!

I've noticed that some packages like the LVOOP Assistant depend on this Icon Editor API package. However, it seems that they don't provide a link to the package (but, it would be nice if they did). It took me a while to find this page

Keep up the great work!

One thing to remember is that Mercurial itself is licensed as GPLv2+, this license includes the Mercurial logo. If you are just calling the Mercurial command line interface you don't need to use the GPLv2+ license.

Ton

<opening a can of worms>So, does that mean if you use the Mercuial logo in a VI icon that the VI must be licensed under GPLv2+?</opening a can of worms>

I've been using Mercurial with TortoiseHG and Kiln (Kiln is free for two developers) since this last summer and I love it! It sometimes surprises me how easy some activities are compared to how I used to have to do them with VSS / Perforce / Surround SCM / DesignSync (don't ask about that one... ).

...snip...

Thanks for the great summary of your results and experiences with Mercurial/TortoiseHG/Kiln!

-Jim

Jim, I'm aware of this and was reading is prior to posting.

It's the main reason I want some VIs of this project (reusable components) to be licensed under BSD.

Felix

Great! Regarding the main application, I guess you'll need to choose a license that best suites your business (and community) goals.

Cheers,

-Jim

Felix: Here's some good reading on the reasoning behind the choice to release the OpenG libraries under the BSD license.

Sign up for NIWeek 2011 and network with these guys

I want to know what's so funny on that computer screen

(PS - Ya, I'm just jealous)

I had the same weird thing with the dialog disappearing - my solution was to throw together this little VI to recursively set the property on all VIs in a folder - it's a little quick and dirty but does the trick

Shaun,

You're the man! I'm starting to play around with "Separate Compiled Code From Source" and was about to create a tool just like your (and now I don't have to).

To me, it seems odd that the "Mark VIs" dialog does include this "folder on disk" functionality -- rarely do my LabVIEW project files include every VI from my project folder on disk.

Thanks!

@dannyt FYI: you can subscribe an RSS feed of a twitter user's tweets without actually signing up for a twitter account yourself.