Console differences after PB 5.42 ?
Console differences after PB 5.42 ?
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
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
Paul Dwyer
“In nature, it’s not the strongest nor the most intelligent who survives. It’s the most adaptable to change” - Charles Darwin
“If you can't explain it to a six-year old you really don't understand it yourself.” - Albert Einstein
“In nature, it’s not the strongest nor the most intelligent who survives. It’s the most adaptable to change” - Charles Darwin
“If you can't explain it to a six-year old you really don't understand it yourself.” - Albert Einstein
Re: Console differences after PB 5.42 ?
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?
Did you compile your old program in Ascii?
sorry for my bad english
Re: Console differences after PB 5.42 ?
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...
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...
Paul Dwyer
“In nature, it’s not the strongest nor the most intelligent who survives. It’s the most adaptable to change” - Charles Darwin
“If you can't explain it to a six-year old you really don't understand it yourself.” - Albert Einstein
“In nature, it’s not the strongest nor the most intelligent who survives. It’s the most adaptable to change” - Charles Darwin
“If you can't explain it to a six-year old you really don't understand it yourself.” - Albert Einstein
Re: Console differences after PB 5.42 ?
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
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
Re: Console differences after PB 5.42 ?
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
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
Paul Dwyer
“In nature, it’s not the strongest nor the most intelligent who survives. It’s the most adaptable to change” - Charles Darwin
“If you can't explain it to a six-year old you really don't understand it yourself.” - Albert Einstein
“In nature, it’s not the strongest nor the most intelligent who survives. It’s the most adaptable to change” - Charles Darwin
“If you can't explain it to a six-year old you really don't understand it yourself.” - Albert Einstein
-
- Addict
- Posts: 4527
- Joined: Thu Jun 07, 2007 3:25 pm
- Location: Berlin, Germany
Re: Console differences after PB 5.42 ?
You can trypdwyer wrote: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() ?
Code: Select all
PrintN(PeekS(*Buffer, -1, #PB_Ascii))
And there is a thread containing tips & tricks concerning Unicode and PureBasic, maybe it is helpful for you.
Re: Console differences after PB 5.42 ?
Thanks for your help, it helped get through this.
Using:
seems to make the printN() work okay
This instead of input() I use
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:
I can probably clean this up a bit more but the app now works on the new version with both x86 and x64 compiles
Using:
Code: Select all
OpenConsole("",#PB_Ascii)
This instead of input() I use
Code: Select all
*Buffer = AllocateMemory(BufferSize)
RetConInput = ReadConsoleData(*Buffer, BufferSize)
Mgrinput = PeekS(*Buffer, -1, #PB_Ascii)
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
Paul Dwyer
“In nature, it’s not the strongest nor the most intelligent who survives. It’s the most adaptable to change” - Charles Darwin
“If you can't explain it to a six-year old you really don't understand it yourself.” - Albert Einstein
“In nature, it’s not the strongest nor the most intelligent who survives. It’s the most adaptable to change” - Charles Darwin
“If you can't explain it to a six-year old you really don't understand it yourself.” - Albert Einstein
Re: Console differences after PB 5.42 ?
Thank you for the feedback.pdwyer wrote: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
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)).
Re: Console differences after PB 5.42 ?
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
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
Paul Dwyer
“In nature, it’s not the strongest nor the most intelligent who survives. It’s the most adaptable to change” - Charles Darwin
“If you can't explain it to a six-year old you really don't understand it yourself.” - Albert Einstein
“In nature, it’s not the strongest nor the most intelligent who survives. It’s the most adaptable to change” - Charles Darwin
“If you can't explain it to a six-year old you really don't understand it yourself.” - Albert Einstein
-
- Addict
- Posts: 4527
- Joined: Thu Jun 07, 2007 3:25 pm
- Location: Berlin, Germany
Re: Console differences after PB 5.42 ?
Hi,pdwyer wrote: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)
does
Code: Select all
*Buffer = Ascii(Input())
Re: Console differences after PB 5.42 ?
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
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
Paul Dwyer
“In nature, it’s not the strongest nor the most intelligent who survives. It’s the most adaptable to change” - Charles Darwin
“If you can't explain it to a six-year old you really don't understand it yourself.” - Albert Einstein
“In nature, it’s not the strongest nor the most intelligent who survives. It’s the most adaptable to change” - Charles Darwin
“If you can't explain it to a six-year old you really don't understand it yourself.” - Albert Einstein
Re: Console differences after PB 5.42 ?
Yes, he's doing what he's supposed to dopdwyer wrote: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().
...
"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.
Re: Console differences after PB 5.42 ?
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.
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.
Paul Dwyer
“In nature, it’s not the strongest nor the most intelligent who survives. It’s the most adaptable to change” - Charles Darwin
“If you can't explain it to a six-year old you really don't understand it yourself.” - Albert Einstein
“In nature, it’s not the strongest nor the most intelligent who survives. It’s the most adaptable to change” - Charles Darwin
“If you can't explain it to a six-year old you really don't understand it yourself.” - Albert Einstein