Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

On 2016-05-11 21:58, Mattias Gaertner wrote: >> > They made the changes to take advantage of the new >> > functionality in FPC 3.0, because the end result is much simpler code >> > both in the LCL and in user programs. > > Yes, simpler and more powerful. For example FPC now supports full UTF-8 >

Re: [fpc-pascal] Smart Pointers

On 11.05.2016 22:23, Florian Klämpfl wrote: > Am 11.05.2016 um 14:12 schrieb Maciej Izak: >> 2016-05-11 13:46 GMT+02:00 Michael Van Canneyt > >: >> >> Anything the compiler needs *must* be in the system unit. The compiler >> should

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

On Wed, 11 May 2016 22:33:13 +0200 Jonas Maebe wrote: > Graeme Geldenhuys wrote: > > On 2016-05-11 18:58, Michael Van Canneyt wrote: > >> > For 99,99% of cases, no changes to your code are required. > >> > If it worked in 2.6.4, it will work in 3.0.0 > > > > Just

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

On Wed, May 11, 2016 22:08, Graeme Geldenhuys wrote: > On 2016-05-11 18:58, Michael Van Canneyt wrote: >> For 99,99% of cases, no changes to your code are required. >> If it worked in 2.6.4, it will work in 3.0.0 > > Just curious, so why was there so many changes required for LCL, and a > whole

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

Graeme Geldenhuys wrote: On 2016-05-11 18:58, Michael Van Canneyt wrote: > For 99,99% of cases, no changes to your code are required. > If it worked in 2.6.4, it will work in 3.0.0 Just curious, so why was there so many changes required for LCL, and a whole wiki page of its own to explain

Re: [fpc-pascal] Smart Pointers

Am 11.05.2016 um 14:12 schrieb Maciej Izak: > 2016-05-11 13:46 GMT+02:00 Michael Van Canneyt >: > > Anything the compiler needs *must* be in the system unit. The compiler > should only assume the system unit, possibly objpas or

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

On 2016-05-11 18:58, Michael Van Canneyt wrote: > For 99,99% of cases, no changes to your code are required. > If it worked in 2.6.4, it will work in 3.0.0 Just curious, so why was there so many changes required for LCL, and a whole wiki page of its own to explain it? Regards, Graeme --

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

Am 11.05.2016 19:35 schrieb "Santiago A." : > Something about codpages needs a second thought. > > a) There shouldn't be automatic conversion at all. > b) The codepage of a string shouldn't change when you assign a string with another codepage, just rise an error. > c)

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

On Wed, 11 May 2016, Santiago A. wrote: El 11/05/2016 a las 16:38, Michael Van Canneyt escribió: FPC 3.0 adds unsafe auto-conversions Why do you think it is unsafe ? I have an answer for this. In short: Different codepage strings and raw strings should be considered different

Re: [fpc-pascal] Smart Pointers

