Jump to content
IGNORED

Bloody comma's. OPEN and FILE TYPE issues.


Bones-69

Recommended Posts

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 by Bones-69
Link to comment
Share on other sites

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:

 

post-24932-0-99269600-1358151581_thumb.png

 

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?

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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!

Link to comment
Share on other sites

  • 3 weeks later...

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" ;)

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...