Jim Kring

I want to give a huge kudos to Jon Green (jgcode) for spearheading the OpenG 4.0 Release. Jon did an incredible amount of work, while I mostly tried to keep out of his way. This is an exciting release, since a majority of the work was spent trying to make it easier for OpenG Developers to make improvements to (and release new) packages, in the future. Great work, Jon!

Hey Doug, Here's the scoop. When OpenG Builder is run for the first time, it "mass compiles" itself and does a little extra trick where it creates its own copy of some VI's that it calls, which are found inside vi.lib (it does this, so that it's VI hierarchy doesn't share any VIs with the end user's LabVIEW projects that OpenG Builder is building into EXEs or Source Distributions). So, you probably looked inside ogb_NI.llb and found nothing, because you hadn't run OpenG Builder yet (and it hadn't copied this file for itself, yet), and then you looked again after this had occurred and then you found the file. Something to note: You should never directly call VIs that you find under the "<LabVIEW>\resource" unless you have a really good reason to do so, and really know what you're doing (since there are a ton of caveats -- if I sound emphatic, it's because it's an issue that's caused me some pain). Also, these VIs called by OpenG Builder are not intended to be called by end users -- those all get put under vi.lib or user.lib. These resource VIs are internal stuff that are called by OpenG Builder. And, if they disappear, please don't be surprised (since these are basically private functions, and might someday even be made private using LVLIBs so that users don't accidentally call them). That said, if you see a VI you like, copy it into your project and use it Hopefully, that clears things up and leaves you with fewer questions than you started with Cheers, -Jim

Hey Seth, Check out this page for some info about getting VIPM working with a proxy: how-do-i-configure-vipm-to-use-a-proxy-server Regarding the "Temporary Filename__ogtk.vi", this is located in the OpenG File library. You can get the latest version of this library, here: http://sourceforge.net/projects/opengtoolkit/files/lib_file/ Or, you can get the sources, here: https://opengtoolkit.svn.sourceforge.net/svnroot/opengtoolkit/trunk/file/source/library/ -Jim

Hi Yair, Ya, objects really aren't supported well at this time. I'd love for the OpenG team to consider adding support, and I'm sure there are some fun things we'd all learn in the process. In the mean-time, you might consider flattening the object and writing that to file or have a VI that converts the object to some data cluster that can be persisted. -Jim

Hey Ryan, I use VI Snippets for posting examples on the web. I also like to send them to my colleagues via skype (send file), occasionally, when I'm trying explain how to do something. I do not ever save my snippets -- I don't consider them to be reusable code. -Jim

I'm not sure if I agree with changing the default behavior of "replace". I can see how this would change the behavior of some people's applications who already rely on the fact that "replace" also replaces all of the permissions/ownership settings of a file.

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

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.

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

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

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.

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