2016-05-11 15:07 GMT+02:00 Maciej Izak : > > 2016-05-11 14:51 GMT+02:00 Sven Barth : > >> And I stand by that decision. Generics are a rather frickle feature and I >> want to know of critical failures as early as possible (and yes, I've made >> use

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

El 11/05/2016 a las 16:38, Michael Van Canneyt escribió: > >> FPC 3.0 adds unsafe auto-conversions > > Why do you think it is unsafe ? > I have an answer for this. In short: Different codepage strings and raw strings should be considered different incompatible types. Pascal is a hardtyped

Re: [fpc-pascal] Summary of Unicode Strings Debate

2016-05-11 11:44 GMT-03:00 Michael Van Canneyt : > > > On Wed, 11 May 2016, Mazo Winst wrote: > > Hello, >> >> A summary of what i learned from the Unicode String debate: >> >> 1 - FPC 3 introduces code page aware strings >> >> 2 - FPC 3 updates the RTL to provide a better

Re: [fpc-pascal] Summary of Unicode Strings Debate

Michael Van Canneyt wrote on Wed, 11 May 2016: On Wed, 11 May 2016, Mazo Winst wrote: 3 - The dynamic behavior of the string type regarding to the platform was not introduced by FPC 3. In the previous versions of FPC, the string type depends on the platform too. The string type does not

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

Andreas Dorn wrote on Wed, 11 May 2016: All in all Graeme is right. FPC looks pretty much broken to me, too. For my projects I pulled the emergency-break on anything FPC.   The most serious flaws for me of FPC 3.0 are: - assuming that it's possible to assign an encoding to every string - using

Re: [fpc-pascal] Summary of Unicode Strings Debate

On Wed, 11 May 2016, Mazo Winst wrote: Hello, A summary of what i learned from the Unicode String debate: 1 - FPC 3 introduces code page aware strings 2 - FPC 3 updates the RTL to provide a better support for code page aware strings 3 - The dynamic behavior of the string type regarding to

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

On Wed, 11 May 2016, Andreas Dorn wrote: All in all Graeme is right. FPC looks pretty much broken to me, too. For my projects I pulled the emergency-break on anything FPC.   The most serious flaws for me of FPC 3.0 are: - assuming that it's possible to assign an encoding to every string -

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

All in all Graeme is right. FPC looks pretty much broken to me, too. For my projects I pulled the emergency-break on anything FPC.   The most serious flaws for me of FPC 3.0 are: - assuming that it's possible to assign an encoding to every string - using an (unsafe) guess about the encoding

Re: [fpc-pascal] Executing external processes and codepages

In our previous episode, Michael Van Canneyt said: > I honestly don't understand this argument: in 99,99% of all cases, the code > will just > work if you use RawByteString, since everything will be in the codepage of > the environment anyway ? Well, we already convert to target encoding on

[fpc-pascal] Summary of Unicode Strings Debate

Hello, A summary of what i learned from the Unicode String debate: 1 - FPC 3 introduces code page aware strings 2 - FPC 3 updates the RTL to provide a better support for code page aware strings 3 - The dynamic behavior of the string type regarding to the platform was not introduced by FPC 3.

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

Graeme Geldenhuys wrote on Wed, 11 May 2016: My test program under FPC 2.6.4 doesn't give problems. It's when that same program is compiled under FPC 3.0.0 that it does. All due to String (and thus AnsiString) changing its encoding based on the running environment. In FPC 2.6.x, if you use a

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

On Wed, 11 May 2016, Jonas Maebe wrote: Michael Van Canneyt wrote on Wed, 11 May 2016: On Wed, 11 May 2016, Graeme Geldenhuys wrote: If anybody has the time, I would really like to learn how. Using FPC 3.x. Running the example program in a Latin-1 [console] environment and still get the

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

On 2016-05-11 14:14, Jonas Maebe wrote: > compared to FPC 2.6.x due to automatic conversions in the RTL and FCL. > When it is clear that is not true, you are now saying that the > behaviour of FPC 3.0 is different to FPC 2.6.x if you compile > different code with each one. My test program

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

Michael Van Canneyt wrote on Wed, 11 May 2016: On Wed, 11 May 2016, Graeme Geldenhuys wrote: If anybody has the time, I would really like to learn how. Using FPC 3.x. Running the example program in a Latin-1 [console] environment and still get the correct data stored in the output.data file.

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

Graeme Geldenhuys wrote on Wed, 11 May 2016: On 2016-05-11 13:27, Jonas Maebe wrote: If you change the string to unicodestring (since FPC 2.6.4 does not know {$modeswitch unicodestring}), you should get the same results in FPC 2.6.4 and FPC 3.x No, because FPC 2.6.4 doesn't do automatic

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

On Wed, 11 May 2016, Graeme Geldenhuys wrote: On 2016-05-11 13:37, Michael Van Canneyt wrote: It would not help if we did this: the data would be wrong in the TDataset buffers, and the result would be worse. I didn't mean literally search and replace - that would simply be too easy. ;-)

Re: [fpc-pascal] Smart Pointers

On Wed, 11 May 2016, Sven Barth wrote: Am 11.05.2016 14:42 schrieb "Maciej Izak" : 2016-05-11 14:23 GMT+02:00 Michael Van Canneyt : Where is that written ? As far as I know, it is only there because classes is there, and classes has some

Re: [fpc-pascal] Smart Pointers

2016-05-11 14:51 GMT+02:00 Sven Barth : > And I stand by that decision. Generics are a rather frickle feature and I > want to know of critical failures as early as possible (and yes, I've made > use of that already numerous times!), thus I prefer fgl to be part of the

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

On 2016-05-11 13:27, Jonas Maebe wrote: > If you change the string to unicodestring (since > FPC 2.6.4 does not know {$modeswitch unicodestring}), you should get > the same results in FPC 2.6.4 and FPC 3.x No, because FPC 2.6.4 doesn't do automatic encoding conversions. I would first have to

Re: [fpc-pascal] Smart Pointers

Am 11.05.2016 14:42 schrieb "Maciej Izak" : > > 2016-05-11 14:23 GMT+02:00 Michael Van Canneyt : >> >> Where is that written ? As far as I know, it is only there because classes >> is there, and classes has some define to allow it to be compiled with

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

On 2016-05-11 13:37, Michael Van Canneyt wrote: > > It would not help if we did this: the data would be wrong in the TDataset > buffers, and the result would be worse. I didn't mean literally search and replace - that would simply be too easy. ;-) Some work and testing would be required,

Re: [fpc-pascal] Smart Pointers

On Wed, 11 May 2016, Maciej Izak wrote: 2016-05-11 14:23 GMT+02:00 Michael Van Canneyt : Where is that written ? As far as I know, it is only there because classes is there, and classes has some define to allow it to be compiled with fgl. by Sven (29 January 2016

Re: [fpc-pascal] Smart Pointers

2016-05-11 14:23 GMT+02:00 Michael Van Canneyt : > Where is that written ? As far as I know, it is only there because classes > is there, and classes has some define to allow it to be compiled with fgl. > > by Sven (29 January 2016 10:54 thread "Generics.Collections as

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

On 2016-05-11 12:03, Graeme Geldenhuys wrote: > I wrote a small > test program that reads data from a Firebird database where the database > and field charset is set to UTF8. For those that want to try the sample application, a backup of the database (3.7MB in size) can be found at:

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

On Wed, 11 May 2016, Graeme Geldenhuys wrote: On 2016-05-11 13:07, Michael Van Canneyt wrote: But what does your program prove ? See below... You're only proving that a conversion happens when you do s := fieldByName('somefield').asString; I'm proving that using the String type

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

That's because you have {$modeswitch unicodestring}, so string=unicodestring. This is answer to my question :-) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

I just double checked my results again. With u: String variable and compiled with FPC 3.0 and running in a Latin-1 environment, data is completely corrupted. It will be good to know where this happens. Because AFAIK fcl-db internaly uses AnsiString/String so assigning between them should

Re: [fpc-pascal] Smart Pointers

In our previous episode, Michael Van Canneyt said: > > For example fgl module is part of RTL just because is usefully > > for Sven for testing purposes (! that is curious). > > Where is that written ? As far as I know, it is only there because classes > is there, and classes has some define to

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

Graeme Geldenhuys wrote on Wed, 11 May 2016: On 2016-05-11 13:05, Jonas Maebe wrote: Your concern is with utf8string, not with string/ansistring. UTF8String is a AnsiString with utf-8 code page set. If you only use string/ansistring/unicodestring, then the behaviour of your program will be

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

On 2016-05-11 13:07, Michael Van Canneyt wrote: > > But what does your program prove ? See below... > You're only proving that a conversion happens when you do > s := fieldByName('somefield').asString; I'm proving that using the String type anywhere in the RTL and FCL is now terrible. If the

Re: [fpc-pascal] Smart Pointers

On Wed, 11 May 2016, Maciej Izak wrote: 2016-05-11 13:46 GMT+02:00 Michael Van Canneyt : Anything the compiler needs *must* be in the system unit. The compiler should only assume the system unit, possibly objpas or macpas or so. All the rest should remain out of the

Re: [fpc-pascal] Executing external processes and codepages

On Wed, 11 May 2016, Marco van de Voort wrote: In our previous episode, Michael Van Canneyt said: I don't like that. The 3.x idea is to get rid of manual conversions and hack-and-convert-it-as-you-go encoding management, not just rebadge the old practices to rawbytestring. You may not

Re: [fpc-pascal] Smart Pointers

In our previous episode, Maciej Izak said: > > Some rtl-objpas units use classes, like fmtbcd. > > > > If you don't use fcl-base I would make it RTL, so we can use it in fcl-base > > if needed :-) > > > Library is low level without using anything outside RTL, IMO it should be > part of RTL like

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

On 2016-05-11 13:05, Jonas Maebe wrote: > > Your concern is with utf8string, not with string/ansistring. UTF8String is a AnsiString with utf-8 code page set. If you > only use string/ansistring/unicodestring, then the behaviour of your > program will be identical with FPC 2.6.4 and 3.0. With

Re: [fpc-pascal] Smart Pointers

2016-05-11 13:46 GMT+02:00 Michael Van Canneyt : > Anything the compiler needs *must* be in the system unit. The compiler > should only assume the system unit, possibly objpas or macpas or so. > > All the rest should remain out of the RTL, which should be as small as >

Re: [fpc-pascal] Executing external processes and codepages

In our previous episode, Michael Van Canneyt said: > > > > I don't like that. The 3.x idea is to get rid of manual conversions and > > hack-and-convert-it-as-you-go encoding management, not just rebadge the old > > practices to rawbytestring. > > You may not like it, but there is simply no other

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

On Wed, 11 May 2016, Graeme Geldenhuys wrote: Hi, Here is an example [proof if you will] of the problem. I wrote a small test program that reads data from a Firebird database where the database and field charset is set to UTF8. I compile the program, then run it. No recompiles between the

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

On 2016-05-11 12:03, Graeme Geldenhuys wrote: > Console output: > > [unicode_test]$ export LANG=en_US.UTF-8 > [unicode_test]$ ./unicodetest > 65001 > > [unicode_test]$ export LANG=en_US.ISO8859-1 > [unicode_test]$ ./unicodetest > 28591 Just to add, compiling that test program with FPC 2.6.4 I

Re: [fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

Graeme Geldenhuys wrote on Wed, 11 May 2016: I'm honestly trying very hard to understand the string changes implemented in FPC 3.x, and the best way to use it going forward. In this example I tried everything I learned from the recent mailing list discussions. My concern with the usage of

[fpc-pascal] code example where AnsiString used in FCL (SqlDB) causes data loss

Hi, Here is an example [proof if you will] of the problem. I wrote a small test program that reads data from a Firebird database where the database and field charset is set to UTF8. I compile the program, then run it. No recompiles between the two runs. The first run my system is set to have a

Re: [fpc-pascal] Executing external processes and codepages

Michael Van Canneyt wrote on Wed, 11 May 2016: On Wed, 11 May 2016, Jonas Maebe wrote: Michael Van Canneyt wrote on Wed, 11 May 2016: On Wed, 11 May 2016, Jonas Maebe wrote: Michael Van Canneyt wrote on Wed, 11 May 2016: And in the case it makes an assumption of the code page,

Re: [fpc-pascal] RTL and Unicode Strings

On 2016-05-11 12:48, Michael Van Canneyt wrote: > No, it does not save you, where did you get that from ? It helps. Any encoding to UTF-16 (or UTF-8) is safe. The other way round is not. There is no guarantee that String (or AnsiString) is using a Unicode encoding. So depending on where you get

Re: [fpc-pascal] RTL and Unicode Strings

On Wed, 11 May 2016, Graeme Geldenhuys wrote: On 2016-05-11 10:48, Michael Van Canneyt wrote: Honestly, I don't understand this preoccupation with {$modeswitch unicodestrings} It just means that Var a : string; is read by the compiler as Var a : unicodestring; No more, no less.

Re: [fpc-pascal] Smart Pointers

On Wed, 11 May 2016, Maciej Izak wrote: 2016-05-11 10:22 GMT+02:00 Marco van de Voort : Some rtl-objpas units use classes, like fmtbcd. If you don't use fcl-base I would make it RTL, so we can use it in fcl-base if needed :-) Library is low level without using anything

Re: [fpc-pascal] Executing external processes and codepages

On Wed, 11 May 2016, Jonas Maebe wrote: Michael Van Canneyt wrote on Wed, 11 May 2016: On Wed, 11 May 2016, Jonas Maebe wrote: Michael Van Canneyt wrote on Wed, 11 May 2016: And in the case it makes an assumption of the code page, regardless of environment variables ? (don't say that

Re: [fpc-pascal] Executing external processes and codepages

Michael Van Canneyt wrote on Wed, 11 May 2016: On Wed, 11 May 2016, Jonas Maebe wrote: Michael Van Canneyt wrote on Wed, 11 May 2016: And in the case it makes an assumption of the code page, regardless of environment variables ? (don't say that doesn't happen. It does, I know a

Re: [fpc-pascal] Executing external processes and codepages

On Wed, 11 May 2016, Jonas Maebe wrote: Michael Van Canneyt wrote on Wed, 11 May 2016: On Wed, 11 May 2016, Jonas Maebe wrote: Michael Van Canneyt wrote on Wed, 11 May 2016: On Wed, 11 May 2016, Marco van de Voort wrote: I don't like that. The 3.x idea is to get rid of manual

Re: [fpc-pascal] RTL and Unicode Strings

On 2016-05-11 10:43, Marco van de Voort wrote: >> The problem as I see it, is that I already lost data when SqlDB >> converted it to Latin-1. Am I not understanding the problem? > > It depends. Sqldb assigned non ansistring data to an ansistring. In the old > (2.6.4, old delphi) logic it would

Re: [fpc-pascal] Smart Pointers

2016-05-11 10:22 GMT+02:00 Marco van de Voort : > Some rtl-objpas units use classes, like fmtbcd. > > If you don't use fcl-base I would make it RTL, so we can use it in fcl-base > if needed :-) Library is low level without using anything outside RTL, IMO it should be part of

Re: [fpc-pascal] Executing external processes and codepages

Michael Van Canneyt wrote on Wed, 11 May 2016: On Wed, 11 May 2016, Jonas Maebe wrote: Michael Van Canneyt wrote on Wed, 11 May 2016: On Wed, 11 May 2016, Marco van de Voort wrote: I don't like that. The 3.x idea is to get rid of manual conversions and hack-and-convert-it-as-you-go

Re: [fpc-pascal] fpc/lazarus and kinect sample

On 2016-05-11 10:12, Michael Van Canneyt wrote: > > No worries. I will send it to you, if I can still find it :-) > > Michael. Thanks, I'd really appreciate that -- Björn ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org

Re: [fpc-pascal] RTL and Unicode Strings

On 2016-05-11 10:48, Michael Van Canneyt wrote: > Honestly, I don't understand this preoccupation with {$modeswitch > unicodestrings} > > It just means that > > Var > a : string; > > is read by the compiler as > > Var > a : unicodestring; > > No more, no less. It saves you from data

Re: [fpc-pascal] Executing external processes and codepages

On Wed, 11 May 2016, Jonas Maebe wrote: Michael Van Canneyt wrote on Wed, 11 May 2016: On Wed, 11 May 2016, Marco van de Voort wrote: I don't like that. The 3.x idea is to get rid of manual conversions and hack-and-convert-it-as-you-go encoding management, not just rebadge the old

Re: [fpc-pascal] Executing external processes and codepages

Michael Van Canneyt wrote on Wed, 11 May 2016: On Wed, 11 May 2016, Marco van de Voort wrote: I don't like that. The 3.x idea is to get rid of manual conversions and hack-and-convert-it-as-you-go encoding management, not just rebadge the old practices to rawbytestring. You may not like it,

Re: [fpc-pascal] Executing external processes and codepages

On Wed, 11 May 2016, Marco van de Voort wrote: In our previous episode, Michael Van Canneyt said: I'm not sure what you are suggesting as alternative. Saving the encoding at startup, so it can be reused in cases like this, in case somebody change defaultsystemcodepage? Or using

Re: [fpc-pascal] RTL and Unicode Strings

On Wed, 11 May 2016, Jonas Maebe wrote: Graeme Geldenhuys wrote on Wed, 11 May 2016: In my application I enable unicodestring mode. So I'm reading data from a Firebird database. The data is stored as UTF-8 in a VarChar field. The DB connection is set up as UTF-8. Now lets assume my

Re: [fpc-pascal] RTL and Unicode Strings

In other cases, like LacaK said, you will have to read the data as plain bytes into e.g. a RawByteString and next use http://www.freepascal.org/docs-html/rtl/system/setcodepage.html (with the last parameter set to "false") to afterwards specify the code page this data has. But this is where

Re: [fpc-pascal] Executing external processes and codepages

In our previous episode, Michael Van Canneyt said: > > I'm not sure what you are suggesting as alternative. Saving the encoding at > > startup, so it can be reused in cases like this, in case somebody change > > defaultsystemcodepage? > > > > Or using defaultsystemcodepage instead of filesystem

Re: [fpc-pascal] RTL and Unicode Strings

In our previous episode, Graeme Geldenhuys said: > > In other cases, like LacaK said, you will have to read the data as plain > > bytes into e.g. a RawByteString and next use > > http://www.freepascal.org/docs-html/rtl/system/setcodepage.html (with > > the last parameter set to "false") to

Re: [fpc-pascal] RTL and Unicode Strings

On 11/05/16 10:18, Graeme Geldenhuys wrote: In my application I enable unicodestring mode. So I'm reading data from a Firebird database. The data is stored as UTF-8 in a VarChar field. The DB connection is set up as UTF-8. Now lets assume my FreeBSD box is set up with a default encoding of

Re: [fpc-pascal] RTL and Unicode Strings

Graeme Geldenhuys wrote on Wed, 11 May 2016: In my application I enable unicodestring mode. So I'm reading data from a Firebird database. The data is stored as UTF-8 in a VarChar field. The DB connection is set up as UTF-8. Now lets assume my FreeBSD box is set up with a default encoding of

Re: [fpc-pascal] Executing external processes and codepages

On Wed, 11 May 2016, Marco van de Voort wrote: In our previous episode, Jonas Maebe said: It assumes for windows utf16, and for Unix filesystem encoding (e.g. unix.pp:254). If you have more info, please share. The filesystem encoding is fine to find the binary on Unix, but the parameters

Re: [fpc-pascal] Invoking methods through rtti

Am 11.05.2016 10:22 schrieb "Michael Schnell" : > > On 05/09/2016 05:36 PM, Sven Barth wrote: >> >> >> As long as you know the signature of the method you can cast the pointer to the method to an approbiate method variable and call that. For dynamic calls you'll need to wait

Re: [fpc-pascal] {$modeswitch unicodestring}

On 2016-05-11 10:06, Jonas Maebe wrote: > Indeed, just like any other {$mode xxx} and {$modeswitch xxx} > directive. Thank you. That’s what I thought. I just wanted to double check. Regards, Graeme ___ fpc-pascal maillist -

Re: [fpc-pascal] Executing external processes and codepages

In our previous episode, Jonas Maebe said: > > > > It assumes for windows utf16, and for Unix filesystem encoding (e.g. > > unix.pp:254). > > > > If you have more info, please share. > > The filesystem encoding is fine to find the binary on Unix, but the > parameters you specify to that binary

[fpc-pascal] Executing external processes and codepages

marcov wrote on Tue, 10 May 2016: In our previous episode, Jonas Maebe said: > ExecuteProcess is in trunk since late march. > > It is fairly self contained and could be merged to 3.0.2 technically. I mentioned that it is in trunk, but it's incomplete: it does not translate the command line

Re: [fpc-pascal] RTL and Unicode Strings

On 2016-05-11 09:21, Jonas Maebe wrote: > In other cases, like LacaK said, you will have to read the data as plain > bytes into e.g. a RawByteString and next use > http://www.freepascal.org/docs-html/rtl/system/setcodepage.html (with > the last parameter set to "false") to afterwards specify

Re: [fpc-pascal] The world is ending

On Tue, 10 May 2016, Michael Schnell wrote: On 05/09/2016 09:34 PM, Jonas Maebe wrote: While still missing in the documentation, you can already do that with {$modeswitch unicodestrings}. If this avoids the issues, Graeme found, why is this not enabled as default, as well in the user code

Re: [fpc-pascal] {$modeswitch unicodestring}

Graeme Geldenhuys wrote on Wed, 11 May 2016: On 2016-05-11 09:58, Jonas Maebe wrote: It does not avoid "the issues". All that modeswitch does is make "String" an alias for "Unicodestring" in the declaring module. Am I correct in understanding that it only affects individual units. So using

Re: [fpc-pascal] {$modeswitch unicodestring}

On 2016-05-11 09:58, Jonas Maebe wrote: > It does not avoid "the issues". All that modeswitch does is make > "String" an alias for "Unicodestring" in the declaring module. Am I correct in understanding that it only affects individual units. So using it in my application, it would not affect the

[fpc-pascal] {$modeswitch unicodestring} (was: Re: The world is ending)

Michael Schnell wrote on Tue, 10 May 2016: On 05/09/2016 09:34 PM, Jonas Maebe wrote: While still missing in the documentation, you can already do that with {$modeswitch unicodestrings}. If this avoids the issues, It does not avoid "the issues". All that modeswitch does is make

Re: [fpc-pascal] Smart Pointers

In our previous episode, Florian Kl?mpfl said: > > whatever... > > If it depends on classes: fcl-generic, else RTL-generic. Some rtl-objpas units use classes, like fmtbcd. If you don't use fcl-base I would make it RTL, so we can use it in fcl-base if needed :-)

Re: [fpc-pascal] The world is ending

On 05/09/2016 09:34 PM, Jonas Maebe wrote: While still missing in the documentation, you can already do that with {$modeswitch unicodestrings}. If this avoids the issues, Graeme found, why is this not enabled as default, as well in the user code as in the RTL interface ? -Michael

Re: [fpc-pascal] Invoking methods through rtti

On 05/09/2016 05:36 PM, Sven Barth wrote: As long as you know the signature of the method you can cast the pointer to the method to an approbiate method variable and call that. For dynamic calls you'll need to wait for Invoke() support which is on the ToDo list, but there's no ETA yet.

Re: [fpc-pascal] RTL and Unicode Strings

Mazo Winst wrote: Suppose that my app needs to read a file encoded with UTF-8. Suppose that my app runs on Windows, where the system codepage is most likely to be Windows ANSI. As RTL will use the system codepage, Windows ANSI doesn't support the full range of unicode chars and need to use RTL

Re: [fpc-pascal] fpc/lazarus and kinect sample

On Wed, 11 May 2016, Björn Lundin wrote: On 2016-05-10 23:41, wkitt...@windstream.net wrote: On 05/10/2016 04:33 PM, Björn Lundin wrote: I found the nice article "Programming the Microsoft Kinect in Pascal" by Michaël Van Canneyt, in Blaise Pascal Magazine. (Nr 5 / 2013) However, I wonder

Re: [fpc-pascal] RTL and Unicode Strings

How the sqldb package handles this point? sqlDB does not perform any character translation. Only stores data in record buffers as they arrive. So it expects, that programmer is aware of that and sets correct "connection encoding". In case of Lazarus it is often UTF-8, because Lazarus

Re: [fpc-pascal] Warning not to use the "String" type with FPC 3.x

Mark Morgan Lloyd wrote: Graeme Geldenhuys wrote: On 2016-05-09 17:40, Mark Morgan Lloyd wrote:> What, /exactly/, are So which of these are you complaining about: a) AnsiString doesn't support codepoints > 0xff ? b) AnsiString doesn't support codepoints > 0x7f ? c) AnsiString might apply

Re: [fpc-pascal] fpc/lazarus and kinect sample

On 2016-05-10 23:41, wkitt...@windstream.net wrote: > On 05/10/2016 04:33 PM, Björn Lundin wrote: >> I found the nice article "Programming the Microsoft Kinect in Pascal" by >> Michaël Van Canneyt, in Blaise Pascal Magazine. (Nr 5 / 2013) >> >> However, I wonder if anyone have seen the sample code