Leaderboard

Your tale reminds me of a similar story: I had a very senior co-worker at a company I worked at years ago who was bitten by a bug in an OpenG VI once, and his solution was to proclaim that no one at the company be permitted to use open source reuse libraries. Most of the other developers were relatively junior, so they all took his lead. A couple of years later I started working at that company, someone asked for my help on something, and I told them there was an OpenG VI that did exactly what they wanted. He told me the story, so I went and talked to the guy that was originally bitten by the bug and he told me his story of woe. I asked him why he didn't fix the bug and upload it back to OpenG? Or maybe even just post a quick couple of lines to the forum to let everyone else know about it? His reply was that his job isn't to help others outside the company to profit. The code you get from OpenG may not be perfect. The code you get in vi.lib may not be perfect. The code you write isn't perfect. don't tell my boss, but the code I write isn't perfect. But that's part of why we're all here: to accept challenges and make things better. Now, if you can't tolerate any code that doesn't do exactly what you want it to, then you need to start coding in assembly. Otherwise, accept that what you get from OpenG, NI, etc is best effort from the developers, and (and this is the bottom line here) is created to try to help you. If it doesn't, drop them a line and let them know why, but don't write it off because it wasn't a perfect fit. Better yet, get involved so that others can benefit from the code you write. I'm not saying that OpenG shouldn't be criticized: in fact, the OpenG architects and developers actively encourage it - it's only through constructive criticism that it will grow and better serve the people it was created for: you!

Anything that can be undone should not have a dialog, period. Get rid of it altogether. No checkboxes or ini settings.

This. I absolutely agree. Also any dialog boxes that must be shown should never be yes/no/ok/cancel/etc. Make a proper UI with large buttons that clearly explain what action will happen if you click on the button. Windows 7 did a lot of this, and though they went a little overboard in my opinion it was definitely a step in the right direction.

Hi! I recently started working at NI and I'm interested in what dialog/error messages LabVIEW throws that the users find confusing/ambiguous/useless. A good example is a case where LabVIEW (not a user-built VI) opens a dialog box with "Press OK to [perform some action] or Cancel to [perform some other action]" with an OK/Cancel button. The point here is that OK and Cancel buttons themselves don't describe what is actually going to happen, and that makes them sort of useless. I would like to find examples of these in LabVIEW. Feel free to reply back, preferably with a VI or project I can load and reproduce the ambiguous dialog or error. Some more background: I just started working at NI and with LabVIEW just shy of a month ago. As such, I'm slowly learning more and more about LabVIEW, but I don't have the insight that many of you, the end users, have. Hence, here I am! I'm hoping I can learn a lot from the LabVIEW "veterans" here.

You're probably thinking of a tab in an ActiveX or .NET container. Why are you using a tab at all? Just use a single subpanel and use the "tabs" (a ring or a list box works well) to control which VI is currently displayed in the subpanel. Then you can add as many items as you want at run-time.

See attached image. You have to click on the dot next to the post title.

Better yet, categorize this dialog box and other newbie-friendly warnings as "tips" and give us the option to disable all of them at once.

Yes, that seems correct, and IMHO is very logical to mainstreaming LabVIEW. On a side note, it provides a great market place, allowing developers to make money from selling tools etc... As a side note, from reading their forums, posts and blogs etc.. JKI are able to help with this process. If there is any logical reason(s) such as the above, that would make sense to move the libraries (or do anything else to them) then OpenG want to hear it! The only other use case I can think of, off the top of my head is when - I have wanted to do this in during a source distribution build: I wanted to exclude NI vi.lib but not my library VIs (which was under vi.lib at the time), but I couldn't so having it in user.lib lets me etc...

Thanks for the kind words Jim, it was a pleasure Hi Greg, this (LabVIEW ZIP Library) is a known issue, but we have now documented it.

The Call Library Node does not directly support to pass complex datatypes, resp. it does using the Adapt to Type but this passes an array as a LabVIEW handle which is absolutely not the same as a C array pointer. So you will have to trick this a bit. First configure the parameter as an array of bytes (8-bit integers). Then allocate a byte array of enough length with the Initiliaze Array function and pass this to the Call Library Node. The returned byte array can then be typecasted to a LabVIEW array of clusters and should after that be routed through a Swap Bytes and Swap Words node when you are on Windows. Alternately in LabVIEW 8.2 an newer you can use the Unflatten from String function (convert the byte array first to a string) where you set the endianess input to little endian, or even better native, host order, and the "data includes array or string size? (T)" set to false. With this you replace the Typecast and Swap Bytes and Swap Words. You will have to create a cluster that is compatible. For the char name[32] and char pad[3] you can NOT use a LabVIEW string but must instead insert another cluster of 32 resp. 3 8-bit integers. The get the length of the entire byte array typecast this entire cluster to a string and get the string length and multiply it with the number of struct elements you want to pass to the DLL function and then pass this value to the length input of the Initiliaze Array node. Rolf Kalbermatter