Post - Forum - Plus/4 World



	Home Search Games Tapes Covers Cheats Maps Software New Stuff Hall Of Fame HVTC Game Endings Solutions Remakes Publications Magazines Effects Top List Members Groups Features Plus/4 Encyclopedia Hardware Tools Options Forum Home Search Games Tapes Covers Cheats Maps Software New Stuff Hall Of Fame HVTC Game Endings Solutions Remakes Publications Magazines Effects Top List Members Groups Features Plus/4 Encyclopedia Hardware Tools Options Forum	Login

Forum Help

Post Your Message

Previous Messages

Posted By

JamesC
on 2007-05-08
07:59:07

Re: Oddness in INPUT#

I have come across this, years ago. It also occurs in INPUT (from keyboard).

10 INPUT A$, B$
20 PRINT A$, B$

Run this short program and enter ABC:DEF. The computer will prompt you for more. Enter GHI. The computer will print ABC GHI (forgetting DEF completely).

As it is possible to SAVE and reLOAD a BASIC program that has colons in the program lines, it is not a fault of the operating system itself. The fault lays within BASIC's INPUT routine.

This was discussed in a US Commodore magazine years ago, but I cannot locate it immediately. When I find it I will post it for you.

In the meantime, if you MUST have commas and colons in your datafiles.... substitute another character. One could use CHR$(133) as a replacement for a comma, CHR$(134) as a replacement for a colon.

Posted By

SVS
on 2007-05-08
02:52:06

Oddness in INPUT#

I recently discovered an undocumented behavior of INPUT#.
As you know this command gets from a file a string of characters between two CHR$(13). This string can be splitted in several variables if inside it there are commas.
For example:
"NAME,ADDRESS,TELEPHONE" can be read by INPUT#x,NA$,AD$,TE

The news (at least for me) is that the separator could be a colon ":" too (in addition to comma).
This fact makes impossible to read by INPUT# any string containing character ":".

Any comment?