After reading the mailing lists more I've played a little bit with this
and it seems that with Zeos (MySQL5) it is working out of the box at
first sight (need some more tests) if one sets the
ZConnection.Properties to
character_set_client=utf8
character_set_connection=utf8
character_set_databa
Florian Klaempfl wrote:
No. First, imo it's more likely that the next release will be 2.4.0
and not 2.2.4, further, the changes are too big.
Do you have a todo for it? IOW, what is missing to start releasing of
2.4.0 (we need resources changes ;) )
Best regards,
Paul Ishenin.
_
Martin Schreiber schrieb:
On Sunday 14 September 2008 19.22:13 Florian Klaempfl wrote:
Martin Schreiber schrieb:
I tried with trunk, same result. The problem is probably that the second
constant string parameter has a wrong reference count. It is initially 0
instead of -1. The incref call at be
On Sunday 14 September 2008 19.22:13 Florian Klaempfl wrote:
> Martin Schreiber schrieb:
> > I tried with trunk, same result. The problem is probably that the second
> > constant string parameter has a wrong reference count. It is initially 0
> > instead of -1. The incref call at begin of winfilepa
Martin Schreiber schrieb:
On Thursday 11 September 2008 23.18:07 Florian Klaempfl wrote:
Martin Schreiber schrieb:
On Saturday 30 August 2008 13.37:42 Florian Klaempfl wrote:
I have a crash in MSEide startup in a procedure finalization section:
[...]
I saw that you merged unicodestring to tr
On Thursday 11 September 2008 23.18:07 Florian Klaempfl wrote:
> Martin Schreiber schrieb:
> > On Saturday 30 August 2008 13.37:42 Florian Klaempfl wrote:
> >
> > I have a crash in MSEide startup in a procedure finalization section:
[...]
> > I saw that you merged unicodestring to trunk. Should I t
> It is not documented at all. Just like the rest of the database-stuff.
> But maybe I should write a FAQ for fpc. With the new lazarus-versions
> using UTF-8 by default, this is asked quite often.
This would be really nice.
I know I'm not the only one who doesn't want to spend days on hacking
Sorry, but I meant comparing with collation. I did not mean comapring
within labguage context.
How can you do /proper/ collation while ignoring the language context?
1) 'sıkıcı' which means 'boring' in English (notice the dotless small
'i's)
2) 'sikici' which means 'fucker' in English
Depe
listmember wrote:
IMHO The discussion splits here between:
1) How can this be done in a specific app
2) what should fpc provide
as for 2: This would be on top of yet (afaik) missing basic functions
such as
Compare using collation x (where collation is given as argument to
compare, not as part of
[Note that, here 'TCharacter' isn't necessarily an object; it might as
well be a simple record structure.]
AFAIK for most programmers this is not a common task. Most programs need less
(one language or codepage)
But, when you're talking unicode, codepage is rather meaningless --isn't it?
or
Actually for you example case doesn't matter. as you need to decide if
"ss" = "ß"
And, this is only valid in German. For all other, the result must either
be false, or undefined.
Is there, in Unicode, start-stop markes that denote 'language'?
I do not know, that was why I said "unused uni
listmember wrote:
Martin Friebe wrote:
Just to make sure, all of this discussion is based on various collation
No part of this discussion is based on collation.
Ok, so we were talking about different things
Here is a scenario for you:
You have multilanguage text as data. Someone has ask
Op vrijdag 12-09-2008 om 15:56 uur [tijdzone +0200], schreef Mattias
Gärtner:
> Zitat von Joost van der Sluis <[EMAIL PROTECTED]>:
>
> > Op vrijdag 12-09-2008 om 13:22 uur [tijdzone +0200], schreef JoshyFun:
> >
> > > A> Thanks for pointing me to the Lazarus thread about this and the bug
> > > A>
Daniël Mantione schrieb:
>
>
> Op Fri, 12 Sep 2008, schreef listmember:
>
>> This search needs to be NOT case-sensitive.
>>
>> How can you do this?
>>
>> Is it doable if TCharacter (or wahtever you call it) has no 'langauge'
>> attribite?
>
> 'I am on FoolStrasse' versus 'I am on FoolStraße' is
Op Fri, 12 Sep 2008, schreef listmember:
This search needs to be NOT case-sensitive.
How can you do this?
Is it doable if TCharacter (or wahtever you call it) has no 'langauge'
attribite?
'I am on FoolStrasse' versus 'I am on FoolStraße' is not a upper/lower
case issue. Strasse and Straß
Zitat von Joost van der Sluis <[EMAIL PROTECTED]>:
> Op vrijdag 12-09-2008 om 13:22 uur [tijdzone +0200], schreef JoshyFun:
>
> > A> Thanks for pointing me to the Lazarus thread about this and the bug
> > A> report. Checked them.
> > A> But as I understand there is no solution available at the mom
Zitat von listmember <[EMAIL PROTECTED]>:
>[...]
> You have multilanguage text as data. Someone has asked you to search it
> and see if a certain peice of string (in a given language) exists in it.
>
> This search needs to be NOT case-sensitive.
>
> How can you do this?
>
> Is it doable if TCharac
Martin Friebe wrote:
Just to make sure, all of this discussion is based on various collation
No part of this discussion is based on collation.
I am going to leave out the object question for now. I said all I can
say in earlier mails.
That's good. Thank you.
And also from your comments it
Op vrijdag 12-09-2008 om 13:22 uur [tijdzone +0200], schreef JoshyFun:
> A> Thanks for pointing me to the Lazarus thread about this and the bug
> A> report. Checked them.
> A> But as I understand there is no solution available at the moment for this.
>
> I had partially solved the problem using t
Hello ABorka,
Friday, September 12, 2008, 2:30:35 AM, you wrote:
A> Thanks for pointing me to the Lazarus thread about this and the bug
A> report. Checked them.
A> But as I understand there is no solution available at the moment for this.
I had partially solved the problem using the handler "OnG
Just to make sure, all of this discussion is based on various collation
for European languages? Or shall we include Arabic, Chinese and other
languages? But they have there own chars, they can be identified without
collation, so they do not need the language info, to be distinguished
from Europ
Hi,
Thanks for pointing me to the Lazarus thread about this and the bug
report. Checked them.
But as I understand there is no solution available at the moment for this.
I have a database that is not encoded utf8 (and it will never be because
other client programs are accessing it and their u
So maybe the design is quite well thought?
Adding a flag field is easy enough --if all you're doing is to do some
sort of collation. In that sense, everything is well tought out.
But..
Life becomes very complicated when you begin to do things like FTS (full
text search) on a multilanguage t
listmember wrote:
I also do not know of other apps that could do this. (And it may not be
possible). Look around. Databses for example, AFAIK the most you can do
is define a collation per column.
True. But, that does not mean that those app/databases are well
thought out. Does it?
Point of Vie
IMHO You can't? But you could use a TStringList.
I don't think I could.
Because, in TStringList, you have no way of knowing what language each
item belogs to.
You could, of course, work around it by adding a fake object to each
item denoting the language, but that does mean a generalized so
listmember wrote:
Actually, UTF-8 can contain bidi info, it's indeed a matter of the
renderer.
And, how do you propose doing a case-insensitive search in a given
text that contains multiple languages?
I assume you speak of multiply collations in on string?
IMHO You can't? But you could use a TS
Actually, UTF-8 can contain bidi info, it's indeed a matter of the
renderer.
And, how do you propose doing a case-insensitive search in a given text
that contains multiple languages?
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://
On Thu, 11 Sep 2008 22:56:49 +0200
Martin Schreiber <[EMAIL PROTECTED]> wrote:
>[...]
> > Doesn't that mean we will be --by design-- unable to write something
> > like 'Yom Kippur (יוֹם כִּפּוּר)' on a caption?
Yes and more. See below.
> > This is why I keep asking that the 'TCharacter' or 'TCh
Martin Schreiber schrieb:
On Saturday 30 August 2008 13.37:42 Florian Klaempfl wrote:
I've continued to work on support of an unicodestring type in fpc. It's
currently in an svn branch at:
http://svn.freepascal.org/svn/fpc/branches/unicodestring
and will be merged later to trunk. The unicodestri
On Thursday 11 September 2008 22.33:32 listmember wrote:
> >> procedure TLabel.Paint(...)
> >> begin
> >> if *Caption.IsRTL *then
> >> DrawCaptionRTL(0,0,*Caption.AsUTF8*, flags)
> >> else
> >> DrawCaption(0,0,*Caption.AsUTF8*, flags);
> >> end;
> >>
> >> Is not that enough?
> >
Marco van de Voort schrieb:
In our previous episode, listmember said:
> else
> DrawCaption(0,0,AsUTF8(Caption), flags);
> end;
>
> In other words where is the benefit from OOP in this ?
IMO, both are deficient as they both assume that a string block (text)
is either RTL or LTR.
In our previous episode, listmember said:
> > else
> > DrawCaption(0,0,AsUTF8(Caption), flags);
> > end;
> >
> > In other words where is the benefit from OOP in this ?
>
> IMO, both are deficient as they both assume that a string block (text)
> is either RTL or LTR.
The assignment
>> procedure TLabel.Paint(...)
>> begin
>> if *Caption.IsRTL *then
>> DrawCaptionRTL(0,0,*Caption.AsUTF8*, flags)
>> else
>> DrawCaption(0,0,*Caption.AsUTF8*, flags);
>> end;
>>
>> Is not that enough?
>
> What is the gain as opposed to
>
> procedure TLabel.Paint(...)
> begin
>if
On Saturday 30 August 2008 13.37:42 Florian Klaempfl wrote:
> I've continued to work on support of an unicodestring type in fpc. It's
> currently in an svn branch at:
> http://svn.freepascal.org/svn/fpc/branches/unicodestring
> and will be merged later to trunk. The unicodestring type is a ref.
> c
Hello ABorka,
Thursday, September 11, 2008, 7:26:50 PM, you wrote:
A> The database field can contain any string with '®' in it for this to happen
A> for example: 'sometext®'
A> It seems that
A> ListBox1.Items.Add(SQL1.FieldByName('MyTableField').AsString);
[...]
A> will only put an empty string i
Some conversion problem occurs and empty string put into a TListbox if I
try to get a field value with some special characters from a SQL result.
(using Zeos)
The database field can contain any string with '®' in it for this to happen
for example: 'sometext®'
It seems that
ListBox1.Items.Ad
Michael Van Canneyt wrote:
On Thu, 11 Sep 2008, Anton Kavalenka wrote:
Florian Klaempfl wrote:
Graeme Geldenhuys schrieb:
Remember, Unicode support is much more that simply storing and
displaying text. You have various encodings, RTL or LTR direction etc.
I can't see how a simpl
Anton Kavalenka wrote:
How would an OOP approach solve this? The problem isn't the tracking of
things like encoding or directions but handling all these information.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/
On Thu, 11 Sep 2008, Anton Kavalenka wrote:
> Florian Klaempfl wrote:
> > Graeme Geldenhuys schrieb:
> >
> > > Remember, Unicode support is much more that simply storing and
> > > displaying text. You have various encodings, RTL or LTR direction etc.
> > > I can't see how a simple type can ke
Florian Klaempfl wrote:
Graeme Geldenhuys schrieb:
Remember, Unicode support is much more that simply storing and
displaying text. You have various encodings, RTL or LTR direction etc.
I can't see how a simple type can keep track of all such information
- but then, I don't know the internals
But it is far more readable when there is special and reserved type
for which we could have special operators and converters just like
those we have for strings and widestrings.
Oh, I thougbt people just complained in this thread that + isn't
appropriate for strings anyways ...
People are, o
Hello listmember,
Wednesday, September 10, 2008, 3:55:25 PM, you wrote:
l> Please don't get resented, but this kind of attitued is verging on being
l> offensive..
l> Instead of looking at the issue from POV of "I don't need it" or "It
l> requires more hardware resources", can't you try to evaluat
listmember schrieb:
compiler guys all the same} and ask, instead, to give us
reference-counted 4-byte (actually, preferably 6-bytes) per cell
arrays/strings.
What's wrong with an dyn. array of DWord?
Much like what's wrong with dynamic array of Word (as opposed to
Widestring) or with dynami
compiler guys all the same} and ask, instead, to give us
reference-counted 4-byte (actually, preferably 6-bytes) per cell
arrays/strings.
What's wrong with an dyn. array of DWord?
Much like what's wrong with dynamic array of Word (as opposed to
Widestring) or with dynamic array of byte (as o
listmember schrieb:
>>> But, I could write a gigantic data mining application, a database
>>> application
>>> or a myriad of such apps that uses the above class without doing a
>>> single
>>> pixel of GUI stuff.
>>
>> I'd like to see that: it will be guaranteed dog slow :(
>
> Hmm.. may be, maybe
But, I could write a gigantic data mining application, a database application
or a myriad of such apps that uses the above class without doing a single
pixel of GUI stuff.
I'd like to see that: it will be guaranteed dog slow :(
Hmm.. may be, maybe not.
Last year I wrote a natural lang parser
On Wed, 10 Sep 2008, listmember wrote:
> Michael Van Canneyt wrote:
> > You are mixing 2 things. There is the actual string content, and there is
> > the
> > string metadata. The metadata is something that would apply for flyweight
> > pattern. There is nothing to be gained by putting the metada
On Wed, 10 Sep 2008, listmember wrote:
> Michael Van Canneyt wrote:
> > You are mixing 2 things:
> >
> > - Texts (strings) at the compiler language level.
> > - (complex) GUI design that needs to handle a lot of text and a lot of extra
> >properties.
>
> :)
>
> If you draw the lines so red
In our previous episode, listmember said:
> > - Texts (strings) at the compiler language level.
> > - (complex) GUI design that needs to handle a lot of text and a lot of extra
> >properties.
>
> If you draw the lines so red and thick, who am I to disagree...
>
> But, I could write a gigantic
Michael Van Canneyt wrote:
You are mixing 2 things:
- Texts (strings) at the compiler language level.
- (complex) GUI design that needs to handle a lot of text and a lot of extra
properties.
:)
If you draw the lines so red and thick, who am I to disagree...
But, I could write a gigantic d
Yes, but most proposals here about a TCharacter are a bit overkill. In
example languare reference for a given char is not very important from
a Unicode point of view, unicode focuses its power in the text, so
locale is important in context operations and collations.
See my other post above.
Michael Van Canneyt wrote:
You are mixing 2 things. There is the actual string content, and there is the
string metadata. The metadata is something that would apply for flyweight
pattern. There is nothing to be gained by putting the metadata in an object,
This is true --upto a point.
And, that
In our previous episode, Graeme Geldenhuys said:
> > The problem is how it applies to strings, and how they can be more
> > memory saving than a straight array of 16-bit values which are
> > copy-on-write.
>
> I think for a good code example of this, have a look at Java's
> Document class. It's
Hello Graeme,
Wednesday, September 10, 2008, 12:36:17 PM, you wrote:
GG> Remember, Unicode support is much more that simply storing and
GG> displaying text. You have various encodings, RTL or LTR direction etc.
GG> I can't see how a simple type can keep track of all such information
GG> - but th
Graeme Geldenhuys schrieb:
> Remember, Unicode support is much more that simply storing and
> displaying text. You have various encodings, RTL or LTR direction etc.
> I can't see how a simple type can keep track of all such information
> - but then, I don't know the internals of FPC either. ;-)
On Wed, 10 Sep 2008, Graeme Geldenhuys wrote:
> On 9/10/08, Marco van de Voort <[EMAIL PROTECTED]> wrote:
> >
> > Like everybody, I have read GOF several times, and even got some of the
> > successor books.
>
> I don't think anybody has read GOF only once. :-)
>
>
> > The problem is how it
On 9/10/08, Marco van de Voort <[EMAIL PROTECTED]> wrote:
>
> Like everybody, I have read GOF several times, and even got some of the
> successor books.
I don't think anybody has read GOF only once. :-)
> The problem is how it applies to strings, and how they can be more
> memory saving than
In our previous episode, Graeme Geldenhuys said:
> > this ever save memory?
>
> Please read the following...
>
> http://exciton.cs.rice.edu/JavaResources/DesignPatterns/FlyweightPattern.htm
>
> http://en.wikipedia.org/wiki/Flyweight_pattern
>
> Design Patterns - Elements of Reusable Object-Orie
Zitat von Graeme Geldenhuys <[EMAIL PROTECTED]>:
> On 9/10/08, Micha Nelissen <[EMAIL PROTECTED]> wrote:
> > > TCharacter and TString to be more intelligent with what encoding it
> > > represents etc... And if you have an application with many strings, it
> > > might actually save memory, because
On 9/10/08, Graeme Geldenhuys <[EMAIL PROTECTED]> wrote:
>
> Please read the following...
>
> http://exciton.cs.rice.edu/JavaResources/DesignPatterns/FlyweightPattern.htm
>
> http://en.wikipedia.org/wiki/Flyweight_pattern
>
> Design Patterns - Elements of Reusable Object-Oriented Software
> (a
On 9/10/08, Micha Nelissen <[EMAIL PROTECTED]> wrote:
> > TCharacter and TString to be more intelligent with what encoding it
> > represents etc... And if you have an application with many strings, it
> > might actually save memory, because flyweight objects are used from a
> > pool.
> >
>
> Save
Graeme Geldenhuys wrote:
TCharacter and TString to be more intelligent with what encoding it
represents etc... And if you have an application with many strings, it
might actually save memory, because flyweight objects are used from a
pool.
Save memory?
1) storing information for each character
I
I fully agree with you. I would like the object oriented way of strings
also - but I stopped asking for that ;) There are a lot of advantages
over the small amount of disadvantages. Of course I dont like this one:
S := TString.Create('');
But a built in class TString that is managed by the co
Marco van de Voort schrieb:
> In our previous episode, Ivo Steinmann said:
>> I fully agree with you. I would like the object oriented way of strings
>> also - but I stopped asking for that ;) There are a lot of advantages
>> over the small amount of disadvantages. Of course I dont like this one:
>
In our previous episode, Ivo Steinmann said:
> I fully agree with you. I would like the object oriented way of strings
> also - but I stopped asking for that ;) There are a lot of advantages
> over the small amount of disadvantages. Of course I dont like this one:
>
> S := TString.Create('');
>
>
On Wed, Sep 10, 2008 at 7:15 AM, listmember <[EMAIL PROTECTED]> wrote:
> 1) since each character is a class, memory requirements are increased
> several fold.
>
> 2) Again, the charater-as-class also means that the speed with wich we can
> create and destroy (and manipulate) a string is a lot slowe
Graeme Geldenhuys wrote:
I have to say I agree with you The Object Pascal / Delphi language
already has way to many string types! At it's just getting worse.
I've always liked the Java style of everything being an object - even
the string type.
The more I look at this Unicode issue, the m
peter green schreef:
I have just checked the manual and I don't see anything I can use to
make sure my custom type starts at a predictable state initially
(nessacery so they assignment operator can safely clean up before
making the assignment). Nor do I see anything to do automatic clean up
Jonas Maebe schrieb:
On 09 Sep 2008, at 21:37, Florian Klaempfl wrote:
Even C++'s is not good enough to do a ref. counted string in an
efficient way. Just consider the [...] operator which needs to
distinguish between reads and writes to avoid unncessary unique calls.
Can't you have a const
Check again...
I have just checked the manual and I don't see anything I can use to
make sure my custom type starts at a predictable state initially
(nessacery so they assignment operator can safely clean up before making
the assignment). Nor do I see anything to do automatic clean up when th
On 09 Sep 2008, at 21:37, Florian Klaempfl wrote:
Even C++'s is not good enough to do a ref. counted string in an
efficient way. Just consider the [...] operator which needs to
distinguish between reads and writes to avoid unncessary unique calls.
Can't you have a const and non-const versi
Martin Schreiber schrieb:
On Sunday 07 September 2008 21.23:24 Florian Klaempfl wrote:
Trunk 11723 does not compile:
Trunk or unicodestring branch? Strange, because here it works?
Unicodestring branch, sorry, I should change the directory name of my switched
checkout. Does your unicodestring
peter green schrieb:
3: Use an automatic reference counting system either implemented in the
compiler (the delphi/fpc way) or implemented using a very powerfull
operator overloading system (the C++ way, last I checked freepascal did
not have sufficiant operator overloading capabilities to imple
peter green schreef:
I fully agree with you. I would like the object oriented way of strings
also - but I stopped asking for that ;) There are a lot of advantages
over the small amount of disadvantages.
Which object orientated way of doing strings?
As I see it there are three main ways of doi
I fully agree with you. I would like the object oriented way of strings
also - but I stopped asking for that ;) There are a lot of advantages
over the small amount of disadvantages.
Which object orientated way of doing strings?
As I see it there are three main ways of doing variable length str
Ivo Steinmann schrieb:
I fully agree with you. I would like the object oriented way of strings
also - but I stopped asking for that ;) There are a lot of advantages
Which ones? Really, I want to know :)
___
fpc-devel maillist - fpc-devel@lists.freep
Anton Kavalenka schrieb:
> Florian Klaempfl wrote:
>> I've continued to work on support of an unicodestring type in fpc.
>> It's currently in an svn branch at:
>> http://svn.freepascal.org/svn/fpc/branches/unicodestring
>> and will be merged later to trunk. The unicodestring type is a ref.
>> count
Anton Kavalenka wrote:
I only have a dream - controllable way of string assignment without any
magic like implicit call of _LStrAddRefCnt
Do you have a real-world sample of usage, ie, where or when the object
pascal way is a problem?
Joao Morais
__
Michael Van Canneyt wrote:
On Tue, 9 Sep 2008, Anton Kavalenka wrote:
Nothing stops you from doing this yourself.
But for something as basic as text operations, I think this is bloat.
Imagine that you would have to do
I:=TInteger.Create(1);
J:=TInteger.Create(2);
I.Add(J);
What kind
On Tue, Sep 9, 2008 at 2:23 PM, Graeme Geldenhuys
<[EMAIL PROTECTED]> wrote:
> On 9/9/08, Anton Kavalenka <[EMAIL PROTECTED]> wrote:
>> The Pascal huge strings always annoy me.
>> Since - it is IMPLICIT automatic object with set of overloaded methods,
>> length and reference count fields etc hidd
On Tue, 9 Sep 2008, Anton Kavalenka wrote:
>
> > Nothing stops you from doing this yourself.
> >
> > But for something as basic as text operations, I think this is bloat.
> >
> > Imagine that you would have to do
> > I:=TInteger.Create(1);
> > J:=TInteger.Create(2);
> > I.Add(J);
> > What
Nothing stops you from doing this yourself.
But for something as basic as text operations, I think this is bloat.
Imagine that you would have to do
I:=TInteger.Create(1);
J:=TInteger.Create(2);
I.Add(J);
What kind of language do you end up with then ? Utterly unreadable, and
slow, becau
In our previous episode, Graeme Geldenhuys said:
> > The Pascal huge strings always annoy me. Since - it is IMPLICIT
> > automatic object with set of overloaded methods,
> > length and reference count fields etc hidden from developer.
> >
> > In near future we geat a Zoo of the strings:
> > A
On Tue, 9 Sep 2008, Anton Kavalenka wrote:
> Florian Klaempfl wrote:
> > I've continued to work on support of an unicodestring type in fpc. It's
> > currently in an svn branch at:
> > http://svn.freepascal.org/svn/fpc/branches/unicodestring
> > and will be merged later to trunk. The unicodestrin
On 9/9/08, Anton Kavalenka <[EMAIL PROTECTED]> wrote:
> The Pascal huge strings always annoy me.
> Since - it is IMPLICIT automatic object with set of overloaded methods,
> length and reference count fields etc hidden from developer.
>
> In near future we geat a Zoo of the strings:
> AnsiString
Florian Klaempfl wrote:
I've continued to work on support of an unicodestring type in fpc.
It's currently in an svn branch at:
http://svn.freepascal.org/svn/fpc/branches/unicodestring
and will be merged later to trunk. The unicodestring type is a ref.
counted utf-16 string. On non-windows, wide
On Sunday 07 September 2008 21.23:24 Florian Klaempfl wrote:
> >
> > Trunk 11723 does not compile:
>
> Trunk or unicodestring branch? Strange, because here it works?
Unicodestring branch, sorry, I should change the directory name of my switched
checkout. Does your unicodestring branch compile?
M
Martin Schreiber schrieb:
On Sunday 07 September 2008 10.58:03 Florian Klaempfl wrote:
Martin Schreiber schrieb:
On Saturday 06 September 2008 21.08:50 Florian Klaempfl wrote:
Martin Schreiber schrieb:
Next problem is that pmsechar(msestring) returns a NIL pointer if
msestring = ''. As design
On Sunday 07 September 2008 10.58:03 Florian Klaempfl wrote:
> Martin Schreiber schrieb:
> > On Saturday 06 September 2008 21.08:50 Florian Klaempfl wrote:
> >> Martin Schreiber schrieb:
> >>> Next problem is that pmsechar(msestring) returns a NIL pointer if
> >>> msestring = ''. As designed? The b
Martin Schreiber schrieb:
On Saturday 06 September 2008 21.08:50 Florian Klaempfl wrote:
Martin Schreiber schrieb:
Next problem is that pmsechar(msestring) returns a NIL pointer if
msestring = ''. As designed? The behaviour of ansistring and widestring
was very useful, I'd like if UnicodeStrin
On Saturday 06 September 2008 21.08:50 Florian Klaempfl wrote:
> Martin Schreiber schrieb:
>
> > Next problem is that pmsechar(msestring) returns a NIL pointer if
> > msestring = ''. As designed? The behaviour of ansistring and widestring
> > was very useful, I'd like if UnicodeString would behave
Martin Schreiber schrieb:
On Friday 05 September 2008 22.50:23 Florian Klaempfl wrote:
[...]
This should be fixed.
Thanks, FPC and MSEide compile now.
Attached an "emergency" patch that I could load the MSEgui forms, not finished
and not tested.
Thanks.
Is TTypekind = (... tkInterfaceRaw,
On Friday 05 September 2008 22.50:23 Florian Klaempfl wrote:
[...]
>
> This should be fixed.
> >
Thanks, FPC and MSEide compile now.
Attached an "emergency" patch that I could load the MSEgui forms, not finished
and not tested. Is TTypekind = (... tkInterfaceRaw,tkUChar,tkUString)
correct?
Nex
On Friday 05 September 2008 22.50:23 Florian Klaempfl wrote:
> > If you want to try it yourself, MSEide+MSEgui trunk rev. 2473 has
> > msestring = unicodestring if compiled with -dmse_unicodestring.
>
> What's the official way to compile MSE?
>
cd apps\ide
ppc386.exe -Fu..\..\lib\common\* -Fi..\..\
Martin Schreiber schrieb:
Florian,
On Saturday 30 August 2008 13.37:42 Florian Klaempfl wrote:
I've continued to work on support of an unicodestring type in fpc. It's
currently in an svn branch at:
http://svn.freepascal.org/svn/fpc/branches/unicodestring
and will be merged later to trunk. The u
Florian,
On Saturday 30 August 2008 13.37:42 Florian Klaempfl wrote:
> I've continued to work on support of an unicodestring type in fpc. It's
> currently in an svn branch at:
> http://svn.freepascal.org/svn/fpc/branches/unicodestring
> and will be merged later to trunk. The unicodestring type is
In our previous episode, Marc Weustink said:
> OK, then we name it objects (or records with methods)
>
> > Before you know it you are messing with special stringbuilder classes and
> > special syntax to keep a semblance of performance. Moreover I don't really
> > see what this solves.
>
> It solv
Marco van de Voort wrote:
In our previous episode, Ivo Steinmann said:
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Why not creating a new kind of managed class, that is refcounted,
initialized, finalized, etc... like String ty
In our previous episode, Ivo Steinmann said:
> > fpc-devel maillist - fpc-devel@lists.freepascal.org
> > http://lists.freepascal.org/mailman/listinfo/fpc-devel
> >
> >
> Why not creating a new kind of managed class, that is refcounted,
> initialized, finalized, etc... like String type?
I nev
Marco van de Voort schrieb:
In our previous episode, Luiz Americo Pereira Camara said:
And use TNativeString for encoding agnostic purposes.
Well, really agnostic code should simply use "string" :)
Delphi is introducing the RawByteString type, that skips the auto
encoding c
1 - 100 of 119 matches
Mail list logo
