disk.to/from.string

[Pat Bruening]

Thought the PowerBASIC forum could use these 2 complementary
procedures. One captures a string and sends it to disk; the other
retrieves it from disk.

SUB DISK.TO.STRING (byval FILE.NAME$,S$) PUBLIC
X&=FILE.SIZE&(FILE.NAME$)
S$=SPACE$(X&-8) 'BSAVEd files are 8 bytes longer
DEF SEG=STRSEG(S$)
BLOAD FILE.NAME$,STRPTR(S$)
DEF SEG
END SUB
'---------------------------
SUB DISK.FROM.STRING(byval FILE.NAME$,S$) PUBLIC
DEF SEG=STRSEG(S$)
BSAVE FILE.NAME$,STRPTR(S$),LEN(S$)
DEF SEG
END SUB
'---------------------------
FUNCTION FILE.SIZE&(byval FILE.NAME$) PUBLIC
X$=DIR$(FILE.NAME$)
REG 1,&H2F00
CALL INTERUPT &H21
DTASEG=REG(9)
DTAOFF=REG(2)
DEF SEG=DTASEG
FILE.SIZE&=PEEKL(DTAOFF+26)
DEF SEG
END FUNCTION

[This message has been edited by Pat Bruening (edited June 19, 2000).]

[Alan Earnshaw]

Pat,

You might want to post code like this to the Source Code forum. It seems like it might find a wider audience there...

Alan

------------------
Alan C. Earnshaw
Information Management Systems, Inc.
http://www.infoms.com

[Sebastian Groeneveld]

Pat,

You've made me curious... What makes these routines so special? And why would I use them instead of:

OPEN Filename$ FOR BINARY AS #1
PUT$ #1, S$
CLOSE #1

and:

OPEN Filename$ FOR BINARY AS #1
GET$ #1, LOF(1), S$
CLOSE #1

------------------
Sebastian Groeneveld
mailto:[email protected][email protected]</A>

[Pat Bruening]

Sebastian,

Your routine may be smaller, but it requires an extra DOS channel
My routine does not use a DOS-channel other than whatDOS already uses. Hence, it is quick. Further, you do not have to be aware of what DOS-channels are available. Your solution implies that
DOS-channel #1 is not currently being used for another purpose.
Hence there is some overhead to determine if it is free to use.


Thanks for the comment.

Pat

[This message has been edited by Pat Bruening (edited June 21, 2000).]

[Matthias Kuhn]

Hi Pat,

interresting idea to save string$ on Harddisk.

Is it possible to save UDT Strings too(Type...end Type) ?

Is it possible to make a hole file system with quicker access as
in binary mode ?

Do you have any problems with memory chrashes as written in the
PB User´s Guide ?

Thanks for answere !

Matthias Kuhn



------------------

[Tom Hanlin]

I don't think I've ever heard the term "DOS channel", so I'm not sure what point is being made. If you're talking about file handles, however, there's no advantage to either technique. BLOAD and BSAVE have to allocate a file handle in just the same way that OPEN does.

It's not necessary to use a specific file number in PowerBASIC. The FREEFILE function returns an available file number. Note that a BASIC file number is not the same as a DOS file handle, although every file number is associated with a file handle if the file (or device) is open...

------------------
Tom Hanlin
PowerBASIC Staff

[Pat Bruening]

Tom,

Thanks for responding. I do not know what to call what DOS needs
to open a file, or screen, or disk. I call it a DOS channel.
Altho it is true that BLOAD/BSAVE require a handle, the programmer does not have to know what it is. I assume that BSAVE/BLOAD uses one of the 5 system channels the manual talks about. Sebastian's routine is much simplier than mine. Thanks Sebastian. But if you don't want to "OPEN" a file, you can use
BSAVE/BLOAD.

Pat

[Lance Edmonds]

I assume that BSAVE/BLOAD uses one of the 5 system channels the manual talks about.

Sorry, but this is not correct. BSAVE uses one of the available file handles to operate. Unless the number of file handles has been increased, BSAVE will fail with an error 67 if there are already 15 file handles in use. Try it for yourself!

