#489 FMSLogo cannot find library routines when working directory is on different drive

[David Costanzo]

In FMSLogo 7.0.0, if you change the working directory to a different device (aka drive), then FMSLogo cannot find library routines (any command that's in the "logolib" directory).

The working directory can be changed explicitly (with CHDIR) or implicitly (by openening a file using the Windows file picker).

This was reported by serioadamo97 in this discussion.

Repro

Steps to Reproduce: (assumes you have an E: drive)
1) Install FMSLogo 7.0.0 to c:\Program Files\FMSLogo
2) Run FMSLogo
3) CHDIR "E:\
4) ICON "FMSLogo
5) CHDIR "C:\
6) ICON "FMSLogo

What Happens:
At 4), FMSLogo prints "I don't know how to ICON".
At 6) FMSLogo is minimized (iconified)

Expected Result:
At both 4) and 6) FMSLogo is minimized.

Details

The regression was introduced in [r4001], I changed the way FMSLogo determines which directory the "logolib" routines are stored in. The code used to use installation path that was determined at setup time, then fell back to ::GetModuleFileName(). To remove the remants of the Borland version and make the code work on GNU/Linux, I replaced it with this:

    // Figure out the path that contains fmslogo.exe, which we
    // assume also holds Logolib.
    const wxFileName fmslogoExecutable(wxStandardPaths::Get().GetExecutablePath());
    const wxString & fmslogoPath = fmslogoExecutable.GetPath(wxPATH_GET_SEPARATOR);

What's significant is that wxPATH_GET_VOLUME is not given. So the executable path won't start with the "C:" (or whatever) and the path is relative to the current device (drive). And when you try to run a logolib routine when your working directory is on a different drive, FMSLogo constructs the correct path to the logolib routine, but Windows uses the wrong drive, and so fail to find the file.

[David Costanzo]

Fixed in [r4321]. This fix will be included in FMSLogo 7.1.0.