01-30-2009 05:15 PM
Sorry for all the post spam, but apparently the "Match Regular Expression" VI also has case-insensitive matching. Doing some benchmarking tests, apparently this VI is a less expensive operation (about 50% less) than using the "Search and Replace String" VI. Although either one is pretty much negligible with the number of excluded folders we can expect to get, nonetheless I feel we should use the more efficient one. Also, "Match Regular Expression" makes more sense when you look at the code.
Interesting enough, I just noticed another icon bug (at least in 8.2). When you are looking at the "Match Regular Expression" VI in your functions pallet, the Icon shows PCRE on the top which leads me to think it does Perl Compatible Regular Expressions, however when you actually drop the icon on the block diagram, its completely different! The block diagram icon is much more like the "Match Pattern" VI, except this one actually has the correct pattern "b+", so that's good. Does this inconsistancy persist in 8.6?
Attached is the updated "Recursive File List_Exclude" VI
02-02-2009 10:47 AM
Siege X,
you're right, the icon is different when the VI is placed down on the block diagram in 8.2. However, this inconsistency is fixed in 8.5 and 8.6.
02-02-2009 11:36 AM
Darren,
this
is a strong argument for using strings. On the other hand I'm coming from old DOS times and never used more than '?' and '*'. Will Windows Explorer understand any patterns? I didn't have tried.
02-02-2009 02:42 PM - edited 02-02-2009 02:42 PM
waldemar.hersacher wrote:On the other hand I'm coming from old DOS times and never used more than '?' and '*'. Will Windows Explorer understand any patterns? I didn't have tried.
Hi waldemar,
As far as I know, Windows only supports the '*' and '?' wildcards (also known as globs.) Your statement is the exact reason why I created the Glob_to_Regex.vi and put that inline with the "Match Regular Expression" VI to enable pattern matching for the exclude list. This conversion VI will make it so that '*' and '?' will work as you would expect. Without the glob --> regex conversion, the '*' and '?' bring on a whole new meaning and would produce results you would not expect.
Misha,
Thanks for the update, glad to see this was fixed.