bug when using _Dest _Console

[Jack]

this works Ok, you are prevented from entering a number that's too large for a long

Code: (Select All)

Dim As Long n
Input "n "; n
Print n

however that's not the case here

Code: (Select All)

$Console:Only
_Dest _Console

Dim As Long n
Input "n "; n
Print n

sample run

Code: (Select All)

n ? 99999999999999999999
999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 999999999

Press any key to continue

[mnrvovrfc]

It's not a bug. Galleon designed it that way. The problem is you're trying to get a value for a "LONG" which cannot be higher than (2 ^ 32) - 1. Must ask for the value of a string if you want an integer any larger than the maximum range of an "_INTEGER64".

LOL the message from the system should be "Press enter to continue" out of the console. Hmmm... There should be no need to use "_DEST _CONSOLE" anymore, use "$CONSOLE:ONLY" instead for a program that is entirely going to use the console.

[bplus]

Console Input difference confirmed and also correct mnrvovrfc,_Dest _Console not needed.

It is interesting that after some spaces the correct 9 nines is printed?
   

[Jack]

I simply hate the graphic console, you can't do copy or paste with it, look at the output, it certainly is a bug
999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 999999999

[bplus]

Certainly. Yes clearly a bug, I would agree. If n is a Long Type, Input should not allow more than 9 nines to be printed. We are expecting Input to behave the same in Console as in regular screen.

For a copy of something that is output, I recommend using the _Clipboard, otherwise there is only a screen shot.

Update: see what went into clipboard!
   

[mnrvovrfc]

For a copy of something that is output, I recommend using the _Clipboard, otherwise there is only a screen shot.

Could build a function that prints to the SCREEN 0 as well as to the clipboard, then save clipboard contents to a text file but have to be clever enough about it. Otherwise must keep a text file open for output while displaying to the SCREEN 0, and to add to the file. It sucks and could be frustrating when the programmer forgets to do it and needs to debug the program based on its output.

It's easy to become spoiled by "PRINT" statement so that a programmer dreads having to use a "SUB" or "FUNCTION" instead for any "PRINT'ing". But it must be done in a few cases where a console-only program is not practical for the purpose.

The "$CONSOLE:ONLY" antics reminds me of Liberty BASIC 32-bit on WindowsXP which had a "mainwin" that looked like Windows Notepad, and had a similarity to QB64's non-console screenie. It was like Notepad allowing the user to write any text he/she wanted with program output and save it to a text file. Liberty BASIC had a command called "nomainwin" which wasn't recommended used except for graphics-only programs.

It still exists although it's a little bit stale:
https://www.libertybasic.com/

Telling by the "Video" unit of Free Pascal and other places it's a real itch programming for the console on Linux or Windows, so it's a doubt that something like the "mainwin" of Liberty BASIC could become an alternative to the SCREEN 0 of QB64. We might have to vote for it.

[Jack]

the graphic console is ok for display-only but if you want to copy the displayed "text" by click&drag with the mouse you are **** out of luck, look at the thousands of screenshots on the former forum simply because you couldn't copy the displayed text, now you are going to tell me that you can use some _clipboard command to place something on the clipboard, that's simply lame compared to simply using the mouse with click&drag
but not just the ability to copy text but also to paste

[mnrvovrfc]

I was only making a suggestion. Yes it takes more work and it sucks, I don't like it neither. The "SCREEN 0" was built the way it was because it was the closest thing to a MS-DOS screen as people remembered running programs from M$QB, and that console couldn't copy-paste neither. It was built like that because it was much harder to do it with "cmd.exe" console and it was going to affect portability. Eventually a way was discovered to force QB64 text output into a console anyway without a lot of interest in being consistent between that and the SCREEN 0.

People using GW-BASIC were almost never interested in capturing all output from programs or whatever was on the screen. So M$QB only inherited that behavior. This was before there was such a thing as a "clipboard". What do you think people did during the 1980's to debug program output? Create a text file and double the "PRINT" statements, one to the screen and the other to the text file, and then examine the text file for inconsistencies. Also think about the old "FILES" statement output before there was any use of it away from finding your BASIC program to load into the interpreter LOL.

This is an obvious bug you reported, though, it shouldn't display all those extra 9's making me dizzy...

[bplus]

Screen 0 does know what characters and color are at each cell position, it might be recreated easily with a sub or function. And more cleverness could handle scrolling. Maybe just echo everything to a .txt file.

Perhaps the other screens could likewise be interrogated probably through Memory, but it would be a sub or function you'd have to remember to drag and drop into you app.

But these will still be considered lame for Jack, I'm sure.

I think Jack wants something free and automatic like LB or JB has, as mnrvovrfc mentions. It does come in handy.

[mnrvovrfc]

Screen 0 does know what characters and color are at each cell position, it might be recreated easily with a sub or function. And more cleverness could handle scrolling. Maybe just echo everything to a .txt file.

If the SCREEN 0 has to display a bit of stuff, yes, using "SCREEN()" function could be enough. But if it begins to display something at the top, once something large at the bottom begins to be outputted, it. Is. Lost. Some people tried to get around it by using "WIDTH" which led to more frustration when they asked for even more things printed on the screen.

Anyway QB64 is more advanced than that having "_CLIPBOARD$", the problem is must have one string variable to concatenate to which could be very slow, only so it becomes the value of "_CLIPBOARD$" at the end for the sake of an output file. It became even more advanced supporting the console as well as the screenie, but...

Using "_MEMIMAGE()" or alike would bring back the problem with using "WIDTH", how large do I have to make the buffer before I start printing stuff? Instead of trying to make more characters across, have to define the size of the page. Could hack into QB64PE to change the SCREEN 0 to behave like "cmd.exe" or Linux terminal setting a limit of a number of lines to save to a buffer but that could cause the user program's executable to demand more RAM. Again, have to decide there how many characters per line, at least 80.

I admit, I liked Liberty BASIC only because of that "mainwin", it was useful for treating a computer running BASIC like a fancy calculator that printed on paper. The only change is to include those very-large and very-small numbers you guys keep featuring on this site.