Page 2 of 3
Re: Files.dir.This never fails
Posted: Wed Dec 14, 2016 12:33 pm
by Robert
Josef Templ wrote:This() is not intended to check for the existence of a directory.
Ok. But there are two things that encourage this false idea:
1 - The existence of the return code
res = 2 meaning "location not found"
2 - Many examples where the calling code appears to use "
loc = NIL" to test for the existence of a directory.
So, I suggest, we want three things:
1 - Clarify the Docu regarding
This. Explain when
res = 2 does, and does not, occur.
2 - Correct the calling code that misuses the
loc = NIL test.
3 - Add a function to test for a directories' existence. (The code I posted earlier shows how to do this with a 1 line Windows call.)
Code: Select all
MODULE CasketShlwapiDll ["shlwapi.dll"];
IMPORT SYSTEM, Win := WinApi;
PROCEDURE PathIsDirectoryW* (path : Win.PtrWSTR) : Win.BOOL;
END CasketShlwapiDll.
MODULE CasketShlwapiUtils;
IMPORT Shlwapi := CasketShlwapiDll, WinApi;
PROCEDURE IsDirectory* (path : ARRAY OF CHAR) : BOOLEAN;
BEGIN
RETURN Shlwapi.PathIsDirectoryW (path) # WinApi.FALSE
END IsDirectory;
END CasketShlwapiUtils.
Re: Files.dir.This never fails
Posted: Wed Dec 14, 2016 12:58 pm
by Josef Templ
Robert wrote:
Ok. But there are two things that encourage this false idea:
1 - The existence of the return code res = 2 meaning "location not found"
2 - Many examples where the calling code appears to use "loc = NIL" to test for the existence of a directory.
So, I suggest, we want three things:
1 - Clarify the Docu regarding This. Explain when res = 2 does, and does not, occur.
2 - Correct the calling code that misuses the loc = NIL test.
3 - Add a function to test for a directories' existence. (The code I posted earlier shows how to do this with a 1 line Windows call.)
No question that the situation is confusing.
But note that the error code 2 is not listed as a result of This().
There is a global list of error codes for the purpose of
mapping error codes to error messages, for example.
This does not mean that all error codes can occur at all places
where error codes are set.
The docu already lists the error codes that can result from
a particular operation, with maybe a few inaccuracies, I don't know.
- Josef
Re: Files.dir.This never fails
Posted: Thu Dec 15, 2016 9:41 am
by DGDanforth
The current functions for obtaining a locator are inconsistent between the two ways.
Let's clean this up.
(1) If a path is invalid the dir.This and loc.This should return NIL.
There is, however, an alternative.
(2) If the path does not exist it can create the directory and return the locator to it.
A one line windows call does the creation "res := WinApi.CreateDirectoryW(path, NIL);"
That creates all necessary sub directories. Example: If only "C:\" exists then
path = "C:\A\B\C\D\E" will have all those sub directories created.
Now doing that is a "side effect" which is strongly frowned upon. However, it does
satisfy the condition of always (unless the syntax of path is not a valid path form)
returning a non NIL locator.
Something needs to change and it is more than the documentation.
-Doug
Re: Files.dir.This never fails
Posted: Thu Dec 15, 2016 1:05 pm
by Ivan Denisov
Doug, directories created only if you register your File.
Also all this discussion is related to HostFiles. There are many possible realizations of Files.
If you want to make Windows directories manipulations better use WinApi. Files.Locator does not designed for this issue and, IMHO, it should not be redesigned.
Re: Files.dir.This never fails
Posted: Thu Dec 15, 2016 2:30 pm
by Josef Templ
Ivan Denisov wrote:Doug, directories created only if you register your File.
Also all this discussion is related to HostFiles. There are many possible realizations of Files.
If you want to make Windows directories manipulations better use WinApi. Files.Locator does not designed for this issue and, IMHO, it should not be redesigned.
I agree with Ivan.
This should be a bug fix issue, where the bugs are the inconsistency in the docu
and the bugs in testing the error codes. This can be fixed easily.
It should not be mixed up with introducing new features that
introduce incompatibilities with existing code or inefficiencies.
- Josef
Re: Files.dir.This never fails
Posted: Fri Dec 16, 2016 12:01 am
by DGDanforth
Josef Templ wrote:Ivan Denisov wrote:Doug, directories created only if you register your File.
Also all this discussion is related to HostFiles. There are many possible realizations of Files.
If you want to make Windows directories manipulations better use WinApi. Files.Locator does not designed for this issue and, IMHO, it should not be redesigned.
I agree with Ivan.
This should be a bug fix issue, where the bugs are the inconsistency in the docu
and the bugs in testing the error codes. This can be fixed easily.
It should not be mixed up with introducing new features that
introduce incompatibilities with existing code or inefficiencies.
- Josef
Fine.
Let's do as you suggest.
===
In my opinion the Oberon Microsystems design of creating a Locator is bad.
The semantics of "path to locator" should reflect the validity of path, directly,
by returning NIL when path is invalid.
What is our purpose? Is it to maintain the status quo at all costs or is it to
produce a better BlackBox environment?
-Doug
(p.s. you don't need to register a "path" whereas you do for a "file")