Darin's Weakly Nugget - 1/10/11

[rgvdh@rdf]

I sure wish I had known about this a few weeks ago, it would have saved me a couple of hours.

Among the other replies I see:

"Cool, I didn't know that VI was there."

and examples of extra work done by other folks who didn't know it was there.

So why aren't the non-pallette contents of vi.lib documented in such a way that people who might want to use them could find out they're there?

It sure would be nice if they showed up in the LabVIEW documentation listed in the same format as the pallette functions - just going through the whole library opening things up and looking at them isn't very efficient.

I understand why it's a bad idea to jsut put everything on the pallettes, but if these vis are worth shipping then they should be worth documenting somewhere.  A feature that users can't find might as well not exist.

[K1200LT_rider]

An optional listing or link for vi.lib would be nice when you open up Find Examples.  Also, maybe an additional link in the palettes could be added that opens up a listing of vi.lib categories and VI lists.  That would be nice.

[Ben]

The catalog is a ggod idea, yes for finding them fast but more imporatantly for finding issues with LV upgrades. All of the VI's in vi.lib that are NOT on the palette are subject to change from LV version to LV version.

Example:

In LV 7.1 you could use the sub-VI "Config Data Write To File.vi" to save a config file to disk without closing the file. I used this often to enusre I could remember a running total after a reboot following a crash.

That VI has been removed and any code that used that function now opens broke.

So the Catalog would let us find those issues soon after upgrades and not after we attempt to open the app.

Ben

[rgvdh@rdf]

"That VI has been removed and any code that used that function now opens broke."

Ouch!

If NI includes these things with the release, they really should support them.