Ah, seems I am wrong. If e.g. win1_mach_ ist not found, I think, TK2
searches for win1_win1_mach_.
I use the following (extract from S_Edit ;-)):
SV_BASE is my keyword to return the base of the system variables:
12480 DEFine FuNction file_test(name$)
12490 LOCal default
12495 REMark Read the length of DATAD$
12500 default=PEEK_W(PEEK_L(SV_BASE+176))
12506 REMark set the length of DATAD$ to zero, the string itself remains
12510 POKE_W PEEK_L(SV_BASE+176),0
12520 ferr=FOP_IN(#5,name$)
12530 CLOSE#5
12535 REMark restore the length of DATAD$
12540 POKE_W PEEK_L(SV_BASE+176),default
12550 RETurn ferr
12560 END DEFine file_test
I set the data_default to "", so I really know, if the file exists or not.
Cheers...Ralf
----- Original Message -----
From: "Ralf Reköndt" <ralf.rekoe...@t-online.de>
To: <ql-us...@q-v-d.com>
Sent: Saturday, April 21, 2012 6:50 PM
Subject: Re: [Ql-Users] Quanta Library Guide
The FOP_xxx functions (and all similar TK2 things) always tried to use the
Data default next, if a direct call was unsuccessful.
So, if I try to check Win1_test_, and it does not exist, Win1_ is checked
next (if Data default), which is very likely to be successful.
So you can't be sure, that the correct device was opened. That's why it is
better, to set the Data default to "", then try, then set it back to where
it was before.
----- Original Message -----
From: "Bob Spelten" <b...@upcmail.nl>
To: <ql-us...@q-v-d.com>
Sent: Saturday, April 21, 2012 5:43 PM
Subject: Re: [Ql-Users] Quanta Library Guide
Op Sat, 21 Apr 2012 16:10:15 +0200 schreef Ralf Reköndt
<ralf.rekoe...@t-online.de>:
Hmm, but the TK2 Manual states about OPEN_DIR, so, apart from Level 2, it
should be possible. But what kind of directory, if not Level 2? Perhaps
just the root one.
Section 10 Open and Close
The standard QL channel OPEN commands are redefined by Toolkit II
to use the data directory. In addition, Toolkit II provides a set
of functions for opening files either using a specified channel
number (as in the standard QL commands), or they will find and
return a vacant channel number. The functions also allow filing
system errors to be intercepted and processed by SuperBASIC
programs.
Commands
OPEN #channel, name open a file for read/write
OPEN_IN #channel, name open a file for input only
OPEN_NEW #channel, name open a new file
OPEN_OVER #channel, name open a new file, if it
exists it is overwritten
OPEN_DIR #channel, name open a directory
CLOSE #channels close channels
The problem is related to the FTEST command trying to open a file rather
than a directory to verify its existance. In SMSQ/E a directory can be
opened as a file, but in QDOS I don't think it can. The correct way to
check for the validity of devices and directories would be to attempt to
open a directory, not a file (TRAP#2 with D0=1 and D3=4 rather than
D3=1).
The Function FOP_DIR can be used but is not very reliable.
I did a quick QDOS test on my demo Q-emuLator where win1_ is a W$ folder,
win2_ is a QL floppy.
chn= FOP_DIR (win1_): PRINT FTYP(#chn): produced 255.
chn= FOP_DIR (win1_mach_): PRINT FTYP (#chn): also produced 255 while
mach_ is part of a filename and not a directory!
Even chn FOP_DIR ("win1_ma"): PRINT FTYP (#chn): returned as valid
directory.
This was not the case with win2_, there a FTYP returned zero for
everything.
But chn= FOP_DIR (usb1): opened a channel to win2_, PRINT FTYP(#chn):
returned zero and DIR usb1_ gave the name of the floppy and the sector
count.
So this is here not a good level 1 test to see if a device or directory
actually exists.
Minerva gave the same results.
Mind you, even under QPC2 I can happily FOP_OVER (a_file) to my win8_,
which is a QXL.WIN on the cdrom!
Bob
--
The BSJR QL software site at: http://members.upc.nl/b.spelten/ql/
_______________________________________________
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
_______________________________________________
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
_______________________________________________
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
