Null File Dialog Behavior in 2019 & Forward Compatible Run-time Issues

[Hooovahh]

LabVIEW 2019 appears to have changed a behavior in the File Dialog primitive.  Passing a null into this function was a way to get multi select to work in Windows.  Attached is a zip with 2 VIs in it, run File Select Multiple Patterns in 2017 or 2018 and you'll see a browse dialog come up that allows for picking from different patterns like this:

 

Run this in 2019 and you get an error:

If this was an intended change to fix a bug, then how can we do multi select patterns in LabVIEW?

This brings up a different issue I've mentioned before.  You see LabVIEW now has the capability to perform some kind of forward compatible run-time engine.  This means built binaries can be opened in newer versions of the RTE.  This is awesome and a PPL built in LabVIEW 2018 can be used in LabVIEW 2019 without having to rebuild it.  But when this feature was announced NI also said that EXEs would run in the newer runtime engine.  And I was told when an EXE is ran it will run in the newest version of the RTE that is compatible.  I argued that it should always run in the run-time engine it was made for if it is available, and to only use a newer RTE if the default one wasn't available when running EXEs.  My reason was that I might make an EXE for some system and the EXE might change behavior if it is ran in a newer RTE that is installed.  Someone might install a new version of the RTE and not know that that makes my EXE behave differently which is a issue for production systems.

Well this is exactly what happened to me...well not in a production environment but testing.  I made an EXE in 2018, then updated the RTE to try out 2019.  But now when I run my EXE it runs in 2019 which has this different behavior of the File Express Dialog.  Now in my program if I go to File >> Open instead of getting the multi select pattern I get an error and needed to either uninstall 2019, or rebuild the application in 2019 removing the multi select feature.

[RavensFan]

Interesting.  And potentially disturbing, particularly for anyone who is mandated to do thorough testing of code whenever a change is made.  In this case, testing would be needed of your EXE even though you didn't change it.

If you happened to uninstall the 2019 RT engine, will the EXE start working properly again?  It sounds like it would from your description.

[Darin.K]

Since the \x00 separator is the syntax for the old WinAPI GetOpenFileName(), perhaps that function is no longer being used.  A likely replacement is the newer .NET functions like OpenFileDialog.  If this is the case, perhaps the pipe '|' will now work as a separator for multiple types.

If not, since you are relying on a Windows-only hack, perhaps it would not be a problem to go overtly Windows-only and use the .NET dialogs directly.

[MichaelBalzer]

---

@Hooovahh wrote:

But when this feature was announced NI also said that EXEs would run in the newer runtime engine.  And I was told when an EXE is ran it will run in the newest version of the RTE that is compatible.  I argued that it should always run in the run-time engine it was made for if it is available, and to only use a newer RTE if the default one wasn't available when running EXEs.

---

Did NI offer a reason why the newer RTE was preferred when running the EXE?

[MichaelBalzer]

Also this known issue (528963) may be related, and has been addressed in 2019.

[Hooovahh]

@RavensFan - I did not uninstall 2019 RTE and see if it went back to using 2018 I assumed it would but the tester was having other issues with crashing RT EXEs in 2019 that weren't crashing in 2018 (I'll try to make a post on that later).  I ended up wiping the machine of all NI stuff and started over, so I can't test seeing what it would do if I uninstalled 2019.

@Darin.K - I figured this was sort of a hack and since this is Windows only I don't mind calling into a .Net to do this kind of thing in the future.  I see there is an example here on using the OpenFileDialog .Net I'm guessing I can wrap these calls into a VI if I need to do multi pattern selection.

@MichaelBalzer - While I don't remember if NI specifically said this I assumed their reasoning was that the newer RTE should always be better (not always my opinion) so why wouldn't you want to just use the newest one available?  It will have bug fixes not in the older versions.  Of course there actually could be a technical limitation.  Like if I try to open a PPL it shouldn't revert to the version it was built in, it should run in whatever version is calling it.  No idea personally. 

I figured this was a known issue and actually have seen crashes in 2018 that probably could have been attributed to using this feature so I am glad it is being fixed.  I am less glad that I no longer have the ability to select from multiple patterns without calling into .Net myself.

[Darin.K]

I have played around with calling the WinAPI function directly and I am unable to replicate the crashes despite various malformed filter strings involving NULLs.  Since there is some transformation (All Files is always there, sometimes 'Custom Pattern' is displayed, and the pattern is displayed for you in the label), I believe the real issue lies in how this part of the code handles a NULL leading off the Match Pattern.  Excluding all NULLs is an effective, if not drastic measure to handle this.

Kind of a gray area here, this was certainly not a documented feature, but it wasn't documented not to do it either.  It was semi-officially sanctioned here:

http://forums.ni.com/ni/board/message?board.id=170&message.id=497502&query.id=3663527#M497502

Perhaps you could argue that they broke existing functionality, they claim to hate doing that.  You do not have to revert to having LV crash, they just need to find the underlying cause of the crash in the code that generates the filter string.

Or you could go to the idea exchange and request a legit way to have multiple patterns.  

[User002]

We just ran into this with a customer who has LabVIEW 2017 and 2019 installed on his machine. The executable and installer builds worked fine for our development environments (LabVIEW 2017), but whenever he tried to open one of the file dialogs, the program crashed and locked up. We were clueless what was happening because there was no error message.

We sent him some simple file dialog vi's to try running (with/without multi select file patterns, using the file dialog primitive/the file dialog express vi), to see whether simple dialog boxes would work. He could run all four in LabVIEW 2017, but in 2019 the two with multi select options crashed and threw the "LabVIEW (Hex 0x692) The string contains an unexpected null character." exception. I say exception, not error, because it crashed the vi without any opportunity to handle the error.

The change to the file dialog is annoying, but understandable if there's a better way to get multi select and prohibiting null characters fixes something, except that it crashed the file dialog and hung the application instead of failing gracefully and passing an error.

The scarier issue was that the executable and installer that we built and tested using 2017 tried to use the 2019 runtime engine without notice and crashed without any usable feedback.

For anyone else running into similar issues, I did some digging, and followed https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019TuFSAU&l=en-US to https://www.ni.com/en/support/documentation/compatibility/17/labview-and-labview-run-time-engine-com... to http://zone.ni.com/reference/en-XX/help/371361P-01/lvupgrade/labview_features/ 

Apparently, there's an option (enabled by default) on the advanced tab of the executable build specification properties that says, "Allow future versions of the LabVIEW Runtime to run this application." I want to try the build with that option unchecked on a machine with both 2017 and 2019 installed, and see whether it uses the 2017 runtime engine.

[User002]

---

@MichaelBalzer wrote:

Also this known issue (528963) may be related, and has been addressed in 2019.

---

Apparently, changing the crash to say "LabVIEW: (Hex 0x692) The string contains an unexpected null character..." instead of "Exception: Noncontinuable exception..." counts as fixing it.