Query using Turbo Basic

[GreensandsParticipant @greensands]

Unwanted new line when printing strings

[GreensandsParticipant @greensands]

Hi All – Can anyone suggest a way of printing strings in Turbo Basic without having an unwanted new line following the string. I have tried adding a comma and a semicolon at the end of the print statement which I gather does work with QBasic and GW-Basic but neither appear to work with Turbo Baisc. Any helpful suggestions would be much appreciated.

[SillyOldDufferModerator @sillyoldduffer]

According to the manual ( PowerBASIC v4 )

PRINT "Hello";
PRINT " World!";

should result in 'Hello World!' – which is conventional BASIC syntax. What does your code say?

Dave

.

[GreensandsParticipant @greensands]

Hi Dave – This is my problem. Inserting a comma (or semicolon) as shown in you example above does not have the desired effect in TurboBasic. Printing out from an string array places a new line between each record with or without the comma or semi.

Reg

[SillyOldDufferModerator @sillyoldduffer]

Hi Reg,

If it possible that the strings in the array contain a newline character? Try chopping the end off with a Left, something like

PRINT LEFT( S, LEN(S) – 1 )

Not sure this is the best way to do it – my BASIC skills are out of date! (eg May be LEFT$)

Dave

[Bill Davies 2Participant @billdavies2]

My Basic skills are long out of date, but, I note you mention a record. Does this mean you are printing to file? In that case, I wonder whether it is using the newline to indicate end of record. If you can inspect the file, you would probably find two characters, CR and LF carriage reurn and line feed, if you are using a Microsoft Operating System. Separators between fields in the record might be commas or tabs, as determined by your programming.

If you can't hex dump the file, you can print one record to file with a known number of characters, and see whether the file is one OR two characters larger than that.

If you don't have a hex dump program, you might try HxD, which is free:

HxD program

If you've not used one before, you find it quite interesting to view various small files. You will need to find a table of ASCII codes, although many text files now us two bytes per character, in place of the original one.

I hope this is not 'sucking egg' territory.

Bill

[Gerard O’TooleParticipant @gerardotoole60348]

Not sure it helps, but I think if you separate items within a PRINT statement with a semicolon they are printed on the same line. But each separate PRINT statement will add a cr/nl sequence .. You need to use PRINT a;b to get both a and b on the same line.

Could you use PRINT USING or use TAB or LOCATE ?

Finally, it might depend on the output device. Are you displaying the information or printing to a printer.

Sorry but that is about all I can remember from Turbo BASIC days. (It might also vary depending on the version of Turbo BASIC)

This archive might help

[GreensandsParticipant @greensands]

Have not tried using the Hexdump approach yet but have tried checking the LEN of a string containing a known of characters without any indication of hidden characters.

E.g TEST$="123456789" N%=LEN(TEST$) PRINT N% gives a value of 9

[SillyOldDufferModerator @sillyoldduffer]

Posted by Greensands on 03/03/2020 10:24:06:

Have not tried using the Hexdump approach yet but have tried checking the LEN of a string containing a known of characters without any indication of hidden characters.

E.g TEST$="123456789" N%=LEN(TEST$) PRINT N% gives a value of 9

If it's not a hidden character in the string, and the syntax is correct (I believe it is), then probably something to do with the environment.

Which version of TurboBASIC and what are you running it on?

There are many differences between the original 1980's TurboBASIC for MS-DOS, and the current PowerBASIC (version 6) for Windows. The Windows versions added a lot of functionality – the Manual for V4 is about 600 pages, V6 is over 3000 pages.

How exactly is the program run? Assuming it's an early Borland TurboBASIC, unless you have a genuine MSDOS machine, the problem may be in the console emulation that modern Windows uses to simulate an MS-DOS screen. The later Windows PowerBASIC can talk direct to Windows graphics, but it too has a console emulator for character mode.

To eliminate screen display side-effects try PRINT to a file:

OPEN "TEST.DTA" FOR OUTPUT AS #1
PRINT #1, "Hello";
PRINT #1, " World"
CLOSE 1

If the contents of the file are "Hello World", then the problem is in the console emulator, might be a setting.

Very mysterious. A workaround might be to concatenate the strings rather than have a series of print statements, as in

S1$ = "Hello"
S2$ = " World"
BOTH$ = S1$ + S2$
PRINT BOTH$

As always more information would help; can you share any of the actual code? How the array is set, and any processing done to the strings before the offending PRINT might contain a clue.

Dave

[GreensandsParticipant @greensands]

Carrying out further tests I have come to the conclusion that the insertion of a new line is a function more of the print command rather than an embedded LF/CR within the data string. – just a thought

[Steve FParticipant @stevef]

Hello

Have you tried string concatenation (i had to google it, i had no idea how to spell it) the strings into 1 string to print,

string1 "Hello "

string2 "World"

Print string1 & string2

regards

Steve

[Bill Davies 2Participant @billdavies2]

