Re: [fpc-devel] GetConnectionDef in the interface section
On Sun, 15 Jul 2007, Joao Morais wrote: Hello, It's possible include the following declaration: function GetConnectionDef(ConnectorName: string): TConnectionDef; in the interface section of the sqldb unit and merge to 2.2? Moving it to interface is not a problem. Merge to 2.2 is another matter. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Having an always utf-8 string
Op Mon, 16 Jul 2007, schreef Felipe Monteiro de Carvalho: Hi, I would like which would be the theoritical way that Free Pascal could support an always utf-8 encoded string (if it will be supported). With that I mean a string which when set by code is converted from widestring to utf-8 in despite of any environmental conditions, or operating system conditions. So I can open a feature request for it. Based on past discussion, I assume that the prefered way would be using the UTF8String type, is that correct? Another option would be having the possibility to manually change the output format of the widestring managed. I think this gets more important as Lazarus moves to UTF-8. a) We indeed need some configurability in the widestringmanager. b) Ignoring the environment seems a bad idea to me. c) There exists utf8decode/utfencode, so I do not see the problem for UTF-8? Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] graphh.inc - few questions.
On 14 Jul 2007, at 16:01, Evgeniy Ivanov wrote:
I'm doing sdlgraph - so I put my self to packages/base/graph.
graph probably has to be moved to packages/extra, so it can easily
use things like sdl and the (Mac OS X) universal interfaces.
I can't understand the method (where are they used?) using routines in
TModeInfo (from graphh.inc).
In custom graph modules it's used in such way:
mode.PutPixel:={$ifdef [EMAIL PROTECTED];
But in windows and go32v2 there are no any routines for PutPixel from
interface.
They don't need to be in the interface. PutPixel is a procedure
variable, and the only thing that needs to be in the interface (and
it's declared in graphh.inc, which is included in the interface of
the go32v2 and win32 unts). The procedures which are assigned to this
procvar do not have to be in the interface.
I mean someting like
PutPixel := @custom_PutPixel; (PutPixel :=
@libvga_PutPixelProc; - in the unix graph.pp).
So, if there are no such assignations (sorry, I don't know the
right word)
PutPixelDefault from graph.inc will be used...
And it is:
procedure PutPixelDefault(X,Y: smallint; Color: Word);
begin
Writeln(stderr,'Error: Not in graphics mode (use InitGraph and
test
GraphResult afterwards)');
Halt(1);
end;
But windows module works...
Have a look at QueryAdapterInfo in graph.pp of go32v2. It has many
blocks like this:
InitMode(mode);
{ now add all standard VGA modes... }
mode.DriverNumber:= LowRes;
mode.HardwarePages:= 0;
mode.ModeNumber:=0;
mode.ModeName:='320 x 200 VGA';
mode.MaxColor := 256;
mode.PaletteSize := mode.MaxColor;
mode.DirectColor := FALSE;
mode.MaxX := 319;
mode.MaxY := 199;
mode.DirectPutPixel:={$ifdef [EMAIL PROTECTED];
mode.PutPixel:={$ifdef [EMAIL PROTECTED];
mode.GetPixel:={$ifdef [EMAIL PROTECTED];
mode.SetRGBPalette := {$ifdef [EMAIL PROTECTED];
mode.GetRGBPalette := {$ifdef [EMAIL PROTECTED];
mode.SetAllPalette := {$ifdef [EMAIL PROTECTED]
SetVGARGBAllPalette;
mode.SetVisualPage := {$ifdef [EMAIL PROTECTED];
mode.SetActivePage := {$ifdef [EMAIL PROTECTED];
mode.InitMode := {$ifdef [EMAIL PROTECTED];
mode.XAspect := 1;
mode.YAspect := 1;
AddMode(mode);
When switching to a mode, initgraph will assign the putpixel field of
that mode to the global putpixel procvar.
Jonas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Please merge SSE detecion fix to fixes_2_2
On 15 Jul 2007, at 07:27, Martin Schreiber wrote: Can the fix for Mantis 9242 (Debugging broken on win32 with PII) be merged to fixes_2_2? Independent from this, I would encourage you to submit a bug report against gdb for win32. If they don't know this is broken, they can't fix it. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Running test suite for 2.1.4 on linux/sparc
I've been tinkering for a few weeks, hoping eventually to get Lazarus running on linux/sparc. I'm currently using FPC 2.1.4, apologies for not being nearer the bleeding edge. I've got problems with Lazarus that I suspect could be connected with code generation, because of this I've stepped back and am trying to run the FPC test suite. I can do this fine for linux/i386 (hosted on Debian Sarge) but linux/sparc (on Etch) grinds to an unseemly halt: /fpcbuild-2.1.4/fpcsrc/compiler/ppcsparc -n -FEsparc-linux -Tlinux popuperr.pp make[1]: Leaving directory `/fpcbuild-2.1.4/fpcsrc/tests/units' /bin/cp -fp test/cg/obj/linux/sparc/ctest.o test/cg /bin/cp -fp test/cg/obj/linux/sparc/tcext3.o test/cg /bin/cp: cannot stat `test/cg/obj/linux/sparc/tcext3.o': No such file or directory make: *** [copyfiles] Error 1 2 3[EMAIL PROTECTED]:/fpcbuild-2.1.4/fpcsrc/tests# echo TEST_FPC 0 3[EMAIL PROTECTED]:/fpcbuild-2.1.4/fpcsrc/tests# echo $TEST_FPC /fpcbuild-2.1.4/fpcsrc/compiler/ppcsparc running this with make -d gives a bit more detail: /fpcbuild-2.1.4/fpcsrc/compiler/ppcsparc -n -FEsparc-linux -Tlinux popuperr.pp Putting child 0x0007b118 (popuperr.ppu) PID 22199 on the chain. Live child 0x0007b118 (popuperr.ppu) PID 22199 Reaping winning child 0x0007b118 PID 22199 Removing child 0x0007b118 PID 22199 from chain. Successfully remade target file `popuperr.ppu'. Finished prerequisites of target file `extra'. Must remake target `extra'. Successfully remade target file `extra'. Finished prerequisites of target file `all'. Must remake target `all'. Successfully remade target file `all'. Finished prerequisites of target file `default'. Must remake target `default'. Successfully remade target file `default'. make[1]: Leaving directory `/fpcbuild-2.1.4/fpcsrc/tests/units' Reaping winning child 0x00143468 PID 22142 Removing child 0x00143468 PID 22142 from chain. Successfully remade target file `units'. Considering target file `copyfiles'. File `copyfiles' does not exist. Pruning file `output/sparc-linux'. Finished prerequisites of target file `copyfiles'. Must remake target `copyfiles'. /bin/cp -fp test/cg/obj/linux/sparc/ctest.o test/cg Putting child 0x001450e8 (copyfiles) PID 22201 on the chain. Live child 0x001450e8 (copyfiles) PID 22201 Reaping winning child 0x001450e8 PID 22201 /bin/cp -fp test/cg/obj/linux/sparc/tcext3.o test/cg /bin/cp: cannot stat `test/cg/obj/linux/sparc/tcext3.o': No such file or directory Live child 0x001450e8 (copyfiles) PID 22202 Reaping losing child 0x001450e8 PID 22202 make: *** [copyfiles] Error 1 Removing child 0x001450e8 PID 22202 from chain. 2 3[EMAIL PROTECTED]:/fpcbuild-2.1.4/fpcsrc/tests# I can see that 2.1.5 is regularly being tested on Solaris so things can't be too badly broken. I can confirm that the ...test/cg/obj/linux/sparc/ directory exists and is writable, I'm doing all of this close to / in case there are still pathlength issues anywhere. Can anybody point me at where I should be looking? If I can get this working and- in particular- if I can get a reliable copy of Lazarus on linux/sparc I hope to be able to continue testing releases etc., however I've got a fairly major learning curve to surmount :-/ -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Please merge SSE detecion fix to fixes_2_2
From: Jonas Maebe [EMAIL PROTECTED] On 15 Jul 2007, at 07:27, Martin Schreiber wrote: Can the fix for Mantis 9242 (Debugging broken on win32 with PII) be merged to fixes_2_2? Independent from this, I would encourage you to submit a bug report against gdb for win32. If they don't know this is broken, they can't fix it. Maybe it is fixed in new gdb 6.6. It can be downloaded from mingw site. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Running test suite for 2.1.4 on linux/sparc
On 16 Jul 2007, at 14:12, Mark Morgan Lloyd wrote: /fpcbuild-2.1.4/fpcsrc/compiler/ppcsparc -n -FEsparc-linux -Tlinux popuperr.pp make[1]: Leaving directory `/fpcbuild-2.1.4/fpcsrc/tests/units' /bin/cp -fp test/cg/obj/linux/sparc/ctest.o test/cg /bin/cp -fp test/cg/obj/linux/sparc/tcext3.o test/cg /bin/cp: cannot stat `test/cg/obj/linux/sparc/tcext3.o': No such file or directory make: *** [copyfiles] Error 1 That file is supposed to be in svn, but it isn't in fixes. You can download it (along with some others) from http://svn.freepascal.org/svn/fpc/trunk/tests/test/cg/obj/linux/sparc/ Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] GetConnectionDef in the interface section
Michael Van Canneyt wrote: On Sun, 15 Jul 2007, Joao Morais wrote: Hello, It's possible include the following declaration: function GetConnectionDef(ConnectorName: string): TConnectionDef; in the interface section of the sqldb unit and merge to 2.2? Moving it to interface is not a problem. Nice, thanks. Can you upload the change? Merge to 2.2 is another matter. This means no or this means perhaps? If this means no, give me how can I instantiate a SQLConnection from a string, or sqldb isn't flexible enough? Anyway I see your point. Thanks. -- Joao Morais ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Running test suite for 2.1.4 on linux/sparc
Jonas Maebe wrote: /fpcbuild-2.1.4/fpcsrc/compiler/ppcsparc -n -FEsparc-linux -Tlinux popuperr.pp make[1]: Leaving directory `/fpcbuild-2.1.4/fpcsrc/tests/units' /bin/cp -fp test/cg/obj/linux/sparc/ctest.o test/cg /bin/cp -fp test/cg/obj/linux/sparc/tcext3.o test/cg /bin/cp: cannot stat `test/cg/obj/linux/sparc/tcext3.o': No such file or directory make: *** [copyfiles] Error 1 That file is supposed to be in svn, but it isn't in fixes. You can download it (along with some others) from http://svn.freepascal.org/svn/fpc/trunk/tests/test/cg/obj/linux/sparc/ Drat :-) I was assuming that the file was built from source somewhere rather than being a preexisting binary... I should have looked in the sibling directories. Incidentally, something curious here. You might remember that a week ago I was getting stuck on the inconsistent register-assignment nasty, I built and installed an apparently-working 2.1.4 shortly after you pointed out that it tended to be a transiant problem. Odd thing is that since that point I've gone through the entire exercise a second time- 2.0.0 binary compiling 2.0.4 hence compiling 2.1.4, and the 2.1.4 compilation hadn't failed. Work continues here, I'll be back. I /really/ want to get this sorted out. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Running test suite for 2.1.4 on linux/sparc
Jonas Maebe wrote: Incidentally, something curious here. You might remember that a week ago I was getting stuck on the inconsistent register-assignment nasty, I built and installed an apparently-working 2.1.4 shortly after you pointed out that it tended to be a transiant problem. Odd thing is that since that point I've gone through the entire exercise a second time- 2.0.0 binary compiling 2.0.4 hence compiling 2.1.4, and the 2.1.4 compilation hadn't failed. I know, it only happens intermittently (in a way that suggests an uninitialised variable or memory localtion), but have no idea what it's caused by. Valgrind doesn't find anything in an i386 to sparc cross compiler, so it's probably an error somewhere in the sparc code generator (or in a sparc rtl assembler routine) I'm obviously keeping an eye on this, but I'm wondering whether there's a binary (library or executable) that was installed on the system once I had a working 2.1.4, which was not overwritten when I reverted to 2.0.0 or 2.0.4 and subsequently used when I rebuilt 2.1.4. In some ways it will be a relief if it starts coming up with the same fault again :-) Tests still running, more later. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] twide3.pp on windows
From: Jonas Maebe [EMAIL PROTECTED] On 16 Jul 2007, at 16:32, Vincent Snijders wrote: How is the twide3.pp test supposed to work? It assumes that the testsuite environment is configured to use utf8. I don't know how to make it encoding-independent, nor how to configure a Windows console session to always use utf8 (the testsuite scripts of the automated testsuite runs on Linux, Solaris and Mac OS X all explicitly set the LANG environment variable to ensure this). Our Windows RTL use current ansi code page to perform widestring-ansistring conversions. utf8 can not be used. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Please merge SSE detecion fix to fixes_2_2
On 16 Jul 2007, at 18:08, Martin Schreiber wrote: On Monday 16 July 2007 14.05, Jonas Maebe wrote: Independent from this, I would encourage you to submit a bug report against gdb for win32. If they don't know this is broken, they can't fix it. I fear that I am not the right person to report the bug because my knowledge of the debug internals is very limited. :-( You don't need any knowledge of debug internals. Just supply them with an application that crashes gdb/win32 when run under gdb on a non-SSE machine, and which works fine without. And say that even typing handle SIGILL nostop noprint doesn't work either. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] twide3.pp on windows
From: Daniël Mantione [EMAIL PROTECTED] Op Mon, 16 Jul 2007, schreef Yury Sidorov: The code page (locale) is set in Control Panel for whole user session (or whole system). It is not possible to set utf8 as locale. I know. How do you set it to a specific locale for the current application? widestring to ansistring conversion is performed using WideCharToMultiByte. Currently it is done using ANSI code page specified in Control Panel. There is no per application code page setting in Windows. We can create flag in System unit which control how widestring-ansistring should be performed to enable utf8 on Windows. No, you cannot (at least not with full functionality), since uppercasing and compare operations on UTF-8 ansistrings you need a Unicode library, which Windows does only provide in UTF-16 flavour. WideCharToMultiByte can convert from widestring to utf8 if corresponding flag is specified. This flag is available in Windows 98/Me, Windows NT 4.0 and later. MultiByteToWideChar do reverse conversion. This functions already used in System unit for Windows. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] twide3.pp on windows
Op Mon, 16 Jul 2007, schreef Yury Sidorov: From: Daniël Mantione [EMAIL PROTECTED] Op Mon, 16 Jul 2007, schreef Yury Sidorov: The code page (locale) is set in Control Panel for whole user session (or whole system). It is not possible to set utf8 as locale. I know. How do you set it to a specific locale for the current application? widestring to ansistring conversion is performed using WideCharToMultiByte. Currently it is done using ANSI code page specified in Control Panel. There is no per application code page setting in Windows. There must be, because the CRT unit currently seems to do such vodoo (which is questionable behaviour by the way). We can create flag in System unit which control how widestring-ansistring should be performed to enable utf8 on Windows. No, you cannot (at least not with full functionality), since uppercasing and compare operations on UTF-8 ansistrings you need a Unicode library, which Windows does only provide in UTF-16 flavour. WideCharToMultiByte can convert from widestring to utf8 if corresponding flag is specified. This flag is available in Windows 98/Me, Windows NT 4.0 and later. MultiByteToWideChar do reverse conversion. This functions already used in System unit for Windows. Yes, but how would you implement ansiuppercase and friends when utf8 flag is set to true? Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] twide3.pp on windows
Op Mon, 16 Jul 2007, schreef Yury Sidorov: There must be, because the CRT unit currently seems to do such vodoo (which is questionable behaviour by the way). Yes. It is possible to specify code pages for console, gui controls, etc. But application must do it in runtime. Perfect, this is what twide3 needs. Oh, yes it will not work on Windows, because utf8 is not supported here. Then, twide3.pp should be skipped on Windows, since it is not possible to do it in locale independant way. Well, the test could be adapted to use some kind of code page. It could work on all platforms then. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] twide3.pp on windows
From: Daniël Mantione [EMAIL PROTECTED] Op Mon, 16 Jul 2007, schreef Yury Sidorov: There must be, because the CRT unit currently seems to do such vodoo (which is questionable behaviour by the way). Yes. It is possible to specify code pages for console, gui controls, etc. But application must do it in runtime. Perfect, this is what twide3 needs. It is not possible to change code page used for wideansi translation per applicaton. Oh, yes it will not work on Windows, because utf8 is not supported here. Then, twide3.pp should be skipped on Windows, since it is not possible to do it in locale independant way. Well, the test could be adapted to use some kind of code page. It could work on all platforms then. This test will work on Windows only if utf8 support will be added to Windows rtl. Yury. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] twide3.pp on windows
Yury Sidorov schreef: From: Daniël Mantione [EMAIL PROTECTED] Op Mon, 16 Jul 2007, schreef Yury Sidorov: There must be, because the CRT unit currently seems to do such vodoo (which is questionable behaviour by the way). Yes. It is possible to specify code pages for console, gui controls, etc. But application must do it in runtime. Perfect, this is what twide3 needs. It is not possible to change code page used for wideansi translation per applicaton. Oh, yes it will not work on Windows, because utf8 is not supported here. Then, twide3.pp should be skipped on Windows, since it is not possible to do it in locale independant way. Well, the test could be adapted to use some kind of code page. It could work on all platforms then. This test will work on Windows only if utf8 support will be added to Windows rtl. I changed my windows settings to Polish and it now uses codepage 1250 (before it was 1252), now it runs successfully. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] twide3.pp on windows
Vincent Snijders пишет: Yury Sidorov schreef: From: Daniël Mantione [EMAIL PROTECTED] Op Mon, 16 Jul 2007, schreef Yury Sidorov: There must be, because the CRT unit currently seems to do such vodoo (which is questionable behaviour by the way). snip I changed my windows settings to Polish and it now uses codepage 1250 (before it was 1252), now it runs successfully. I think the hack from CRT unit can be useful here too. Just do: OldConsoleOutputCP:=GetConsoleOutputCP; SetConsoleOutputCP(1250); at the beginning of test and SetConsoleOutputCP(OldConsoleOutputCP); at the end. OldConsoleOutputCP is of type Word. -- Best regards, Maxim Ganetsky mailto:[EMAIL PROTECTED] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] twide3.pp on windows
Maxim Ganetsky schreef: Vincent Snijders пишет: Yury Sidorov schreef: From: Daniël Mantione [EMAIL PROTECTED] Op Mon, 16 Jul 2007, schreef Yury Sidorov: There must be, because the CRT unit currently seems to do such vodoo (which is questionable behaviour by the way). snip I changed my windows settings to Polish and it now uses codepage 1250 (before it was 1252), now it runs successfully. I think the hack from CRT unit can be useful here too. Just do: OldConsoleOutputCP:=GetConsoleOutputCP; SetConsoleOutputCP(1250); No, this does not work. GetACP still returns the system setting. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] twide3.pp on windows
Vincent Snijders пишет: Maxim Ganetsky schreef: Vincent Snijders пишет: Yury Sidorov schreef: From: Daniël Mantione [EMAIL PROTECTED] Op Mon, 16 Jul 2007, schreef Yury Sidorov: There must be, because the CRT unit currently seems to do such vodoo (which is questionable behaviour by the way). snip I changed my windows settings to Polish and it now uses codepage 1250 (before it was 1252), now it runs successfully. I think the hack from CRT unit can be useful here too. Just do: OldConsoleOutputCP:=GetConsoleOutputCP; SetConsoleOutputCP(1250); No, this does not work. GetACP still returns the system setting. Where do you see GetACP? Instead of GetACP pass 1250. -- Best regards, Maxim Ganetsky mailto:[EMAIL PROTECTED] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] twide3.pp on windows
Maxim Ganetsky schreef: Vincent Snijders пишет: No, this does not work. GetACP still returns the system setting. Where do you see GetACP? Instead of GetACP pass 1250. I don't see, it is what is used by WideCharToMultiByte(CP_ACP, 0, source, len+1, nil, 0, nil, nil); in Win32Wide2AnsiMove. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Running test suite for 2.1.4 on linux/sparc
Mark Morgan Lloyd wrote: Tests still running, more later. OK, I think it's stuck. It's been sitting here for the last few hours: utils/dotest -c/fpcbuild-2.1.4/fpcsrc/compiler/ppcsparc -e test/tmmx1.pp Abort: Compiler cpu sparc is not in list i386 utils/dotest -c/fpcbuild-2.1.4/fpcsrc/compiler/ppcsparc -e test/tmove.pp utils/dotest -c/fpcbuild-2.1.4/fpcsrc/compiler/ppcsparc -e test/tmt1.pp tmt1.pp doesn't look like it should take /that/ lomg to run, even on a 450MHz system. Noting seems to be taking an inordinate amount of CPU or memory, but I've got about 99 tmt1 processes running all started 7 hours ago... is that right? Ah- the kernel buffer is full of Kernel unaligned access messages. What I can't say is whether this is the result of testing or because of something that was being done on this machine a few minutes ago, however this is suspiciously similar to the fault I was getting in Lazarus. I'll leave the system in its current state if I can in case there's anything worth checking. Any hints appreciated :-) -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] twide3.pp on windows
Vincent Snijders пишет: Maxim Ganetsky schreef: Vincent Snijders пишет: No, this does not work. GetACP still returns the system setting. Where do you see GetACP? Instead of GetACP pass 1250. I don't see, it is what is used by WideCharToMultiByte(CP_ACP, 0, source, len+1, nil, 0, nil, nil); in Win32Wide2AnsiMove. Ah, now I see. Having looked at the code of the test I think that of course my suggestion won't work since it changes console codepage and the test doesn't work with it. -- Best regards, Maxim Ganetsky mailto:[EMAIL PROTECTED] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
