INPUT# and line feeds

[5against4]

Hi, probably a very basic question but i can't find a simple reference/solution in the Help files.

i'm using a plain text file as a data source for a program, with each piece of data on a new line. My problem is that each time INPUT# grabs something the first character of the string is a line feed (ASCII character 10). i notice that this doesn't happen when reading from data files that the program has itself created (where each piece of data is also on a new line), but only files i've manually created.

Can anyone advise on the solution to this? Obviously i could just tell the program to ignore the first character in each string but that's a workaround not a solution. And i'd be interested to know why this doesn't happen with files the program has created itself.

Many thanks in advance!

[hellomike]

Hi,

What you experience and/or need might be documented here:

http://www.bbcbasic.co.uk/wiki/doku.php ... xt_20files

Hope this helps.

Mike

[guest]

Hi, probably a very basic question but i can't find a simple reference/solution in the Help files.

Yes, very basic. It seems you didn't check the Wiki because you would have found this. The Wiki should be one of the first places you look.

And i'd be interested to know why this doesn't happen with files the program has created itself.

PRINT# and INPUT# write and read data in a private internal format, their purpose is to transfer data between BBC BASIC programs (or between one run of a program and the next), not for interchanging data between BBC BASIC and another application. In Acorn versions of BBC BASIC the format they use is so obscure it's effectively impossible to use them for that anyway, which is a good thing. Unfortunately, and I will always regret making such a stupid mistake, I used a slightly more conventional internal format in BBC BASIC for Z80 which is neither standard enough to be used for interchange nor non-standard enough to make that impractical.

This idiotic decision, which I've had to live with ever since in the interests of compatibility, has led to the kind of confusion you encountered. Now all I can do is implore people not to use PRINT# and INPUT# for data interchange but to use BPUT#, BGET# and GET$# instead. But that's shutting the stable door after the horse has bolted. I wish I could go back to 1982 and tell my younger self not to be so foolish.

[5against4]

Many thanks both, much appreciated. For some reason i always forget there's a Wiki - but i won't in future.

[guest]

For some reason i always forget there's a Wiki - but i won't in future.

In both BB4W and BBCSDL there's a link in the Help menu, indeed the Help menu contains links to all the main sources of information (the main manual, the beginners' tutorial, the wiki, the website, the discussion group and this forum - even one to email me!). So if you make the Help menu the 'go to' place for answers you will be reminded.

[5against4]

In both BB4W and BBCSDL there's a link in the Help menu, indeed the Help menu contains links to all the main sources of information (the main manual, the beginners' tutorial, the wiki, the website, the discussion group and this forum - even one to email me!). So if you make the Help menu the 'go to' place for answers you will be reminded.

Ah, that's great. Thanks for letting me know about that.

As a follow-up question - and i have looked in both the help AND the wiki and not found an answer to this(!) - what's the deal with European accented characters, i.e. ü ö é and the like? When they're read from the data file they're not appearing correctly but in their bastardised forms (i.e. ü = Ā¼). i've read the Help article 'Multilingual (Unicode) text output' but that seems only to apply to non-Roman character sets. Apologies if i've missed something in the Help/Wiki that addresses this.

[guest]

what's the deal with European accented characters, i.e. ü ö é and the like? When they're read from the data file they're not appearing correctly but in their bastardised forms (i.e. ü = Ā¼).

How are they encoded in your data file (if the file was exported from Notepad there's an option in the File Save dialogue)? If they are encoded as ANSI then you need to ensure that your program is configured for ANSI, if they are encoded as UTF-8 you need to ensure that your program is configured for UTF-8. The main way of determining that is via the final parameter of the VDU 23,22.... command (0 or 128 for ANSI, 8 or 136 for UTF-8).

You also need to ensure that you have selected an appropriate font: if your data file is UTF-8 encoded that means a Unicode font (most are, apart from the default 'system fixed font', or bitmapped font in the case of BBCSDL).

Incidentally, as is almost always the case in Windows, what I mean by 'ANSI' is whatever the current Code Page is. It will usually be ANSI in the UK and US but probably something different in other countries. This is precisely why UTF-8 is nearly always a better choice of encoding because it's the same everywhere!

[5against4]

How are they encoded in your data file (if the file was exported from Notepad there's an option in the File Save dialogue)?

They were created using Visual Studio Code, which seems to default to UTF-8. i've just changed it to ANSI and all is now fine

Thanks a second time!

[guest]

They were created using Visual Studio Code, which seems to default to UTF-8. i've just changed it to ANSI and all is now fine

Just bear in mind that it won't be "fine" if your program is ever run on a platform where the default Code Page is not ANSI, and if you're having to deal with European accented characters that suggests that you may be wanting it to run in countries other than the UK and US! As I said, it is far better to work with UTF-8 so I would advise switching back and changing your program to work with UTF-8 too. There should be little overhead in doing that, especially with the availability of the UTF8LIB library.

[5against4]

As I said, it is far better to work with UTF-8 so I would advise switching back and changing your program to work with UTF-8 too. There should be little overhead in doing that, especially with the availability of the UTF8LIB library.

Good point, and until just now (having referred to the manual), i didn't realise switching to UTF-8 mode was as simple as altering one byte! All sorted now; i've reverted the data file back to UTF-8 format and it works fine with the program. Thanks again for the help, very much appreciated