Bloody comma's. OPEN and FILE TYPE issues.

[Bones-69]

I have come up with a real issue that has me stumped. If I can't find a solution, I think I can still make things work - but I will be forced to avoid some features I wanted to implement in what could otherwise be a pretty handy little application (aimed at the XB enthusiast who is using the XB compiler).

 

Here is an example which illustrates my issue;

 

100 CALL CLEAR
110 OPEN #1:"DSK1.FTEST",RELATIVE,DISPLAY ,UPDATE,FIXED 255
120 A$="Hello,World"
130 PRINT ">A$ IS;" :: PRINT " "&A$ :: PRINT
140 A$="1000 DATA "&CHR$(34)&A$&CHR$(34):: PRINT ">A$ CHANGED TO; ":" "&A$ :: PRINT
150 PRINT ">SAVING A$ TO "&CHR$(34)&"DSK1.FTEST"&CHR$(34)&" AT RECORD 1" :: PRINT #1,REC 1:A$ :: PRINT
160 PRINT ">READING RECORD 1 BACK FROM DISC AND ASSIGNING VALUE TO B$."
170 INPUT #1,REC 1:B$ :: PRINT
180 PRINT ">LENGTH OF A$="&STR$(LEN(A$));". A$ IS;" :: PRINT " "&A$ :: PRINT
190 PRINT ">LENGTH OF B$="&STR$(LEN(B$))&". B$ IS;" :: PRINT " "&B$ :: PRINT
200 END

 

I can get the correct answer by changing line 110 to;

110 OPEN #1:"DSK1.FTEST",RELATIVE,INTERNAL ,UPDATE,FIXED 255

* If replacing line 110 with above, remember to first delete "DSK1.FTEST" or you will get an I/O error due to the change in file-type.

 

However, for my particular project I can not use INTERNAL as the file-type. I am 100% stuck on needing to use DISPLAY as the file-type.

 

The program I am creating will write a set of records which when viewed is in the form of a XB Line Numbered Program. The idea is that these records (program lines), can then be viewed with Ti99Dir and copied/pasted back into any XB program which is intended for XB Compiling or general XB use.

 

Using the DISPLAY file-type still allows this to be possible (thank goodness), as the written records remain in the correct format and can be properly copied/pasted into Classic99 as intended(1000 "DATA Hello,World"), but the program I am writing also needs to access and manipulate these same records before it completes - this is where commas are triggering some major problems when I try to read the information back within my own program. I was able to fool things somewhat by adding additional quotation marks but then this effects the format of the records I am writing which makes it impossible to then paste back to Classic99 (pasted line numbers are getting the old * UNMATCHED QUOTES error and of course the syntax is horrible anyway).

 

I have been over and over the file documentation and from what I can tell the TI is doing exactly what it is supposed to - the comma is splitting the file record when using the INPUT file command. The one thing I am very thankful for is that when viewing the record it is correct. In the above example Record 1 correctly lists 1000 DATA "Hello,World" - As this is the data I want to Copy/Paste (the whole intention of my program), then ultimately I can still make my program work.

 

The single fix I have is replacing line 170 with;

170 INPUT #1,REC 1:B$,C$ :: B$=B$&","&C$

-But this is not a suitable fix because although I now get the correct answer, I need to know about the comma before it is encountered and even if I could teach my program to learn about future commas (which would be easy enough), it would then throw my entire file structure and records into a nightmare - Especially if the string I need to work on resembles something like; 1000 DATA ",,,,,g,,,,,d,,,,#" (which is possible)

 

Any ideas? I need a way to write DISPLAY type files and not have the comma mess things up when I try to read the information back and manipulate the data, and at the same time I can't have quote marks in places they don't belong as it messes up the syntax and makes copying/pasting into Classic99 impossible.

 

I think I am asking the impossible with my problem but I am tired and have been hitting a brick wall all day with this issue. A simple solution I haven't thought about might be staring me in the face....?.

 

For what it is worth I am writing a Screen Capture/Optimised Char Writer program which will take Magellan output (or any displayed 24*32 screen) and turn everything into an optimised format that can then be copied/pasted into a XB program. Creating these files (which are actually little pastable programs), allows a work around for getting this "optimised screen format" back into a XB program which can not access disc files. i.e. - Programs intended for the XB Compiler. This concept may also be part of a larger application I have been toying with.

 

If I can overcome this current problem I am having I am then about 80% finished and should be able to release the program in a few days for testing.

Edited January 14, 2013 by Bones-69

[Willsy]

Have a look at LINPUT

 

I changed your program, as follows:

 

100 CALL CLEAR
110 OPEN #1:"DSK1.FTEST",RELATIVE,DISPLAY ,UPDATE,FIXED 250
120 A$="Hello,World"
130 PRINT ">A$ IS;" :: PRINT " "&A$ :: PRINT
140 A$="1000 DATA "&CHR$(34)&A$&CHR$(34):: PRINT ">A$ CHANGED TO; ":" "&A$ :: PRINT
150 PRINT ">SAVING A$ TO "&CHR$(34)&"DSK1.FTEST"&CHR$(34)&" AT RECORD 1" :: PRINT #1,REC 1:A$ :: PRINT
160 PRINT ">READING RECORD 1 BACK FROM DISC AND ASSIGNING VALUE TO B$."
170 LINPUT #1,REC 1:B$ :: PRINT
180 PRINT ">LENGTH OF A$="&STR$(LEN(A$));". A$ IS;" :: PRINT " "&A$ :: PRINT
190 PRINT ">LENGTH OF B$="&STR$(LEN(B$))&". B$ IS;" :: PRINT " "&B$ :: PRINT
200 END

 

(note: I reduced the record length to 250 to avoid "string truncated" warnings)

And I get the following output:

 

 

So, LINPUT correctly pulls in the string from the file, including comma's etc.

 

However, each string will be <record length> characters long, because it is a fixed length file. Do you really need an updateable record?

[Bones-69]

Linput.....LINPUT!

 

I spent all yesterday going through the Users Reference Guide (I always use this because I find the file functions are very well described here), without even thinking about XB commands. Linput, for whatever reason, is one of those commands I either forgot about or just never discovered. After your post I pulled out the XB manual and started reading and yep - Linput was the magic bullet for my problem. Everything is now working exactly as I had hoped. THANKS WILLSY!

 

Re the fixed length files, at this stage I do need to access the files randomly so not too concerned about this option at the moment. Once all the testing etc is over I may look closer at fine tuning areas like this. Right now I just want to get my program completed and confirm my idea works OK.

[Willsy]

He he! I have a semi-photographic memory( it doesn't always work!) but I can remember( or rather, see) the image of linput on the page. I think I read it in the xb manual in 1988. However I find it impossible to remember to pick up a pint of milk on the way home!

[CantStopClicking]

He he! I have a semi-photographic memory( it doesn't always work!) but I can remember( or rather, see) the image of linput on the page. I think I read it in the xb manual in 1988. However I find it impossible to remember to pick up a pint of milk on the way home!

 

Funny how that works, huh? I can remember IP addresses easily but a phone number or a persons name, forget it. LINPUT #1,"PICK UP MILK, ON WAY HOME"