05-10-2010 06:42 PM
I learned a very handy tip from LAVA last week related to file dialogs. With the LabVIEW file dialog, you can provide a multi-line filter for file types, like this:
The syntax for accomplishing this is tricky, but doable:
Notice that you need to use the null character (\00) to separate the 'lines' of the pattern...that's why I'm showing the constant in '\' Codes Display. Also notice weird things like the unmatched parenthesis after the first pattern, the fact that the first pattern's name goes in the pattern label input instead of the pattern input, the fact that the patterns themselves must be duplicated, etc. etc. Seems like it wouldn't be too tough to have a wrapper VI that presents this ability more easily to the user (Norm came up with a good start in the original thread here, although it doesn't look like it supports multiple patterns per line). But until we have a nice wrapper, at least it's nice to know that this functionality is possible.
05-11-2010 01:22 AM - edited 05-11-2010 01:24 AM
There is a wrapper. I found it somewhere some time ago, but I don't remember where it was. Probably the author of the VI can comment.
It doesn't wrap the file dialog, but it creates the pattern and the pattern label to feed to it.
To use 2 or more patterns on the same line, separate them using a semicolon, e.g. '*.bmp;*.png;*.gif' (without the quotes).
LV 8.5.
Hope this helps,
Daniel
05-11-2010 03:10 AM
Hi Darren,
I also heard this "trick" two or three weeks ago, with a rather usual complaint: Why isn't it documented in the context help?
Could you create a CAR for either updating the context help or for creating an example VI that ships with LabVIEW?
05-11-2010 03:19 AM
GerdW wrote:
Could you create a CAR for either updating the context help or for creating an example VI that ships with LabVIEW?
I would rather vote for a polymorphic file dialog VI which supports arrays of pattern labels and patterns. I think the functionality wasn't implemented like this intentionally, it's more something related to the underlying OS functions (?).
I would like the option to remove the "All files (*.*)" option from the dialog... This could be in the CAR as well.
Daniel
05-11-2010 06:16 AM
Here's a little wrapper:
Ton
05-11-2010 08:10 AM
GerdW wrote:Could you create a CAR for either updating the context help or for creating an example VI that ships with LabVIEW?
I would rather vote for a polymorphic file dialog VI which supports arrays of pattern labels and patterns. I think the functionality wasn't implemented like this intentionally, it's more something related to the underlying OS functions (?).
I would like the option to remove the "All files (*.*)" option from the dialog... This could be in the CAR as well.
05-11-2010 08:17 AM
LabBEAN wrote:..
Nice wrapper, Daniel.
While they've got the CAR open, how about NOT raising an error when a user presses Cancel (there's already a Boolean output for that)?
Now there is a "If a tree falls in the forest..."
If no errors where encountered (nobody heard anyhting) when not opening a file (tree falling), should it return an error (make a sound)?
Ben
05-17-2010 01:29 AM
LabBEAN wrote:Nice wrapper, Daniel.
While they've got the CAR open, how about NOT raising an error when a user presses Cancel (there's already a Boolean output for that)?
I'm very much afraid that that is no option unless implemented as non-default option. Way to much code relies exactly on the cancel error being added to the error cluster, that such a change would not bring down the wrath of all long time wire workers onto NI.
05-17-2010 08:52 AM
I'm very much afraid that that is no option unless implemented as non-default option. Way to much code relies exactly on the cancel error being added to the error cluster, that such a change would not bring down the wrath of all long time wire workers onto NI.
If that's a concern, they can add a "raise error on cancel (T)" terminal. What's one more input on an Express VI? 😄
06-25-2010 11:48 AM - last edited on 06-28-2010 04:40 PM by Laura F.
I took some liberties with the VI posted by dan_u by simplifying and allowing the user to define multiple patterns per pattern label. See attached VI, snippet, and resultant dialogue window: