On 11 Jan 2005 at 18:19, Marcel Kilgus wrote:

> Default could also be DATAD$ or whatever.

that would defeat the wholme exercice. Why not have the user set the default?

 (...)

> 
> Hm, the meaning of a Trap #3 depends on a specific device you've
> opened, not a good choice IMO. But if you do use a #1 or #2 trap there
> will be no way to maintain QDOS compatibility (not that I'm
> particularly bothered by that, just mentioning it).

See my other email (starting a job from a trap?)
 (...)
> As I said, I think if we/you are going ahead with this, I think it
> should probably be a "current directory" functionality with functions
> like "up one directory" and "change directory to x (absolute and
> relative).
> Or perhaps both? On other systems Applications get 2 things: a current
> directory and the complete name of their EXE file.

OK, this bears thinking about.

(...)
> 
> Don't see why (and as said, a "current directory" would have to be
> present during the whole process anyway). We're talking about a few
> bytes here.

Ok, I hadn't envisaged the current dir as such.
 
> Also something one should probably think about: should functions like
> OPEN automatically use the "current directory" if no drive name is
> given? Currently most commands default to DATAD$.
>
I HATE the open commands that append the data/prog dir when I don't want 
them!

But I'm probably alone with that opinion.

> Or, speaking completely into the blue, what about a meta device like
> DEV_ that uses dynamic paths instead of static ones? Something like
> "home_MyDataFile"?

Too ambitious?
Wolfgang
----------------------------------------
www.scp-paulet-lenerz.com

_______________________________________________
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Reply via email to