On 10/14/2011 05:22 PM, Martin Schreiber wrote:
I understand that this is exactly what Delphi-type runtime packages are
invented for.
and Lazarus-type packages can't do.
Obviously, AFAIK, this never has been claimed, but that there have been
requests for loadable binary plug-in type runtime
On 10/13/2011 08:51 PM, Craig Peterson wrote:
http://community.devexpress.com/blogs/ctodx/archive/2011/09/19/delphi-vcl-is-dead-long-live-firemonkey.aspx
One thing that needs to be considered about FireMonkey and similar
application internal Widget Sets is that they don't integrate well
Craig Peterson schrieb:
In Delphi XE2 on OS X AnsiString does *not* map to UTF-8. On an English
system it maps to Windows-1252. If you want to convert an array of
AnsiChar to a WideString you need to cast it as a UTF8String first. By
default DefaultSystemCodePage is 1252, not 65001.
On 10/14/2011 10:30 AM, Hans-Peter Diettrich wrote:
- and start implementing a new FireMonkey component library,
independent from the LCL.
Is this really necessary ? FireMonkey is a rebranded open source
library, so it should be possible just to _use_ it.
OTOH, (I don't have XE2): does XE2
On 10/14/2011 10:30 AM, Hans-Peter Diettrich wrote:
BTW2, the Lazarus IDE has big problems with the lack of dynamically
loadable packages, which still are *not* supplied by FPC. This will
possibly make impossible above separation between the IDE
implementation and FPC progress. Wouldn't it
On Friday 14 October 2011 14.19:35 Michael Schnell wrote:
On 10/14/2011 10:30 AM, Hans-Peter Diettrich wrote:
BTW2, the Lazarus IDE has big problems with the lack of dynamically
loadable packages, which still are *not* supplied by FPC. This will
possibly make impossible above separation
Am 14.10.2011 14:07, schrieb Michael Schnell:
On 10/14/2011 10:30 AM, Hans-Peter Diettrich wrote:
- and start implementing a new FireMonkey component library,
independent from the LCL.
Is this really necessary ? FireMonkey is a rebranded open source
library, so it should be possible just to
On 10/14/2011 02:51 PM, Martin Schreiber wrote:
Ever tried to implement a form or any function which uses dynamic types or
common application elements in a dll/so?
I understand that this is exactly what Delphi-type runtime packages are
invented for.
-Michael
On Friday 14 October 2011 15.42:38 Michael Schnell wrote:
On 10/14/2011 02:51 PM, Martin Schreiber wrote:
Ever tried to implement a form or any function which uses dynamic types
or common application elements in a dll/so?
I understand that this is exactly what Delphi-type runtime packages
On 13 Oct 2011, at 20:51, Craig Peterson wrote:
BTW, I wanted to point out, to anyone arguing for full Delphi compatibility,
that on OS X Delphi's DefaultSystemCodePage and AnsiString(0) are *not* the
system encoding _or_ UTF-8. They're the Windows ANSI codepages that
correspond to the
Hello,
Posting here as this was requested in the bug report:
http://bugs.freepascal.org/view.php?id=20473
I think it is very simple: Having such a directive would save a lot of
work when porting Lazarus-based projects to FPC 2.7
--
Felipe Monteiro de Carvalho
Am 13.10.2011 09:29, schrieb Felipe Monteiro de Carvalho:
Hello,
Posting here as this was requested in the bug report:
http://bugs.freepascal.org/view.php?id=20473
I think it is very simple: Having such a directive would save a lot of
work when porting Lazarus-based projects to FPC 2.7
1.
13.10.2011 15:29, Felipe Monteiro de Carvalho пишет:
Hello,
Posting here as this was requested in the bug report:
http://bugs.freepascal.org/view.php?id=20473
I think it is very simple: Having such a directive would save a lot of
work when porting Lazarus-based projects to FPC 2.7
Wrote to
On Thu, Oct 13, 2011 at 9:43 AM, Sven Barth pascaldra...@googlemail.com wrote:
1. Currently there is this huge work going on to get trunk to a reasonable
and usable shape again and until that is done (and maybe RTL changes as
well) it is (in my opinion (!) ) not reasonable to think about
On Thu, Oct 13, 2011 at 9:44 AM, Paul Ishenin i...@kmiac.ru wrote:
The later can be made by call SetMultiByteConversionCodePage(CP_UTF8) at the
program start.
From my comment on the bug report:
Won't SetMultyByteConversionCodePage inadvertedly affect 3rd party
libraries used by the program
In our previous episode, Felipe Monteiro de Carvalho said:
RTLString = string;
It would not need to be used anywhere in the RTL, but files which use
the utf8string directive can use this string type to reffer to the RTL
string type.
How do you override classes that are declared in RTLString
13.10.2011 16:14, Felipe Monteiro de Carvalho wrote:
On Thu, Oct 13, 2011 at 9:44 AM, Paul Ishenini...@kmiac.ru wrote:
The later can be made by call SetMultiByteConversionCodePage(CP_UTF8) at the
program start.
From my comment on the bug report:
Won't SetMultyByteConversionCodePage
On Thu, Oct 13, 2011 at 10:26 AM, Paul Ishenin i...@kmiac.ru wrote:
It will affect as well as compiler directive you suggested to add.
No, the directive is per source code file. 3rd party libraries do not
need to use it.
--
Felipe Monteiro de Carvalho
On 10/13/2011 09:43 AM, Sven Barth wrote:
1. Currently there is this huge work going on to get trunk to a
reasonable and usable shape again and until that is done (and maybe
RTL changes as well) it is (in my opinion (!) ) not reasonable to
think about changing the meaning of string at all.
Am 13.10.2011 10:39, schrieb Michael Schnell:
The last FPC version I installed was Free Pascal Compiler version 2.7.1
[2011/08/26] for i386. /usr/bin/ppc383 points to
../lib/fpc/2.7.1/ppc386.
So, when installing a Unicode enabled it might be a good idea to do this
to a separate subdirectory in
In our previous episode, Felipe Monteiro de Carvalho said:
I dont fully understand your question, but lets suppose this RTL file:
unit system;
{$mode string = banana}
type RTLString = string;
unit classes;
{$mode string = banana}
type
TWhaeverClass = class
procedure Do(Param:
On 10/13/2011 10:39 AM, Sven Barth wrote:
When installing you can always select a custom directory though you
can not change the version-id. E.g. you could install to
/lib/fpc-cpstring/2.7.1.
Of course I do know how to install FPC in another directory or how to
preserve the current
On Thu, Oct 13, 2011 at 10:47 AM, Marco van de Voort mar...@stack.nl wrote:
But I don't consider this as solution. You have to put each string type in
the entire libraries on trial, and keep it up.
Could you explain more? Which libraries are you talking about? As I
showed, nothing would need to
Am 13.10.2011 11:02, schrieb Felipe Monteiro de Carvalho:
On Thu, Oct 13, 2011 at 10:47 AM, Marco van de Voortmar...@stack.nl wrote:
But I don't consider this as solution. You have to put each string type in
the entire libraries on trial, and keep it up.
Could you explain more? Which
On Thu, Oct 13, 2011 at 11:24 AM, Sven Barth
pascaldra...@googlemail.com wrote:
I think he ment that if such a feature is introduced it would be a natural
conclusion to define string = unicodestring on Windows and string =
utf8string for Unix in the RTL and the FCL
? I am totally lost as to
On Thu, 13 Oct 2011, Felipe Monteiro de Carvalho wrote:
On Thu, Oct 13, 2011 at 11:24 AM, Sven Barth
pascaldra...@googlemail.com wrote:
I think he ment that if such a feature is introduced it would be a natural
conclusion to define string = unicodestring on Windows and string =
utf8string
In our previous episode, Felipe Monteiro de Carvalho said:
[ Charset ISO-8859-1 unsupported, converting... ]
On Thu, Oct 13, 2011 at 10:47 AM, Marco van de Voort mar...@stack.nl wrote:
But I don't consider this as solution. You have to put each string type in
the entire libraries on trial,
On Thu, Oct 13, 2011 at 11:34 AM, michael.vancann...@wisa.be wrote:
In short, you want a directive to say
In this unit, 'string' means MyNiceStringType
Which is in fact an extension of the current {$H} to a more general case ?
yes
--
Felipe Monteiro de Carvalho
On Thu, Oct 13, 2011 at 11:38 AM, Felipe Monteiro de Carvalho
felipemonteiro.carva...@gmail.com wrote:
On Thu, Oct 13, 2011 at 11:34 AM, michael.vancann...@wisa.be wrote:
In short, you want a directive to say
In this unit, 'string' means MyNiceStringType
Which is in fact an extension of the
On Thu, 13 Oct 2011, Felipe Monteiro de Carvalho wrote:
On Thu, Oct 13, 2011 at 11:38 AM, Felipe Monteiro de Carvalho
felipemonteiro.carva...@gmail.com wrote:
On Thu, Oct 13, 2011 at 11:34 AM, michael.vancann...@wisa.be wrote:
In short, you want a directive to say
In this unit, 'string'
On Thu, Oct 13, 2011 at 11:45 AM, michael.vancann...@wisa.be wrote:
Well, if we add such a beast, it won't be just for UTF-8.
Lazarus happens to be UTF-8 centric, but that doesn't mean we should limit
the use of such a feature to UTF-8...
An addendum to that: We also need the normal PChar.
Am 13.10.2011 11:28, schrieb Felipe Monteiro de Carvalho:
On Thu, Oct 13, 2011 at 11:24 AM, Sven Barth
pascaldra...@googlemail.com wrote:
I think he ment that if such a feature is introduced it would be a natural
conclusion to define string = unicodestring on Windows and string =
utf8string
On Thu, Oct 13, 2011 at 11:51 AM, Sven Barth
pascaldra...@googlemail.com wrote:
In one of your mails you had the example of the units system and classes
which define string as aliased to the string type banana
Ah, that was not ment to be interpreted like that ... I just wanted to
say that in
13.10.2011 13:34, michael.vancann...@wisa.be пишет:
On Thu, 13 Oct 2011, Felipe Monteiro de Carvalho wrote:
On Thu, Oct 13, 2011 at 11:24 AM, Sven Barth
pascaldra...@googlemail.com wrote:
I think he ment that if such a feature is introduced it would be a
natural
conclusion to define string
Am 13.10.2011 11:49, schrieb Felipe Monteiro de Carvalho:
On Thu, Oct 13, 2011 at 11:45 AM,michael.vancann...@wisa.be wrote:
Well, if we add such a beast, it won't be just for UTF-8.
Lazarus happens to be UTF-8 centric, but that doesn't mean we should limit
the use of such a feature to
Am 13.10.2011 11:53, schrieb Alex Shishkin:
another alternative. in {$H-} no changes string=shortstring, in {$h+}
string = ansistring or unocodestring in delphiunicode mode) by default
but can be redefined directly in code (or this definition is set in
ObjPas unit) type string =
On Thu, 13 Oct 2011, Alex Shishkin wrote:
13.10.2011 13:34, michael.vancann...@wisa.be пишет:
On Thu, 13 Oct 2011, Felipe Monteiro de Carvalho wrote:
On Thu, Oct 13, 2011 at 11:24 AM, Sven Barth
pascaldra...@googlemail.com wrote:
I think he ment that if such a feature is introduced it
Am 13.10.2011 11:57, schrieb Marco van de Voort:
In our previous episode, Sven Barth said:
I think he ment that if such a feature is introduced it would be a
natural conclusion to define string = unicodestring on Windows and
string = utf8string for Unix in the RTL and the FCL (and maybe string
On Thu, 13 Oct 2011, Marco van de Voort wrote:
In our previous episode, Sven Barth said:
I think he ment that if such a feature is introduced it would be a
natural conclusion to define string = unicodestring on Windows and
string = utf8string for Unix in the RTL and the FCL (and maybe string
On Thu, 13 Oct 2011, Sven Barth wrote:
Am 13.10.2011 11:57, schrieb Marco van de Voort:
In our previous episode, Sven Barth said:
I think he ment that if such a feature is introduced it would be a
natural conclusion to define string = unicodestring on Windows and
string = utf8string for
On 10/13/2011 11:45 AM, michael.vancann...@wisa.be wrote:
Lazarus happens to be UTF-8 centric
I understand, this is because it had been impossible for them to support
as well UTF-8 for Linux as UTF-16 for Windows,
With the new code page aware Strings it should be possible to compile
the
In our previous episode, Sven Barth said:
the utf* designates the type of the default string type. And the same for
unix. Maybe win32-ansi too.
Ok... that you want multiple distributions per platform is clear now.
But you would not oppose (in the case of having multiple distributions)
Am 13.10.2011 12:13, schrieb Marco van de Voort:
In our previous episode, Sven Barth said:
the utf* designates the type of the default string type. And the same for
unix. Maybe win32-ansi too.
Ok... that you want multiple distributions per platform is clear now.
But you would not oppose (in
In our previous episode, michael.vancann...@wisa.be said:
2. Try a blanket {$H} to make the default stringtype what you want, and fix
problems (e.g. overrides of methods, passing to var params).
The blanket {$H} seems like the way to go for most packages.
If we insert {$H ANSISTRING},
In our previous episode, Sven Barth said:
The difference is more that I don't think it will solve as much as people
think, and using this to stitch together code from different origins will
fail miserably or be unworkable.
For non-inheritance-related code that is encoding-agnostic this
On Thu, Oct 13, 2011 at 11:54 AM, Sven Barth
pascaldra...@googlemail.com wrote:
Out of curiosity: how did you come to that conclusion? According to what I
read in rtl/inc/systemh.inc PChar is still defined as an ^Char and
further down is also an alias AnsiChar = Char, so PChar should still be
In our previous episode, Felipe Monteiro de Carvalho said:
Out of curiosity: how did you come to that conclusion? According to what I
read in rtl/inc/systemh.inc PChar is still defined as an ^Char and
further down is also an alias AnsiChar = Char, so PChar should still be
and behave the
In our previous episode, michael.vancann...@wisa.be said:
The more procedural packages yes. The OOP ones not, since their stringtype
must match classes for overrides.
Yes, but
1. this is the smallest group, so I don't consider that a problem.
Only in number of packages.
2. I doubt
On Thursday 13 October 2011 13.41:24 Marco van de Voort wrote:
It's time to cut the gordian knot and take a decision.
All pros and contras have been discussed at great length meanwhile.
Exactly. That's why a decision that is futureproof should be made, and not
just start hacking, and see
In our previous episode, Martin Schreiber said:
Suggestion: Let it be as it is in fixes_2_6, add support for Unicode
resource strings and invest power into development of Delphi like packages
for example.
That is already not an option anymore, with the newstr branch merged in.
And while that
Ok, so after summing in all of this problems which we are facing, I
will withdraw all of my previous ideas and agree with you Marco. If
FPC can produce a RTL mode where string=utf8string then I agree
Lazarus should try to use this UTF-8 RTL.
--
Felipe Monteiro de Carvalho
On Thursday 13 October 2011 13.56:50 Marco van de Voort wrote:
In our previous episode, Martin Schreiber said:
Suggestion: Let it be as it is in fixes_2_6, add support for Unicode
resource strings and invest power into development of Delphi like
packages for example.
Or improved
In our previous episode, Martin Schreiber said:
And while that is an option for you, it doesn't satisfy anybody else. Not
even the ones that want as close to D2009 compatibility as possible, since
they also need the new ansistring type here and there.
Hm, even Embarcadero can live
13.10.2011 16:30, Felipe Monteiro de Carvalho wrote:
On Thu, Oct 13, 2011 at 10:26 AM, Paul Ishenini...@kmiac.ru wrote:
It will affect as well as compiler directive you suggested to add.
No, the directive is per source code file. 3rd party libraries do not
need to use it.
Then use {$codepage
On 10/13/2011 4:36 AM, Marco van de Voort wrote:
Plus, isn't Embarcadero pushing FireMonkey anyway?
I don't see it that way. I see FM as a Delphi PHP/3rd Rail/Prism like
product, not as serious VCL contender. If I understood it correctly, it is
mostly a sideproduct of internal efforts to port
In our previous episode, Craig Peterson said:
Plus, isn't Embarcadero pushing FireMonkey anyway?
I don't see it that way. I see FM as a Delphi PHP/3rd Rail/Prism like
product, not as serious VCL contender. If I understood it correctly, it is
mostly a sideproduct of internal efforts to
On 10/13/2011 2:03 PM, Marco van de Voort wrote:
No backwards compatibility, no native ties to tie it down. Clearly it is
meant to be fast moving by skipping details. And that doesn't appeal to the
bulk of the Delphi crowd
They're so far behind they pretty much have to run fast and loose.
I'm
57 matches
Mail list logo
