I have done additional tests with GetFullPathNameW but I have not found any differences in the result.
Using a relative path (with \)opens the same file as using the corresponding absolute path.
The only difference is that GetFullPathNameW also converts all / to \.
IMHO, if you use Windows to open a relative path, you should adhere to the Windows naming conventions,
which means you should use \.
In addition, and even more importantly, by retrying the absolute path in OpenExternal but not in RunExternal, we get an ugly
difference in the behavior of both. Note that expanding to absolute paths in RunExternal is not easily possible because many commands have arguments,
not just a plain file name.
I would therefore prefer to stay with the simple form for now. At least until there is a reproducible problem
with the current strategy. (If you want to experiment with absolute file name expansion,
add the following lines before the line with "IF res = 0 THEN" into HostDialog.OpenExternal:
Code: Select all
IF (res = 0) & (error = WinApi.ERROR_FILE_NOT_FOUND) THEN (* retry with absolute path *)
res2 := WinApi.GetFullPathNameW(fileName, LEN(fileName2), fileName2, NIL); (* also converts / to \ *)
IF fileName2 # fileName THEN
sxinfo.lpFile := fileName2;
res := WinApi.ShellExecuteExW(sxinfo);
error := WinApi.GetLastError();
IF res = 1 THEN RETURN 0
ELSIF (res = 0) & (error = WinApi.ERROR_FILE_NOT_FOUND) THEN
fileName := fileName2 (* use absolute path in error msg *)
END
END
END;
)
The latest version has been updated significantly with respect to error handling.
I found out (by accident) that it is possible to get textual error messages for ALL Windows error codes returned by GetLastError().
This means that we don't need to extend the Host Strings resources to include a subset of error messages.
In order to use the error reporting, however, it was necessary to switch from using ShellExecute to ShellExecuteEx,
which does basically the same but delivers standard Windows error codes.
As it turned out, there was also a trivial bug in the definition of WinApi.FormatMessageW, which I fixed.
See diffs at
https://redmine.blackboxframework.org/p ... 63cce82514.
For testing use
http://blackboxframework.org/unstable/i ... c1.991.zip.
- Josef