Console differences after PB 5.42 ?

[pdwyer]

I am in the process of starting a new version of an app I was working on a few years ago but when I compiled in the latest version of PB (5.7) things started failing.

Since this software interacts with other software using STDIO it's very hard to nail down what exactly has changed since I didn't write the other software.

If I run my console app myself on the commandline then regardless of PB version it seems to work and interact with the console fine.

(edit: this is on windows 10)

When the 3rd party software runs my app and interacts with it using input() and PrintN():
- It works fine if I compile with 5.42 or earlier (both 32bit and 64 bit)
- The 3rd party app seems to think my app is not responding if I use v5.51 or later (both 32bit or 64bit)

There was a change around then in PB to add options to OpenConsole() for ascii/utf8/utf16 and if the default codec has changed then perhaps the 3rd party app doesn't like the new codec default although tried forcing it to #pb_ascii but there was no differences.

Does anyone know of any differences to how PB interacts with the console after v5.42 (basically just OpenConsole(), input() and PrintN() ) and what kinds of workarounds exist?

To test I've basically just compiled the same code with all sorts of different versions without change, compile works fine but the resulting exe seems to have some hard-to-see difference in the way it works.

Suggestions welcome as currently my workaround is to use older versions of PB

Cheers

[Josh]

I'm not sure if it's even the console. The big difference between 5.42 and the current Pb version is, that since 5.50 the compilation is always in Unicode.

Did you compile your old program in Ascii?

[pdwyer]

I think you have something here.

In the past, I've never used the "Create unicode executable" option in compiler options before. Now that I look more closely this option is gone.

If I do create as unicode then I can reproduce the problem of the later versions (good news)

But, there doesn't seem to be a way to create a non unicode exe anymore, and in "OpenConsole()" the #pb_ascii option doesn't seem to fix this in the newer versions. I guess that the 3rd party app I'm interfacing with doesn't support unicode but shouldn't the openconsole param work around this issue?

When I don't use #pb_ascii then when I send data I trip the other software with the nulls in unicode
when I do use it the input() never triggers on my side to receive (the crlf not coming through or something?)

Thanks for the suggestions so far...

[Marc56us]

Have you tried
OpenConsole("", #PB_Ascii)
and
then sending ASCII strings converted text ?

Check too IDE encoding (File > File Format > PlainText | Utf8

25th July 2016 : Version 5.50
- Removed: ASCII mode for internal PureBasic string representation, PureBasic is now unicode only.
https://www.purebasic.com/documentation ... story.html

[pdwyer]

Hi,

I had already tried this:
OpenConsole("", #PB_Ascii)

When I'm using input() though, it just sits there, I suspect it's not recognizing the CR that comes in to tell me that the line has arrived.
But if input() is waiting for unicode then what is the point of #PB_Ascii in the openconsole? it sounds like it's only affecting the printn()
I guess I can try the "ReadConsoleData()" to see what's coming in and try to convert it myself

If I'm going to send with printN(), how can I convert to ascii first if the function:
*Buffer = Ascii(String$)
returns a pointer to memory and not something I can pass to printn() ?

I tried changing the IDE encoding but no luck

perhaps there is some combination here that works.. I'll give it some more effort tomorrow

Thanks for your help

[Little John]

If I'm going to send with printN(), how can I convert to ascii first if the function:
*Buffer = Ascii(String$)
returns a pointer to memory and not something I can pass to printn() ?

You can try

Code: Select all

PrintN(PeekS(*Buffer, -1, #PB_Ascii))

If there are other PeekS() or PokeS() commands in your code, you should use the flag #PB_Ascii there, too.

And there is a thread containing tips & tricks concerning Unicode and PureBasic, maybe it is helpful for you.

[pdwyer]

Thanks for your help, it helped get through this.

Using:

Code: Select all

 OpenConsole("",#PB_Ascii)

seems to make the printN() work okay

This instead of input() I use

Code: Select all

       *Buffer = AllocateMemory(BufferSize)
       RetConInput = ReadConsoleData(*Buffer, BufferSize)
       Mgrinput = PeekS(*Buffer, -1, #PB_Ascii)

After this, since I had a case statement for each command that came in one per line, I had to change that since I'd get several lines at once so there would be a new loop:

Code: Select all

       BuffLoop = 1
       BufferPart  = StringField(Mgrinput, BuffLoop, #CRLF$)

       While BufferPart

            ;... (previous Select case code)

            BuffLoop = BuffLoop + 1
            BufferPart  = StringField(Mgrinput, BuffLoop, #CRLF$)
       Wend

I can probably clean this up a bit more but the app now works on the new version with both x86 and x64 compiles

[Marc56us]

Thanks for your help, it helped get through this.
...
I can probably clean this up a bit more but the app now works on the new version with both x86 and x64 compiles

Thank you for the feedback.
It's nice to see when we've been able to move forward.

Since the two programs communicate, it means that it wasn't a bug in the language or the compiler, but just an encoding issue.
Afterwards there are often questions of buffers to think about resizing or emptying (or filling with zeros (ie: FillMemory)).

[pdwyer]

While perhaps not a bug, the change in functionality has damaged the input() capabilities.

The Ascii options for OpenConsole() were added to cope with part of this issue which allows PrintN() to work properly (I believe, since they came at about the same time)
"#PB_Ascii: string will use ASCII format when printed to the console."

But there is no workaround for Input() since the functionality of ReadConsoleData() not line based and not available in Graphical mode (which thankfully I'm not using in this case).

Admittedly I'm saying this without understanding the effort involved under the hood which could be prohibitive, but I would suggest either

1. Have Input() change to ascii mode like PrintN() does when console is opened with #PB_Ascii
or
2. Have a #PB_Ascii param option for input()

(or UTF8 etc)

Anyway, not urgent since there is a workaround but the workaround is to avoid a key function [Input() ] with one that behaves differently because input() isn't handling something that console and other functions can.

Just my 2 yen

[Little John]

Admittedly I'm saying this without understanding the effort involved under the hood which could be prohibitive, but I would suggest either

1. Have Input() change to ascii mode like PrintN() does when console is opened with #PB_Ascii
or
2. Have a #PB_Ascii param option for input()

(or UTF8 etc)

Hi,

does

Code: Select all

*Buffer = Ascii(Input())

not do what you want?

[pdwyer]

I'll try it again later but I don't think so.

input() never returns as it's waiting for a unicode EOL or CRLF or something. the program just hangs waiting for input().

It's not a conversion problem.

Using ReadConsoleData() brings several lines in together and I can then convert them and split them as it's not waiting for a specific char to arrive

[Marc56us]

I'll try it again later but I don't think so.

input() never returns as it's waiting for a unicode EOL or CRLF or something. the program just hangs waiting for input().
...

Yes, he's doing what he's supposed to do
"This function locks the program execution and waits until the user presses the return key. " (so a keyboard code, not a char)
https://www.purebasic.com/documentation ... input.html

Input() is the equivalent of the shell command (cmd.exe / command.com) "pause" and not at all of the classic basic command: INPUT#

In other words, it does return a string (if necessary) but requires a keyboard action by user.

So to automate the dialog between two applications via the console, do not use Input(), but ReadConsoleData() and analyze the contents of the buffer until you find the end of dialog indicator (defined by the sending application). The special EOT character (Chr(4) or #PB_Input_Eof) is for example very useful.

[pdwyer]

But if you are in graphical mode and can't use ReadConsoleData() then you have no workaround for this. (unless there is some API call or something)

If not a bug then probably should be a feature request since someone is going to get caught out on this in the future, I was lucky that I don't need the graphical mode in my app so wasn't using it.