On Thursday, 13. January 2011 18.57:00 Hans-Peter Diettrich wrote:
>
> The implementation can choose any model. Different models can be
> implemented as well, so that the final decision about the new standard
> can be delayed, until the models can be tested in real world applications.
>
> One model
On 13-1-2011 21:40, Sven Barth wrote:
WideString on Windows has no reference counting, thus everytime a
WideString is assigned it needs to be copied.
Not exactly true. widestring is com marshaled and thus has reference
counting on the com level. afaik .
As long as your memorymanager is com mar
On 13.01.2011 02:20, Hans-Peter Diettrich wrote:
LacaK schrieb:
3. C style comments: /* ... */ (I have never understood why in Pascal
was used (* ... *) )
Pascal has several digraphs:
(* = {
*) = }
(. = [
.) = ]
I must say, that I have not yet known about the alternatives for the
squared b
On 13.01.2011 18:57, Hans-Peter Diettrich wrote:
Widestring will also grind the application to a halt due to being COM
based
on Windows.
How that?
WideString on Windows has no reference counting, thus everytime a
WideString is assigned it needs to be copied.
When system encoding changes
On 12.01.2011 22:40, Marco van de Voort wrote:
In our previous episode, Sven Barth said:
legacy code can be broken by (eventually) required changes to "set of
char", sizeof(char) and PChar, sizeof(string) as opposed to
Length(string), upper/lower conversion, and many more not so obvious
conseque
Marco van de Voort schrieb:
In our previous episode, Hans-Peter Diettrich said:
"non-native" strings, it can also be a performance win).
IMO a single encoding, i.e. UTF-8, can cover all cases.
Well, for starters, it doesn't cover the existing Delphi/unicode codebase.
Because it's bound to UTF-
Hello FPC,
Thursday, January 13, 2011, 4:24:31 PM, you wrote:
>> Are you aware about the Firebird Field(UTF8) and SQLConnection
>> CharSet(UTF8) problem ?
JvdS> See my mail to Lacak about the two options to solve this.
I think the problem is different and can be solved without any
compatibility
On Thu, 2011-01-13 at 15:55 +0100, José Mejuto wrote:
> Hello FPC,
>
> Thursday, January 13, 2011, 2:58:30 PM, you wrote:
>
> JvdS> Then that option has to be added. I think it's already possible but you
> JvdS> simply don't know how. (Sql-Server is ODBC only, so that one is fixed.
> JvdS> For fi
Hello FPC,
Thursday, January 13, 2011, 2:58:30 PM, you wrote:
JvdS> Then that option has to be added. I think it's already possible but you
JvdS> simply don't know how. (Sql-Server is ODBC only, so that one is fixed.
JvdS> For firebird there's a 'serverencoding' parameter, or something like
JvdS>
On 13/01/2011 14:14, Joost van der Sluis wrote:
>> TCmdLineDebugger.SendCmdLn "-data-evaluate-expression
^^shortstring(^POINTER($eax)^+12)^^"
<< TCmdLineDebugger.ReadLn "^done,value="#0""
<< TCmdLineDebugger.ReadLn "(gdb) "
You do realize that this is an hack? (I partly wrote it)
It cou
On Thu, 2011-01-13 at 11:00 +, Martin wrote:
> On 13/01/2011 07:45, Joost van der Sluis wrote:
> >
> >> >> TCmdLineDebugger.SendCmdLn "-data-evaluate-expression
> >> ^^shortstring(^POINTER($eax)^+12)^^"
> >> << TCmdLineDebugger.ReadLn "^done,value="#0""
> >> << TCmdLineDebugger.ReadLn "(gd
On Thu, 2011-01-13 at 10:32 +0100, José Mejuto wrote:
> Hello FPC,
>
> Thursday, January 13, 2011, 10:03:02 AM, you wrote:
>
> >> ODBC 3.5 was launched around 2000-2001.
> L> But this approach will require changes in packages/odbc/src/odbcsql.inc
> L> like, does not ?:
> L> -pointer(SQLGetDat
On Thu, 2011-01-13 at 09:49 +0100, LacaK wrote:
> So IMHO there must be:
> 1. allocated space in record buffer in size 4*TFieldDef.Size+1
> 2. redefine meaning of Size property (as number of bytes not
> characters) and create fielddefs with Size*4
Yes, those are the possible solutions. Good thi
On Thu, 2011-01-13 at 09:15 +0100, LacaK wrote:
>
> > Didn't I explain this to you and others a few times?
> >
> ;-) If so, then please excuse me
>
> > The database-components itself are encoding-agnostic. This means:
> > encoding in = encoding out.
> >
> > So it is up to the developer what c
Hello FPC,
Thursday, January 13, 2011, 1:01:57 PM, you wrote:
L> Also it seems to me, that when you call ANSI version of ODBC API
L> functions, then you receive data in ANSI encoding.
L> If it is so, then it is always safe use ansitoutf8() (or UTF8Encode())
L> on receved data.
No, because ANSI i
Most probably it needs a "flag" to indicate that the ODBC must work in
Unicode, and then dynamic link to *W functions if this flag is set. I
think ODBC drivers since 2002+/- should have this set of APIs, but I
had never used ODBC in my life... :)
It seems, that Driver Manager automaticaly per
On 13/01/2011 07:45, Joost van der Sluis wrote:
>> TCmdLineDebugger.SendCmdLn "-data-evaluate-expression
^^shortstring(^POINTER($eax)^+12)^^"
<< TCmdLineDebugger.ReadLn "^done,value="#0""
<< TCmdLineDebugger.ReadLn "(gdb) "
You do realize that this is an hack? (I partly wrote it)
It could
On 01/13/2011 02:25 AM, Hans-Peter Diettrich wrote:
This would result in the same error, because x.a is not an lval.
The example that make me ask here was Form1.Caption := Form1.Caption + '.';
-Michael
___
fpc-devel maillist - fpc-devel@lists.free
In our previous episode, Hans-Peter Diettrich said:
> >>> "non-native" strings, it can also be a performance win).
> >> IMO a single encoding, i.e. UTF-8, can cover all cases.
> >
> > Well, for starters, it doesn't cover the existing Delphi/unicode codebase.
>
> Because it's bound to UTF-16? That
Joost van der Sluis wrote:
On Wed, 2011-01-12 at 23:52 +, Martin wrote:
Has dwarf 2 changed ?
>> TCmdLineDebugger.SendCmdLn "-data-evaluate-expression
^^shortstring(^POINTER($eax)^+12)^^"
<< TCmdLineDebugger.ReadLn "^done,value="#0""
<< TCmdLineDebugger.ReadLn "(gdb) "
You do reali
Hello FPC,
Thursday, January 13, 2011, 10:03:02 AM, you wrote:
>> ODBC 3.5 was launched around 2000-2001.
L> But this approach will require changes in packages/odbc/src/odbcsql.inc
L> like, does not ?:
L> -pointer(SQLGetData) :=
L> GetProcedureAddress(ODBCLibraryHandle,'SQLGetData');
L> +
L> Yes in UNIX world it may be so (I do not know),
L> but in Windows ODBC we have no such possibility AFAIK
Quote from Microsoft:
"The ODBC 3.5 (or higher) Driver Manager supports both ANSI and
Unicode versions of all functions that accept pointers to character
strings or SQLPOINTER in their ar
Joost van der Sluis wrote / nap?sal(a):
On Wed, 2011-01-12 at 14:59 +0100, LacaK wrote:
No. It is mandatory that you send/receive UTF8 to/from GUI LCL
elements.
As LCL elements are using TStringField.Text property, then this property
should return UTF8String, right (not AnsiString
Didn't I explain this to you and others a few times?
;-) If so, then please excuse me
The database-components itself are encoding-agnostic. This means:
encoding in = encoding out.
So it is up to the developer what codepage he want to use. So
TField.Text can have the encoding _you_ want.
On Wednesday, 12. January 2011 23.05:02 Juha Manninen wrote:
> Martin Schreiber kirjoitti maanantai 10 tammikuu 2011 19:22:49:
> > On Monday, 10. January 2011 16.27:19 Marco van de Voort wrote:
> > > And there are three such cases
> > >
> > > - normal FPC and Delph 2007- code : ansistring(0)
> > >
25 matches
Mail list logo
