View Issue Details

IDProjectCategoryView StatusLast Update
0033591FPCOtherpublic2019-09-15 15:10
ReporterEduardo VieiraAssigned ToMarco van de Voort 
PrioritynormalSeverityminorReproducibilityalways
Status feedbackResolutionopen 
PlatformWindowsOSWindowOS VersionXP and Later
Product Version3.0.4Product Build2017/10/06 
Target VersionFixed in Version 
Summary0033591: FP allways make convertion to Code Page 1252
DescriptionFP always uses codepage 1252 even if I change to 850.

Steps To ReproducePROMPT> CHCP 850

...
  setconsolecp(850);
  setconsoleoutputcp(850);
  SetMultiByteConversionCodePage(850);
...




Additional InformationIf I type a character (>>127) of the code page 850 or if I pass via program parameter, the FP will always understand as if I was using the code page 1252.

I have to use CP 850 because I have many files using this CP.

TagsNo tags attached.
Fixed in Revision
FPCOldBugId
FPCTarget-
Attached Files

Activities

Thaddy de Koning

2018-04-09 17:06

reporter   ~0107715

use {$codepage 850} in your sources too.

Eduardo Vieira

2018-04-09 20:50

reporter   ~0107718

I'll try and will report here.
Thank you.

Eduardo Vieira

2018-04-09 21:11

reporter   ~0107719

{$codepage CP850}
...
It did not work.
By the way, the behavior of keyboard reading in WXP is different from behavior in W10.

Thaddy de Koning

2018-04-09 22:46

reporter   ~0107723

Last edited: 2018-04-09 22:52

View 4 revisions

"By the way, the behavior of keyboard reading in WXP is different from behavior in W10."
That is not correct. What maybe happened is that in between 1999 and 2018 you use different computers with different windows installed. There are some very slight security related issues that are supposed to be non-detectable for normal use.
E.g.:if something types faster that humanly feasable or something types more evenly than humanly feasable... That is indeed changed in Windows 10, although hardly docmented outside of the development community versions..Explicitly: the keyboard driver -which now requires! interaction.-, nothing else in the given example.

Eduardo Vieira

2018-04-09 23:05

reporter   ~0107724

I have several computers with different OS for testing.
But, I've verified and... it's equal in 2.6.0 and 2.6.4, except, of course, without "SetMultiByteConversionCodePage" !
So, that is no big deal.
Thanks.

Marco van de Voort

2019-09-15 14:05

manager   ~0118083

Last edited: 2019-09-15 15:10

View 3 revisions

1. The parameters have been parsed before the SET* statements, so this is probably useless.
2. chcp only seems to influence the console. The winapi still returns "1252" as system codepage (getacp)
3. afaik FPC 3+ uses unicode functions for parameters. So it isn't FPC that does the "wrong" conversion but windows

It could also be the transforming back to ansistring that is the problem. Try to convert unicodestring parameters manually to cp850.

Issue History

Date Modified Username Field Change
2018-04-09 14:17 Eduardo Vieira New Issue
2018-04-09 17:06 Thaddy de Koning Note Added: 0107715
2018-04-09 20:50 Eduardo Vieira Note Added: 0107718
2018-04-09 21:11 Eduardo Vieira Note Added: 0107719
2018-04-09 22:46 Thaddy de Koning Note Added: 0107723
2018-04-09 22:48 Thaddy de Koning Note Edited: 0107723 View Revisions
2018-04-09 22:48 Thaddy de Koning Note Edited: 0107723 View Revisions
2018-04-09 22:52 Thaddy de Koning Note Edited: 0107723 View Revisions
2018-04-09 23:05 Eduardo Vieira Note Added: 0107724
2019-09-15 14:05 Marco van de Voort Assigned To => Marco van de Voort
2019-09-15 14:05 Marco van de Voort Status new => feedback
2019-09-15 14:05 Marco van de Voort FPCTarget => -
2019-09-15 14:05 Marco van de Voort Note Added: 0118083
2019-09-15 15:09 Marco van de Voort Note Edited: 0118083 View Revisions
2019-09-15 15:10 Marco van de Voort Note Edited: 0118083 View Revisions