Darren's Weekly Nugget 05/10/2010

[JackDunaway]

I have notified the moderator to remove the download from my previous post - there is a fundamental error in using the "Array to Spreadsheet String" primitive. You see, that primitive inserts an EOL control character at the end of the string, which throws off the regular expression for pattern matching.

Anyway, here you can see I've "rolled my own" function to delimit an array of strings that does not "graciously" include the spurious EOL.

[Neil.Pate]

%num$ in string formatting?

AWESOME!

funny thing is it is first token described in the help for string formatting and I have never seen it before 🙂

[id]

I seemed to find a case which still does not work properly which may interest you.  Somewhere below the 4th selection filter, the list got corrupted.  Any ideas?

[Honkey Bear]

I am running 2009 so I can't open your vi.  Perhaps you already solved your problem but here is something I discovered.  The string going into the "format" input must be less than 256 characters. Anything over 255 characters and the list is corrupted.

[fabric]

I've been using this trick for years and it works beautifully!

HOWEVER, I noticed today that it is not working in LV2023Q1 (Win10 x64)...

Here are some sample files:

When I specify multiple patterns:

• Only the first pattern is rendered in the File Dialog's drop down list

• The dialog does NOT actually match any files (unless "All files" is selected)

Even if I only specify a single pattern (with the exotic format), the dialog fails to match any files:

Note that the above syntax works perfectly well with LV2020 on the same machine.

If anyone knows of any workarounds I'd love to hear about them! 

[rolfk]

The workaround is to use .Net functions or wrap the Windows API function yourself.

Another option is to use your own VI based dialog but that will of course be a major usability issue as gour dialog will not look like the default platform dialog (which tends to look different between various Windows versions too.

I guess that functionality disappeared because the LabVIEW developers headed the Microsoft recommendation to replace the use of GetOpenFileName and GetSafeFileName with the Common Item Dialog. The old functionality worked by grace of passing the unsanitized string from the Pattern parameter to the aforementioned two APIs. This is considered a major security vulnerability by todays standards.

there are already several solutions here and on Lava, implementing either .Net or LabVIEW native variants for this.

[wiebe@CARYA]

---

@rolfk wrote:

The workaround is to use .Net functions or wrap the Windows API function yourself.

---

.NET makes browse dialogs easy.

This browses for folders ( with a dialog different than the LV dialog).

That comment is key though!

[Darren]

---

@fabric wrote:

HOWEVER, I noticed today that it is not working in LV2023Q1 (Win10 x64)...

---

This was in fact broken in LabVIEW 2023 Q1, but it has been fixed in LabVIEW 2023 Q3 and later.

[Frozen]

---

wiebe@CARYA wrote:

---

@rolfk wrote:

The workaround is to use .Net functions or wrap the Windows API function yourself.

---

.NET makes browse dialogs easy.

This browses for folders ( with a dialog different than the LV dialog).

---

Another file dialog solution can be found here.

[Hooovahh]

I'm glad this bug came and went.  But this is one of those situations that I point to, when advocating not using the setting which allows for newer runtime engines to be used in a built application. I had a built application and made an installer that included a runtime for that EXE.  Then the system was updated and a newer runtime engine was installed.  Suddenly my application started using this new runtime engine, which broke the multi select dialog we are talking about here.  I needed to then make a new build of my application with that setting turned off to force it to use the one runtime engine that didn't exhibit the bug.

I'm glad this setting can be turned off, but I can't know what bugs future runtime engines will add.  I like the flexibility of allowing other runtime engines to be used in my application without needing to make a new binary, but it is too much of a risk that something will break.