Why does this not work?

[qbasicking]

OPEN "test.tst" FOR BINARY AS #1
c = 14
FOR a = 1 TO 20
PUT #1, a, c
NEXT

and then when I do this

OPEN "test.tst" FOR BINARY AS #1
FOR a = 1 TO 20
GET #1, a, c
PRINT c
NEXT

I get a string of all zeros except for the last two (3.69349E+19 and 14)

 

[Nyaj2k1]

Try this:

'I like random access files more then binary.

OPEN "test.tst" FOR RANDOM ACCESS WRITE AS #1 LEN = 255
c$ = "14"
FOR a = 1 TO 20
PUT #1, a, c$
NEXT
CLOSE

OPEN "test.tst" FOR RANDOM ACCESS READ AS #1 LEN = 255
FOR a = 1 TO 20
GET #1, a, c$
PRINT LTRIM$(RTRIM$(c$))
NEXT
CLOSE

 

[Nyaj2k1]

I guess that still does not answer your question... I don't quite know why the BINARY file does that.

 

[agual]

Just erase the a's from the GET and PUT routines. The second variable says to GET and PUT the number of bytes to read. If you leave it blank, they will read-write just the size of the third variable
so
GET #1,,c$
and
PUT #1,,c$

If the GET test is in a separate program you should also pre-dimension C$ as two bytes (p.e. b$=" &quot or it will read nothing.

(RTFM!)
Antoni

http://www.geocities.com/antonigual/index.html

 

[Alt255]

Integers are two bytes long... so this should work...
[tt]
OPEN "test.tst" FOR BINARY AS #1
c% = 14
FOR a = 1 TO 20 STEP 2
   PUT #1, a, c%
NEXT

OPEN "test.tst" FOR BINARY AS #1
FOR a = 1 TO 20 STEP 2
   GET #1, a, c%
   PRINT c%
NEXT
[/tt]
Sorry I couldn't test it for you. I'm on a Macintosh at the moment.

 

[agual]

I just read QB help.
The second parameter for GET and PUT is the record number,
not the number of bytes to read.
For a file opened as BINARY the record length is 1 byte, so the a parameter should be increased by 2 on each iteration,
as ALT255 said.

To make it easier, if you omit the second parameter, GET /PUT reads exactly the number of bytes fitting ind the variable in the 3rd parameter and advances the pointer exactly by this amount of bytes. So my solution works also. Antoni

http://www.geocities.com/antonigual/index.html

 

[qbasicking]

Okay I forgot that two bytes long.

I don't like using opening files for RANDOM because it is so bloody slow and the files are so big.

 

[qbasicking]

Wait a minute! Neither one of your solutions worked. I tried them both. I don't understand this.

 

[trollacious]

Try:

OPEN "test.tst" FOR BINARY AS #1
c% = 0
FOR a = 1 TO 20
PUT #1, , c%
c%=c% + 1
NEXT

CLOSE #1

OPEN "test.tst" FOR BINARY AS #1
FOR a = 1 TO 20
GET #1, , c%
PRINT c%
NEXT
CLOSE #1

This will let the file pointer progress automatically. Since it's generally best to read data from a file into memory, work with it, then reopen the file and write what you want, this should fit most normal situations using file access. An old habit of mine is to keep files open as short a time as possible.

 

[Nyaj2k1]

I hate RANDOM access files because to do anything useful with it you are looking at a severely inefficient and inflexible file.

The only reason it looks like it is used at all is because stupid programmers think it's somehow easer to use then the more efficient file type of Binary.

I don't exclude myself in that statement, because three days ago I suggested using Random files, but only because I had never even experimented with Binary files. Why? Perceived complexity that never existed.

I still like standard text based file I/O for most applications that I use it for, but Binary will be my new tool in attacking slow Random type disk accessing in my older programs.

 

[qbasicking]

nevermind. I just typed copied it to qb wrong