It is true that the O/S "reserved" 5 handles - it uses them for the standard devices (CONS, KYBD, PRN, NUL, etc)



------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Pat Bruening]

Matthias Kuhn,

Thanks for you inquiry about BSAVE and BINARY use with UDT.
I am able to use a pointer to a UDT and transfer its data to a
string and then save the string. But I am not yet able to reverse the process; that is, change a string into a UDT.

Can a whole file system by used with strings? Yes. Since BINARY
mode can save a string, a string can contain many records, with
each field delimited by a character (like a comma) and each record by a CR/LF pair. Items can be put into the string in
ASCII order, retrieved in order, etc. A real file management
system. The down side is the maximum length is 32K. If PBCC is
used, the limit is 2 gigs - enough for the average size file.

I have found NO CRASHES in using such a file.

Pat

[Lance Edmonds]

Exchanging a UDT and a string:

DIM MyUDT as MyUDTType
A$ = MyUDT       ' copy the UDT structure data into a string
LSET MyUDT = A$  ' copy the string into a UDT structure

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Matthias Kuhn]

Pat Bruening,

thanks for answere, but I´ve only PB 3.5 so it is too less
memory for my main files. But for read´in index-files or pre-
setting files or files to change information between different
programs it is very useable.

Regards

Matthias Kuhn

------------------

[Pat Bruening]

Lance,

Thanks for the info on saving/retrieving a UDT to/from a string.

Pat

------------------

[Pat Bruening]

Lance,

Thanks for the string to UDT and back again. Can you tell me if
it is possible to save the TYPE...END TYPE structure to disk not the data but the structure? Thanks
Pat

[Lance Edmonds]

During compilation, PowerBASIC uses the structure definition to generate the compiled code - the UDT structure definition is not required at runtime, so it is not "included" in the code. The only way to save a UDT structure definition to disk is for you to write a routine to do it - I usually define by UDT structures in separate INC files, so if necessary I can read one at runtime and parse the structure.

However, as a UDT structure is not required at runtime by the compile code, saving the structure is of limited use in "conventional" application design.

If you need to be able to dynamically work with record "structures" in PB/DOS, then maybe you should look at using flex-strings instead - they can be dynamically mapped at runtime.

Note that flex-strings are native only to PB/DOS - there is no direct equivalent in our Window's compiler range. UDT's and Unions are available in all PowerBASIC compilers. If you plan to port your code to Windows eventually, then choose your approach to data structures carefully - the decision can affect the amount of effort involved in porting code.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Tom Hanlin]

For "DOS channel", substitute "file handle". BSAVE and BLOAD allocate file handles in exactly the same way as the OPEN statement.

In reference to system handles, every DOS program has five handles that are already allocated. These handles are:

0 - standard input (stdin, or CON in DOS)
1 - standard output (stdout, or CON in DOS)
2 - standard error output (stderr)
3 - standard auxiliary I/O (stdaux, or AUX or COM1 in DOS)
4 - standard printer output (stdprn, or PRN or LPT1 in DOS)

You can gain more file handles for your program by closing any unwanted system handles.

asm mov ah,&H3E ; close file handle
asm mov bx,HANDLE ; handle number goes here
asm int &H21 ; do it!


------------------
Tom Hanlin
PowerBASIC Staff

[Mike Luther]

Tom hit it right ...

If you will simply set up a small integer array such as FL%(#)
and use it, you can keep track of them yourself. Execute FREEFILE
and return the next available handle to the storage array. Then
use element FL%(#) for all references to the files in your program.
When you close a file, reset that element to zero as well.

That way, you can forget about what actual handle is being used
for any file. If an element is non-zero, the handle is in use.

If you run over the cap of 20, you can set more in the your open
statements ... Typically, in DOS-VDM operations in OS/2 I use
a FILES=50 statement as protection. In a fairly complex program
suite here, I've never had to expand the given program to more
than 20 file open at one time, although I have a number of my
executables that do use the full 20 all at one time, as well as
up to four Btrieve open files and some shell operations as well
in the same executeable. I've never gon to TSR's so I have
no idea what they add that 'DOS' can't see, but they must!


[This message has been edited by Mike Luther (edited June 26, 2000).]