Graeme Geldenhuys schrieb:
On 2011-10-21 10:22, Hans-Peter Diettrich wrote:
Now also tell us how application code is affected by such astral
codepoints, and how these are handled easier in UTF-8 than in UTF-16.
As to not repeat myself, see one of my other replies.
I didn't ask for a repetit
Graeme Geldenhuys schrieb:
On 2011-10-20 17:30, Luca Olivetti wrote:
"Additionally, 16 bits is enough to cover the BMP, Basic Multilingual
Plane, which encompasses the majority of today's most widely used
languages. Only when you get to more advanced codepoints in some of the
far-eastern languag
Žilvinas Ledas schrieb:
Hello,
On 2011-10-21 10:43, Michael Schnell wrote:
Of course you are right, but "move" and friends is "hardware-near
programming" for this who know what they are doing. but basic (legacy)
string operations like "myChar := myString[i]" is "office-level
programming" and
Michael Lutz schrieb:
Am 21.10.2011 15:02 schrieb Michael Schnell:
But if you just deal with the user's GUI input and output and with files
that you wrote yourself in some default encoding code the language tools
define, IMHO a decent language should do whatever possible to hide the
complexity
Michael Schnell schrieb:
On 10/20/2011 09:42 PM, Felipe Monteiro de Carvalho wrote:
Changing the size of Char is not just small detail, this breaks *a
lot* of code. Any kind of memory operations such as Move will fail
because the char size changed.
Of course you are right, but "move" and friend
Michael Lutz schrieb:
Am 21.10.2011 00:20 schrieb Hans-Peter Diettrich:
The Ansi/UTF-16 migration is much easier than a migration to UTF-8. When
your legacy code can assume that every (visible) character is a Char, in
an SBCS codepage, this is not different in UTF-16.
Ever heard of decomposed
Graeme Geldenhuys schrieb:
On 2011-10-21 10:19, Hans-Peter Diettrich wrote:
Please specify "Finding", a code snippet would be nice.
Knock yourself out...
https://github.com/graemeg/fpGUI/blob/master/src/corelib/fpg_stringutils.pas
Take a look at UTF8Copy() or UTF8Insert() etc.
I didn't m
Graeme Geldenhuys schrieb:
On 2011-10-21 10:31, Michael Schnell wrote:
So with these projects you obviously are a "Unicode aware" programmer
and don't qualify for the group of "office" programmers that (IMHO)
I don't have to think about anything special when working with Unicode
text. I simp
Felipe Monteiro de Carvalho schrieb:
Maybe we should have instead created 1 color for each native control,
like: clFormDefault, clPageControlDefault, etc.
For that purpose we already have clScrollBar etc., see Graphics.pp 270 ff.
At least on Windows the user can specify freely the colors for
> This is weird. After a long work with this translation, it is the first time
> that i heard someone complaining about it. So far, i never got a single
> suggestion.
I have made an extensive translation of the IDE a few years ago, you
may know about that. Perhaps you don't know who has made it.
Hello,
This is weird. After a long work with this translation, it is the first time
that i heard someone complaining about it. So far, i never got a single
suggestion.
I understand that "linking" refers to the act of the "linker". It is what a
"linker" does. So, to me " linking" in this case r
Michael Schnell hat am 21. Oktober 2011 um 17:23
geschrieben:
> On 10/21/2011 04:13 PM, Michael Lutz wrote:
> > If you write a file with a file name in unicode NFC in OS X
> > and read the file name back from the OS, you'll get a NFD string returned,
> > which means a normalization-unaware co
On 10/21/2011 04:13 PM, Michael Lutz wrote:
If you write a file with a file name in unicode NFC in OS X
and read the file name back from the OS, you'll get a NFD string returned,
which means a normalization-unaware compare function will not do what
you'd expect.
...as already mentioned in anothe
The alternative is "Vinculador", which would result in "Linker" in English.
Antônio
2011/10/21 Antônio :
> Another translation for "Linking" could be "Vínculo", but sounds a bit
> confusing.
>
> Antônio
>
> 2011/10/21 Antônio :
>> In English I think it is OK.
>>
>> Antônio
>>
>> 2011/10/21 Felipe
Another translation for "Linking" could be "Vínculo", but sounds a bit
confusing.
Antônio
2011/10/21 Antônio :
> In English I think it is OK.
>
> Antônio
>
> 2011/10/21 Felipe Monteiro de Carvalho :
>> On Fri, Oct 21, 2011 at 3:22 PM, Vincent Snijders
>> wrote:
>>> These are options related to l
In English I think it is OK.
Antônio
2011/10/21 Felipe Monteiro de Carvalho :
> On Fri, Oct 21, 2011 at 3:22 PM, Vincent Snijders
> wrote:
>> These are options related to linking. Of source these options are used
>> by the linker.
>>
>> So, IMHO, both linking and linker are good terms in English
On Fri, Oct 21, 2011 at 3:22 PM, Vincent Snijders
wrote:
> These are options related to linking. Of source these options are used
> by the linker.
>
> So, IMHO, both linking and linker are good terms in English.
Yes, you are correct. I was thinking of "linking" as a verb in gerund,
which would be
Hi,
I use the IDE in English for two reasons: is easier to report problems
and ask questions in official list or bugtracker; to practice my
English :D.
But I agree with Antonio that the current translation is sounding
strangely to pt_BR.
--
Silvio Clécio
Am 21.10.2011 10:00 schrieb Michael Schnell:
> On 10/20/2011 10:26 PM, Felipe Monteiro de Carvalho wrote:
>> Mac OS X uses the decomposed form in UTF-8 to store filenames, which
>> is rather unpleasant.
>
> Why are they so silly ?
What's silly about that? If they'd store it in precomposed form (N
Am 21.10.2011 09:10, schrieb Graeme Geldenhuys:
On 2011-10-21 09:04, Alexander Shishkin wrote:
SendInteger('$Param(data,Sync=1)|', $Param(data,Sync=1));
Awesome, thanks! That works perfectly under 0.9.30.x too. :-)
AFAIK you don't need the "Sync=1" in the first parameter (if it is
indeed t
Am 21.10.2011 15:02 schrieb Michael Schnell:
> But if you just deal with the user's GUI input and output and with files
> that you wrote yourself in some default encoding code the language tools
> define, IMHO a decent language should do whatever possible to hide the
> complexity.
You'd advocat
Something similar could be said of "Version Info", "Code Generation",
"Build Macros", which should be "Informação de versão", "Geração de
código". And also you have to choose between writing all with
capitals or not.
"Build Macros" could be translated simply as "Macros".
Antônio
2011/10/21 Antô
Yes, but something must be learned from the commercial standard for Portuguese.
Antônio
2011/10/21 Vincent Snijders :
> 2011/10/21 Felipe Monteiro de Carvalho :
>> It should probably be "Linker" in english
>
> These are options related to linking. Of source these options are used
> by the linker.
2011/10/21 Felipe Monteiro de Carvalho :
> It should probably be "Linker" in english
These are options related to linking. Of source these options are used
by the linker.
So, IMHO, both linking and linker are good terms in English.
Vincent
--
___
Laza
It is Linking.
Antônio
2011/10/21 Felipe Monteiro de Carvalho :
> It should probably be "Linker" in english
>
> --
> Felipe Monteiro de Carvalho
>
> --
> ___
> Lazarus mailing list
> Lazarus@lists.lazarus.freepascal.org
> http://lists.lazarus.freepascal
It should probably be "Linker" in english
--
Felipe Monteiro de Carvalho
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Similarly, "Project / Project Options / Parser" must be translated as
"Projeto / Opções de Projeto / Analisador de Sintaxe" and not
"Analisando Sintaxe".
Antônio
2011/10/21 Antônio :
> The translation for "Project / Project Options / Linking" is not
> "Projeto / Opções de Projeto / Vinculando", b
The translation for "Project / Project Options / Linking" is not
"Projeto / Opções de Projeto / Vinculando", but "Projeto / Opções de
Projeto / Vinculador".
Antônio
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.fr
On 10/21/2011 02:18 PM, Žilvinas Ledas wrote:
What if a file on the user computer has...
If you deal with the content of files you did not write yourself, you of
course need to deal with whatever encoding same has been done in (maybe
its EBCDIC :) ). This is unavoidable and if you are so unhap
Hello,
On 2011-10-21 10:43, Michael Schnell wrote:
Of course you are right, but "move" and friends is "hardware-near
programming" for this who know what they are doing. but basic (legacy)
string operations like "myChar := myString[i]" is "office-level
programming" and thus should work as a dum
Am 21.10.2011 00:20 schrieb Hans-Peter Diettrich:
> The Ansi/UTF-16 migration is much easier than a migration to UTF-8. When
> your legacy code can assume that every (visible) character is a Char, in
> an SBCS codepage, this is not different in UTF-16.
Ever heard of decomposed characters? In *no
On Friday 21 of October 2011 09:25:27 Graeme Geldenhuys wrote:
> On 2011-10-20 17:57, Felipe Monteiro de Carvalho wrote:
> > I have my TCDPageControl on top of a form, but for
> > TCDPageControl.Color I get just clDefault, which turns out to be
> > black. =( using Parent.GetDefaultColor(dcBrush) al
On 2011-10-21 10:04, Felipe Monteiro de Carvalho wrote:
>
> Yes, that's how it worked before clDefault was introduced, but
OK, I now understand what you mean. All other "alias colors" (eg:
clBackground, clButtonFace) etc have actual RGB lookup values at
runtime, but clDefault I guess not. Indeed
On 2011-10-21 10:22, Hans-Peter Diettrich wrote:
>
> Now also tell us how application code is affected by such astral
> codepoints, and how these are handled easier in UTF-8 than in UTF-16.
As to not repeat myself, see one of my other replies.
Regards,
- Graeme -
--
fpGUI Toolkit - a cro
On Fri, Oct 21, 2011 at 10:35 AM, Paul Ishenin wrote:
> GetColor should return the color assigned to a control. In other case you
> will have many problems with object inspector and form saving.
Indeed ... In this case I propose something like this:
function TControl.GetColorResolvingParent: TCo
21.10.2011 16:23, Felipe Monteiro de Carvalho wrote:
Maybe GetColor should call GetDefaultColor if the color is clDefault?
GetColor should return the color assigned to a control. In other case
you will have many problems with object inspector and form saving.
Best regards,
Paul Ishenin.
21.10.2011 16:21, Felipe Monteiro de Carvalho пишет:
On Fri, Oct 21, 2011 at 10:14 AM, Paul Ishenin wrote:
How ParentColor property will work in this case?
I think that it would work like this:
function TWinControl.GetColor: TColor
begin
if ParentColor and (Parent<> nil) then Result := P
On 2011-10-21 10:31, Michael Schnell wrote:
> So with these projects you obviously are a "Unicode aware" programmer
> and don't qualify for the group of "office" programmers that (IMHO)
I don't have to think about anything special when working with Unicode
text. I simply use the string manipula
On 10/21/2011 10:09 AM, Graeme Geldenhuys wrote:
We use the Science and Maths symbols define outside the BMP all the time
in our products.
So with these projects you obviously are a "Unicode aware" programmer
and don't qualify for the group of "office" programmers that (IMHO)
should be enabled
On Fri, Oct 21, 2011 at 10:19 AM, Paul Ishenin wrote:
> if CDTabControl.Color = clDefault then
> lColor := ColorToRGB(CDTabControl.GetDefaultColor(dctBrush))
> else
> lColor := ColorToRGB(CDTabControl.Color);
>
> This should work ^.
Ok, thanks, this indeed works =) I did not expect GetDefaultCo
On 2011-10-21 10:19, Hans-Peter Diettrich wrote:
>
> Please specify "Finding", a code snippet would be nice.
Knock yourself out...
https://github.com/graemeg/fpGUI/blob/master/src/corelib/fpg_stringutils.pas
Take a look at UTF8Copy() or UTF8Insert() etc.
> in FPC, until now. Give an example
On Fri, Oct 21, 2011 at 10:14 AM, Paul Ishenin wrote:
> How ParentColor property will work in this case?
I think that it would work like this:
function TWinControl.GetColor: TColor
begin
if ParentColor and (Parent <> nil) then Result := Parent.Color
else Result := FColor;
end;
--
Felipe Mo
21.10.2011 16:01, Felipe Monteiro de Carvalho пишет:
On Fri, Oct 21, 2011 at 9:47 AM, Paul Ishenin wrote:
if CDTabControl.Color = clDefault then
lColor := CDTabControl.GetDefaultColor(dctBrush)<-- I get black!
else lColor := ColorToRGB(CDTabControl.Color);
The call to CDTabControl.G
21.10.2011 16:04, Felipe Monteiro de Carvalho wrote:
Maybe we should have instead created 1 color for each native control,
like: clFormDefault, clPageControlDefault, etc.
How ParentColor property will work in this case?
Best regards,
Paul Ishenin.
--
___
On 2011-10-21 09:50, Michael Schnell wrote:
>
> But in fact I up til now never came across any situation requiring
> non-BMP encoding.
We use the Science and Maths symbols define outside the BMP all the time
in our products. Why use images (old school style) when font symbols
(today's style) can
Paul Ishenin schrieb:
21.10.2011 5:39, Hans-Peter Diettrich wrote:
What's the purpose and action of TWinControl.AddControl?
The source code comment suggests
Add Handle object to *parents* Handle object.
but the code invokes
TWSControlClass(WidgetSetClass).AddControl(Self);
with no Parent involv
Graeme Geldenhuys schrieb:
On 2011-10-20 17:30, Luca Olivetti wrote:
"Additionally, 16 bits is enough to cover the BMP, Basic Multilingual
Plane, which encompasses the majority of today's most widely used
languages. Only when you get to more advanced codepoints in some of the
far-eastern languag
Graeme Geldenhuys schrieb:
On 2011-10-21 00:20, Hans-Peter Diettrich wrote:
your legacy code can assume that every (visible) character is a Char, in
an SBCS codepage, this is not different in UTF-16.
Rookie mistake!!! You forgot surrogate pairs in UTF-16.
Which Ansi characters translate into
On Fri, Oct 21, 2011 at 9:25 AM, Graeme Geldenhuys
wrote:
> In fpGUI have have a fpgColorToRGBColor() - this will lookup and
> translate (if required) "color aliases" to real RGB values. If memory
> serves me right, Delphi (and probably Lazarus too) has a similar call?
> Try something like ColorTo
On Fri, Oct 21, 2011 at 9:47 AM, Paul Ishenin wrote:
> Why do you use Parent. ?
That's the whole reason why I have this problem at all. My control in
question here is TCDPageControl, which is a custom drawn page control,
therefore I have no background color of my own (although the user
might spec
On 10/20/2011 10:26 PM, Felipe Monteiro de Carvalho wrote:
Mac OS X uses the decomposed form in UTF-8 to store filenames, which
is rather unpleasant.
Why are they so silly ?
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
h
On 10/20/2011 05:49 PM, Mattias Gaertner wrote:
Often they say: Linux has problems with unicode. Reason: teachers
think that unicode is so simple under java, so they don't explain it.
I see. Obviously a similar problem as with Delphi. (If E. in fact (like
promised some time ago) creates a Delp
On 10/21/2011 08:56 AM, Graeme Geldenhuys wrote:
That is such a rubbish statement! More and more information is being
added outside the Unicode's BMP. Emoticons, Science and Maths symbols,
Map Symbols (often seen in GPS applications), Music notes etc etc.
Those who deal with this of course need
20.10.2011 23:57, Felipe Monteiro de Carvalho wrote:
Is there any easy way to obtain the color of a component taking into
considerating all the factors? aka, propagating ParentColor, resolving
clDefault, etc.
if AControl.Color = clDefault then
AColor := AControl.GetDefaultColor(dctBr
On 10/21/2011 09:03 AM, Graeme Geldenhuys wrote:
You forgot surrogate pairs in UTF-16. Think outside
the Unicode BMP where a "visible" character will be 4-bytes, thus two
UTF-16 Char values.
Regarding this, there seemingly is no help at all :( (I understand that
even in full 32 Unicode there are
On 10/20/2011 09:42 PM, Felipe Monteiro de Carvalho wrote:
Changing the size of Char is not just small detail, this breaks *a
lot* of code. Any kind of memory operations such as Move will fail
because the char size changed.
Of course you are right, but "move" and friends is "hardware-near
progr
On 10/20/2011 04:34 PM, Felipe Monteiro de Carvalho wrote:
Length does not give the number of chars? No problem:
As said: Of course this is no problem for those who do are aware that
they are dealing with Unicode and not with displayed characters. This of
course includes myself when doing new
On 2011-10-20 17:57, Felipe Monteiro de Carvalho wrote:
>
> I have my TCDPageControl on top of a form, but for
> TCDPageControl.Color I get just clDefault, which turns out to be
> black. =( using Parent.GetDefaultColor(dcBrush) also returned black in
> Windows...
In fpGUI have have a fpgColorToRG
On 2011-10-21 09:04, Alexander Shishkin wrote:
> SendInteger('$Param(data,Sync=1)|', $Param(data,Sync=1));
Awesome, thanks! That works perfectly under 0.9.30.x too. :-)
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/
--
_
21.10.2011 10:47, Graeme Geldenhuys пишет:
Hi,
I've setup a Code Templates 'lsi' (Logging with SendInteger(...)). When
I press Ctrl+J I would like the following to appear with the cursor
inside the first parameter of the SendInteger() call. Now the tricky
part. I would ideally also like to have
On 2011-10-21 00:20, Hans-Peter Diettrich wrote:
> your legacy code can assume that every (visible) character is a Char, in
> an SBCS codepage, this is not different in UTF-16.
Rookie mistake!!! You forgot surrogate pairs in UTF-16. Think outside
the Unicode BMP where a "visible" character will b
61 matches
Mail list logo