Greensands, with regard to the function appending the 'newline' character(s), I agree. If you can print your string of characters to a small file and then view its size you will see if extra characters have been added. Unfortunately i haven't used Basic in a long time, but TurboPascal and other languages functioned the the same (if you pardon the pun).

I'm afraid I can't help on avoiding the newline from occuring.

Bill

[Nick Clarke 3Participant @nickclarke3]

Try outputting with PRINT USING with $ as the format string.

ie PRINT USING "$"; a$

I don't have a copy of Turbo BASIC here but when I get home I will install a copy and have a look if this does not sort it for you.

PS Does the ASCII backspace character (08h) move you back a space over the LF character??

Edited By Nick Clarke 3 on 03/03/2020 11:56:30

[Bill Davies 2Participant @billdavies2]

Another option might be to print individual characters to file (BPUT?) using, e.g., a for loop.

Bill

[SillyOldDufferModerator @sillyoldduffer]

The semi-colon syntax works for me. This is TurboBASIC 1.0 downloaded from AbandonWare and running on Ubuntu 19.10 under DOSBOX

Note HELLO WORLD on one line in the Run box, bottom right. The semi-colon stopped PRINT H$; from throwing a newline as would PRINT H$

Dave

 

 

Edited By SillyOldDuffer on 03/03/2020 12:50:56

[GreensandsParticipant @greensands]

To answer a previous question I am runing a DOS version of Borland Turbo Basic (8 chars max filenames) under Windows XP

[Bill Davies 2Participant @billdavies2]

Referring to the 1987 manual (Turbo BASIC manual), p.307 tells us that putting the semicolon at the end of items to be printed supresses the otherwise automatic printing of a carriage return. I wouldn't expect another version of the program to give a different behaviour, as it's probably the most-used standard function in the language.

Nick's comment sounds like a good idea to move the cursor back. A problem I remember from TurboPascal (which was probably similar in behaviours) was that printing to the last character in the bottom line of the screen caused the screen to scroll up one line, which was unrecoverable.

Bill

[Nick Clarke 3Participant @nickclarke3]

Running Turbo BASIC 1.1 in VMWare I typed in this code fragment to use a string array:

DIM a$(2)
a$(1)="Hello"
a$(2)=" World"
FOR n=1 to 2
PRINT a$(n);
NEXT

Output was Hello World

So I can't replicate your error – I suspect it might be due to the WinXP Console emulation, but without a live XP system any more I am stuck here. I could run XP in VMware, but that might be a little too far removed from your set up to have any value.

Sorry,

Nick

[GreensandsParticipant @greensands]

Apologies for the delay in coming back but many thanks to all for the help and usefful suggestions. I found a way out of my problems which I traced to a number of hidden characters within the data strings and which in the absence of a Hex dump remained out of sight. Problem was overcome by setting a trap for all characters within the range <CHR$(32 and >CHR$(126) all became sweetness and light!

[SillyOldDufferModerator @sillyoldduffer]

Posted by Greensands on 06/03/2020 10:10:20:

Apologies for the delay in coming back but many thanks to all for the help and usefful suggestions. I found a way out of my problems which I traced to a number of hidden characters within the data strings and which in the absence of a Hex dump remained out of sight. Problem was overcome by setting a trap for all characters within the range <CHR$(32 and >CHR$(126) all became sweetness and light!

Well done you – control characters hiding invisibly in the data are a wonderful time-waster!

Don't ask how I know…

Dave

[GreensandsParticipant @greensands]

I have another query using Turbo Basic. Using a FOR/NEXT routine to search for a file within a specified folder works exactly as expected but has the (slight) disadvantage of the need to specify the range of the variable .

e.g FOR I%= 1 TO 100

I would prefer to replace this routine with a DO UNTIL EOF#(n) /LOOP to overcome this problem.but for some reason I cannot get this to work despite no other changes being made to the coding.

Can anyone offer a possible explanation for this?

[SillyOldDufferModerator @sillyoldduffer]

Posted by Greensands on 10/05/2022 15:35:10:

…

I would prefer to replace this routine with a DO UNTIL EOF#(n) /LOOP to overcome this problem.but for some reason I cannot get this to work despite no other changes being made to the coding.

Can anyone offer a possible explanation for this?

DO

UNTIL EOF

loops are dodgy because the file may not have opened or been read correctly, so it's usual to invert the loop. Try something like:

OPEN "YOURFILE.TXT" FOR INPUT AS #1
WHILE NOT EOF(1)
INPUT #1, DATA$
PRINT DATA$
WEND

If the "YOURFILE.TXT" is found and has read permission, it will open. EOF is true if the file is empty, else false so INPUT #1 won't get called on an empty or not found file. EOF is checked first, whereas DO…UNTIL does it at the end, and might hit a problem because of that.

DO…UNTIL checking at the end makes it less popular than WHILE WEND

Dave

 

 

 

 

Edited By SillyOldDuffer on 10/05/2022 17:14:20

[GreensandsParticipant @greensands]

Hi Dave – Have now seen the light!, Thanks once again for your help. Always a mine of information.

[Author]

Posts