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
Files.dir.This never fails
- DGDanforth
- Posts: 1061
- Joined: Tue Sep 17, 2013 1:16 am
- Location: Palo Alto, California, USA
- Contact:
-
- Posts: 1700
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Russia
Re: Files.dir.This never fails
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.
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.
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: Files.dir.This never fails
I agree with Ivan.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.
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
- DGDanforth
- Posts: 1061
- Joined: Tue Sep 17, 2013 1:16 am
- Location: Palo Alto, California, USA
- Contact:
Re: Files.dir.This never fails
Fine.Josef Templ wrote:I agree with Ivan.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.
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
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")