LabVIEW Developers Feature Brainstorming

[tst]

As I said earlier, I'm in favor of this, but it needs to consider that experienced users and beginners have different requirements.

In any case, I think this dialog should be more intelligent - It's probably more important to sort warnings by their severity then by number of occurences - warnings like "constant replaced..." (I assume that was what you meant) are lower priority and should probably not pollute this dialog. The others should have a clear and simple explanation of why they are important very easily accessible (quite possibly already visible). I mind less the magnitude of a change and more the actual effect it has.

I don't think it's a major problem if the details are displayed in a separate window, but it might be good if there would be an environment setting which would allow advanced users to get the details view immediately. An alternate implementation would be to have a summary view and a details view in the same window.

[crelf]

---

JLoftus wrote:

(1) Do you typically read this warning dialog in detail?  Do you scan over it looking for particular types of warnings?

---

It depends - I often know when it's coming (eg: I've explicitly moved something on disk, and I know that LabVIEW's going to relink to VIs in a location that it didn't expect them to be in) so I'll have a quick read through and cancel it out.  Other times it surprises me with warnings that I didn't expect, so I read it very very carefully

---

JLoftus wrote:

(2) Do you use the "Save to File..." button to export the warnings to a text file for later examination?  If so, do you use any automated tools to parse/filter these text files?

---

Very rarely - only when I'm surprised by something, and there's a lot of info to go through.  As someone else already said, it'd be great if the dialog wasn't modal, and I could work on code with it up - or at least have a look at code that it's flagged.

---

JLoftus wrote:

(3) Does this dialog ever appear at times when you really would rather it be suppressed?  Is it ever essential to suppress this dialog?

---

Never - that said, it'd be nice to have categroies of info rather than everything in a big text block, then I can quickly decide what's important and what's not.  Maybe like the LabVIEW Options dialog - categories on the left and descriptions with hotlinks to the VIs (or even the components of the VIs) on the right.

[Albert.Geven]

Hi

It seems like a good approach, especially that I can get to this warnings later.

How do you differentiate between warnings for loading and the normal warnings (like hidden terminal)

[JLoftus]

---

Albert Geven wrote:
Hi

It seems like a good approach, especially that I can get to this warnings later.

How do you differentiate between warnings for loading and the normal warnings (like hidden terminal)

---

Good question, Albert.  The distinction between "warnings for loading" and "normal warnings" is admittedly a bit fuzzy, and we don't have any official, consistent terminology to explain it.  Here's my attempt...

LabVIEW has two distinct classes of warnings: (a) load/save warnings and (b) code warnings.  Partly for "historical reasons", these two warning classes are reported in different ways (various different dialogs), but there are also fundamental differences in their nature that led to this situation.

(a) Load/save warnings inform you about actions that LabVIEW did automatically for you while loading or saving your files.  (Note that "load/save" encompasses loading via File>>Open, saving via Save For Previous, and the automatic load/save operations that take place during Mass Compile.)  Commonly, these automatic actions really were The Right Thing To Do (tm), but we let you know because sometimes LabVIEW had to make guesses on your behalf and only you can verify that they were correct.

(b) Code warnings inform you about existing problems in your code that aren't serious enough to break the VI, but may cause you grief later.  In these cases, LabVIEW didn't do anything to change your code (presumably you or some other author of your code made changes leading to the warning).  Leaving these problems as they are is almost never The Right Thing To Do (tm), but then they may be benign enough to ignore for now.

Now, note the difference in verb tense in those definitions -- load/save warnings tell you about actions that already happened in the past, while code warnings report something about the present state of your code.  It is arguable that load/save warnings also tell you something about the present by describing the past, but the difference is still there, and trying to present these different concepts clearly via the same UI mechanism is pretty tricky.

[johnsold]

I use the warnings primarily when upgrading old programs or when moving a program to a different platform. The summary dialog you mocked up a few days ago looks like a good start, along with the other readability suggestions.

Separating warnings about linkages to vi.lib from other linkages would probably be useful as these are either flags about platform or version differences and usually need to be examined carefully.

Lynn

[JLoftus]

Thanks, Lynn.

A follow up question:  when you mention "warnings about linkages to vi.lib", do you mean situations where subVIs move in/out of vi.lib or those times where subVIs are found at a new location within vi.lib?  For the latter case, LabVIEW has been suppressing warnings for things that move within vi.lib since at least LV 7.1.  Could you please be a little more specific about your use case?  What kind of transition where you taking a caller VI through that yielded a warning that included vi.lib paths?

Thanks,

-=James

[Albert.Geven]

Just an idea

How about warnings like: the loaded vi comes from a previous version (X.x.x) and needs to be saved for this version.
So not only when closing but also on opening a vi.

[altenbach]

Excellent idea Albert,

Whenever I open a VI posted here in the forum, the first thing I do is check the VI properties to see from what version it came from. This would eliminated that step.

[tst]

If you want something faster than that, how about writing a simple VI which will go into the tools menu and just return a popup with the version of the VI it's called from?

Alternatively, I'm not sure how Firefox \ IE 7 plugins work, but if you can call an arbitrary executable, you could write a small LV app which will call the Get VI Version method with command line arguments and embed it in the browser. Of course, loading the RTE just for that seems like overkill.

[lmtis]

I definitely would like to see a warning for opening a VI that was saved for a previous version.  We have test stations running VIs from various versions of LV, but most are 7.1.  I usually am good about checking that I start up the correct LV version before loading a VI, but sometimes in a rush... I sure wish there enabling such a warning was just a change in the ini file, because future implementations won't help those of us stuck with previous versions.