#382 WINDOWFILEEDIT behaves strangely/crashes when it can't make file

[David Costanzo]

WINDOWFILEEDIT has strange behavior if no file by the given name exists and FMSLogo does not have permission to create the file. The same behavior exists if you give it a directory name.

Steps to Reproduce:
1) Start FMSLogo as a non-admin
2) WINDOWFILEEDIT "c:\\filedoesnotexist.none []

What Happens:
FMSLogo displays a warning as a message box, then opens the editor with the name "Untitled". When you try to save the file, it says that you are saving it to the workspace. You cannot close the editor unless you don't save the changes.

Expected Result:
WINDOWFILEEDIT reports and error and does not open the editor. The error could be reported by throwing an error or by a message box.

[David Costanzo]

When I ported FMSLogo to use wxWidgets, I introduced a severe regression in the code path that previously exhibited the weird behavior. In the OWL version, in TFileWindow::Read fopen() returned NULL, and it displayed the message box. The failure code was largely ignored (hence the weird behavior).

In the wxWidgets version, which became the only version as of FMSLogo 7.0.0, the fclose() was called on the file handle, even if fopen() returned NULL (hence the crash). This can be reproduced as easily with an illegal filename like

WINDOWFILEEDIT "|\\| []

or

WINDOWFILEEDIT "|X&Y;\\Z| []

[David Costanzo]

I have fixed the crash by only calling fclose() if fopen() returns non-NULL. I fixed the strange show-error-but-still-open-editor behavior by propagaing an error code. The error code is translated into a file system error by the Logo engine. So now the behavior is

WINDOWFILEEDIT "c:\\filedoesnotexist.none []
File system error: Could not launch the editor

I also made it so that the screensaver throws this error if ever the editor is invoked, either by EDIT or WINDOWFILEEDIT (before, it would fail silently without opening the editor).

All of these change were committed as [r4780]. They will be available in FMSLogo 7.5.0.

[David Costanzo]

As the comment says, I have already fixed this in FMSLogo 7.5.0 but must have forgotten to close it.

Note that the original steps to reproduce the problem don't throw an error on Windows 10 because Windows 10 virtualizes the location where it writes (and so the file is successfully written to, even if it's a different file).

C:\Users\david\AppData\Local\VirtualStore\filedoesnotexist.none