On 2013-07-02 15:55, Marco van de Voort wrote:
> Then when you got into trouble, your testsuite revealed this problem
> immediately?
Yes it did, and I promptly reported it to FPC. Somehow I thought [at
the time] FPC was "delphi compatible", as advertised. But I quickly
learned that "delphi compa
On Mon, Jul 01, 2013 at 01:09:39PM +0100, Graeme Geldenhuys wrote:
> On 30/06/13 23:33, Hans-Peter Diettrich wrote:
> >
> > Such coding style is asking for trouble :-(
> Hardly, but maybe our advanced applications and coding has moved past
> your level of knowledge of the language.
No, abusing n
That would be much clearer to use, if Pascal had scope local variables
and auto created stack objects:
begin
var x: SetBusyMouseCursorObject;
end;
That would also make the ref-counted classes at language level
unnecessary, because you could just use
type TObjectWithRefCounting=
On 30/06/13 23:33, Hans-Peter Diettrich wrote:
>
> Such coding style is asking for trouble :-(
Hardly, but maybe our advanced applications and coding has moved past
your level of knowledge of the language. That doesn't make us wrong or
"asking for trouble".
G.
--
__
On 01/07/13 05:36, Martin Schreiber wrote:
>>
> Working with autodestroyed objects is asking for trouble. ;-)
+1
:)
Regards,
- Graeme -
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/li
On 06/30/2013 08:14 PM, Florian Klämpfl wrote:
It matters when people make assumptions when the a temp.
If an interface indeed is used as an "interface" externally of the
program, Destroying it might result in a crash when the external program
writes something back to the interface object (b
On Monday 01 July 2013 00:33:43 Hans-Peter Diettrich wrote:
> Graeme Geldenhuys schrieb:
> > On 2013-06-30 17:25, Hans-Peter Diettrich wrote:
> >> I'm somewhat confused now. When an object has an definite "last use", it
> >> should not matter when it is destroyed afterwards, sooner or later.
> >
>
Florian Klämpfl schrieb:
Am 30.06.2013 18:25, schrieb Hans-Peter Diettrich:
Marco van de Voort schrieb:
On Sat, Jun 29, 2013 at 08:47:37PM -0400, waldo kitty wrote:
(Some versions of?) Delphi deallocate interfaces at the end of a
block of
procedures, not immediately after first usage.
first u
Graeme Geldenhuys schrieb:
On 2013-06-30 17:25, Hans-Peter Diettrich wrote:
I'm somewhat confused now. When an object has an definite "last use", it
should not matter when it is destroyed afterwards, sooner or later.
The simplest example... You have code that executes when the Interface
gets
On 2013-06-30 17:25, Hans-Peter Diettrich wrote:
> I'm somewhat confused now. When an object has an definite "last use", it
> should not matter when it is destroyed afterwards, sooner or later.
The simplest example... You have code that executes when the Interface
gets destroyed. A very simple e
On 2013-06-30 19:14, Florian Klämpfl wrote:
>
> It matters when people make assumptions when the a temp.
Yes, people like Embarcadero themselves (even though it is not
officially documented), or Embarcadero partners that ship products with
Delphi (think Raize's CodeSite etc).
I seriously doubt E
Am 30.06.2013 18:25, schrieb Hans-Peter Diettrich:
> Marco van de Voort schrieb:
>> On Sat, Jun 29, 2013 at 08:47:37PM -0400, waldo kitty wrote:
(Some versions of?) Delphi deallocate interfaces at the end of a
block of
procedures, not immediately after first usage.
>>> first usage or
On Sat, Jun 29, 2013 at 4:43 PM, Marcos Douglas wrote:
> On Fri, Jun 28, 2013 at 1:07 PM, Hans-Peter Diettrich
> wrote:
>> Graeme Geldenhuys schrieb:
>>
>>> On 2013-06-27 21:32, Hans-Peter Diettrich wrote:
I don't see how this is related to managed objects.
>>>
>>>
>>> If FPC implements
Marco van de Voort schrieb:
On Sat, Jun 29, 2013 at 08:47:37PM -0400, waldo kitty wrote:
(Some versions of?) Delphi deallocate interfaces at the end of a block of
procedures, not immediately after first usage.
first usage or last usage?
Last usage of course, sorry.
I'm somewhat confused now
On Sat, Jun 29, 2013 at 08:47:37PM -0400, waldo kitty wrote:
> > (Some versions of?) Delphi deallocate interfaces at the end of a block of
> > procedures, not immediately after first usage.
>
> first usage or last usage?
Last usage of course, sorry.
--
_
On 6/29/2013 14:51, Marco van de Voort wrote:
On Sat, Jun 29, 2013 at 12:14:35AM +0200, Hans-Peter Diettrich wrote:
There won't be any exact Delphi like implementation, because like with
interfaces it isn't documented _when exactly_ the reference count is
decreased.
It is decreased whenever a
On Fri, Jun 28, 2013 at 1:07 PM, Hans-Peter Diettrich
wrote:
> Graeme Geldenhuys schrieb:
>
>> On 2013-06-27 21:32, Hans-Peter Diettrich wrote:
>>>
>>> I don't see how this is related to managed objects.
>>
>>
>> If FPC implements managed objects, is it going to behave _exactly_ like
>> Delphi, or
On Sat, Jun 29, 2013 at 12:14:35AM +0200, Hans-Peter Diettrich wrote:
> > There won't be any exact Delphi like implementation, because like with
> > interfaces it isn't documented _when exactly_ the reference count is
> > decreased.
>
> It is decreased whenever a reference expires. Where do you
On 29.06.2013 00:14, Hans-Peter Diettrich wrote:
Sven Barth schrieb:
On 28.06.2013 16:49, Graeme Geldenhuys wrote:
On 2013-06-27 21:32, Hans-Peter Diettrich wrote:
I don't see how this is related to managed objects.
If FPC implements managed objects, is it going to behave _exactly_ like
Delp
Sven Barth schrieb:
On 28.06.2013 16:49, Graeme Geldenhuys wrote:
On 2013-06-27 21:32, Hans-Peter Diettrich wrote:
I don't see how this is related to managed objects.
If FPC implements managed objects, is it going to behave _exactly_ like
Delphi, or slightly different to Delphi - like what ha
Graeme Geldenhuys schrieb:
On 2013-06-27 21:32, Hans-Peter Diettrich wrote:
I don't see how this is related to managed objects.
If FPC implements managed objects, is it going to behave _exactly_ like
Delphi, or slightly different to Delphi - like what happened to the
Interfaces implementation.
On Thu, Jun 27, 2013 at 02:58:15PM +0200, Hans-Peter Diettrich wrote:
> > Java and C# don't count, as safe languages, they have _ONLY_ managed types.
> > Their choices will be hard to backport.
>
> Right. The idea sounds to me like the other half-baked attempts to
> introduce anonymous methods, c
On 28.06.2013 16:49, Graeme Geldenhuys wrote:
On 2013-06-27 21:32, Hans-Peter Diettrich wrote:
I don't see how this is related to managed objects.
If FPC implements managed objects, is it going to behave _exactly_ like
Delphi, or slightly different to Delphi - like what happened to the
Interfa
On 2013-06-27 21:32, Hans-Peter Diettrich wrote:
> I don't see how this is related to managed objects.
If FPC implements managed objects, is it going to behave _exactly_ like
Delphi, or slightly different to Delphi - like what happened to the
Interfaces implementation.
Regards,
- Graeme -
--
Graeme Geldenhuys schrieb:
On 2013-06-27 11:45, Hans-Peter Diettrich wrote:
Automatic reference counting works pretty well, doing it manually is
asking for trouble.
Sometimes it becomes trick (at least with reference counted interfaces).
eg: I have code where I pass a interface around, but don
Am 27.06.2013 22:11 schrieb "Hans-Peter Diettrich" :
>
> Marco van de Voort schrieb:
>
>> On Wed, Jun 26, 2013 at 05:59:06PM +0200, Hans-Peter Diettrich wrote:
Yeah, that change is going to be a nightmare to lots of existing code.
I
hope Delphi developers enjoy debugging!
>>>
>>> I d
Marco van de Voort schrieb:
On Wed, Jun 26, 2013 at 05:59:06PM +0200, Hans-Peter Diettrich wrote:
Yeah, that change is going to be a nightmare to lots of existing code. I
hope Delphi developers enjoy debugging!
I don't see any relationship to COM here. Java has managed objects, C++
has, .NET ha
On 2013-06-27 11:45, Hans-Peter Diettrich wrote:
>
> Automatic reference counting works pretty well, doing it manually is
> asking for trouble.
Sometimes it becomes trick (at least with reference counted interfaces).
eg: I have code where I pass a interface around, but don't want the
reference c
Graeme Geldenhuys schrieb:
On 2013-06-26 16:59, Hans-Peter Diettrich wrote:
I don't see any relationship to COM here. Java has managed objects, C++
has, .NET has, so why not OPL too?
I wasn't referring to COM explicitly. But having objects being freed
when the developer didn't expect it (beca
On 06/26/2013 05:59 PM, Hans-Peter Diettrich wrote:
I don't see any relationship to COM here.
Delphi "interfaces" mostly are seen as COM thingies, even though they
are just straight forward language constructs that _can_ be used to
attach to COM objects. but they can be happily be used for o
On Wed, Jun 26, 2013 at 09:12:42AM +0200, Michael Schnell wrote:
> On 06/25/2013 03:16 PM, Marco van de Voort wrote:
> > As far as I know that was all to be limited to their mobile offering.
> As stated earlier by several contributors, splitting the language into
> two separate branches for differ
On Wed, Jun 26, 2013 at 05:59:06PM +0200, Hans-Peter Diettrich wrote:
> > Yeah, that change is going to be a nightmare to lots of existing code. I
> > hope Delphi developers enjoy debugging!
>
> I don't see any relationship to COM here. Java has managed objects, C++
> has, .NET has, so why not OP
On 2013-06-26 16:59, Hans-Peter Diettrich wrote:
> I don't see any relationship to COM here. Java has managed objects, C++
> has, .NET has, so why not OPL too?
I wasn't referring to COM explicitly. But having objects being freed
when the developer didn't expect it (because that was not the behav
Graeme Geldenhuys schrieb:
On 26/06/13 07:19, Martin Schreiber wrote:
Because then classes work like COM interfaces. Shudder.
Yeah, that change is going to be a nightmare to lots of existing code. I
hope Delphi developers enjoy debugging!
I don't see any relationship to COM here. Java has m
Am 26.06.2013 09:08, schrieb Michael Schnell:
On 06/25/2013 03:14 PM, Sven Barth wrote:
Yes, it will merely be an empty method then.
If this really works and does not break anything, I wonder why this
has not been implemented since long...
There can be problems where the reference counting mech
On 26/06/13 07:19, Martin Schreiber wrote:
>>
> Because then classes work like COM interfaces. Shudder.
Yeah, that change is going to be a nightmare to lots of existing code. I
hope Delphi developers enjoy debugging!
Regards,
- Graeme -
--
___
Laz
Am 26.06.2013 08:08, schrieb Michael Schnell:
On 06/25/2013 03:14 PM, Sven Barth wrote:
Yes, it will merely be an empty method then.
If this really works and does not break anything, I wonder why this has
not been implemented since long...
Because then classes work like COM interfaces. Shudde
On 06/25/2013 03:16 PM, Marco van de Voort wrote:
As far as I know that was all to be limited to their mobile offering.
As stated earlier by several contributors, splitting the language into
two separate branches for different architectures seems like an utterly
bad idea. I do hope Lazarus will
On 06/25/2013 03:14 PM, Sven Barth wrote:
Yes, it will merely be an empty method then.
If this really works and does not break anything, I wonder why this has
not been implemented since long...
-Michael
--
___
Lazarus mailing list
Lazarus@lists.laza
On Thu, Jun 20, 2013 at 01:48:00PM +0200, Vincent Snijders wrote:
> > To build a 2-byte windows unit (and the new RTL),
> >
> > 1) checkout fpc/branches/unicode
> > 2) do a make cycle to get a fresh 2.7.1
> >
> I did a make all at the top level directory, which ignores my fpc.cfg
> (good) and calls
On Tue, Jun 25, 2013 at 09:23:14AM +0100, Graeme Geldenhuys wrote:
> So what platforms with the nextgen compiler target? OS X, iOS, Android,
> Windows Phone, Linux? All but Windows?
There is a note in the XE4 related documentation, that desktop
Delphi/nextgen will be compatible with the current si
On Mon, Jun 24, 2013 at 04:59:13PM +0200, Michael Schnell wrote:
> I just have been told that Embarcadero plans to do away with the stuff
> fpc is just implementing in the "Unicode branch" and is on the verge to
> change to a completely new String type that is
> - UTF-16-only,
> - Zero-Based,
Am 25.06.2013 11:04, schrieb Michael Schnell:
On 06/24/2013 05:14 PM, Hans-Peter Diettrich wrote:
They also make TObject reference counted...
I did read about this. So ".Free" is going to be obsolete ?
Yes, it will merely be an empty method then.
Regards,
Sven
--
___
Felipe Monteiro de Carvalho schrieb:
On Mon, Jun 24, 2013 at 5:14 PM, Hans-Peter Diettrich
wrote:
I just have been told that Embarcadero plans to do away with the stuff fpc
is just implementing in the "Unicode branch" and is on the verge to change
to a completely new String type that is
- UTF-
On 06/24/2013 09:25 PM, Michael Van Canneyt wrote:
AFAIK This is only for the new nextgen compiler, for the Win32 target,
nothing changes.
To me it makes absolutely no sense to force the programmers to use
different paradigms for different platforms. A decent programming system
should hide
On 06/24/2013 05:14 PM, Hans-Peter Diettrich wrote:
They also make TObject reference counted...
I did read about this. So ".Free" is going to be obsolete ?
When we can start implementing further changes, we should look whether
Delphi exists at all, at that time. I wouldn't hold my breath ;-)
On 2013-06-24 20:25, Michael Van Canneyt wrote:
>
> AFAIK This is only for the new nextgen compiler, for the Win32 target,
> nothing changes.
When you say Win32 do you mean Windows (as in 32 & 64-bit) or only
32-bit Windows?
So what platforms with the nextgen compiler target? OS X, iOS, Androi
On Mon, Jun 24, 2013 at 5:14 PM, Hans-Peter Diettrich
wrote:
>> I just have been told that Embarcadero plans to do away with the stuff fpc
>> is just implementing in the "Unicode branch" and is on the verge to change
>> to a completely new String type that is
>> - UTF-16-only,
>> - Zero-Based, a
On Mon, 24 Jun 2013, Michael Schnell wrote:
I just have been told that Embarcadero plans to do away with the stuff fpc is
just implementing in the "Unicode branch" and is on the verge to change to a
completely new String type that is
- UTF-16-only,
- Zero-Based, and
- immutable.
And thus com
Am 24.06.2013 16:59, schrieb Michael Schnell:
> I just have been told that Embarcadero plans to do away with the stuff
> fpc is just implementing in the "Unicode branch" and is on the verge to
> change to a completely new String type that is
> - UTF-16-only,
> - Zero-Based, and
> - immutable.
>
For the very little that it's worth, I abandoned Delphi (10) because I
was sick of Embarcadero's approach to strings at that time, which forced
a rework of *a lot* of my old code and components.
Adopted Lazarus and never looked back.
On 6/24/2013 10:14 AM, Hans-Peter Diettrich wrote:
Michael
Michael Schnell schrieb:
I just have been told that Embarcadero plans to do away with the stuff
fpc is just implementing in the "Unicode branch" and is on the verge to
change to a completely new String type that is
- UTF-16-only,
- Zero-Based, and
- immutable.
And thus completely incompatibl
I just have been told that Embarcadero plans to do away with the stuff
fpc is just implementing in the "Unicode branch" and is on the verge to
change to a completely new String type that is
- UTF-16-only,
- Zero-Based, and
- immutable.
And thus completely incompatible with any "String" Type e
2013/6/8 Marco van de Voort
>
> To build a 2-byte windows unit (and the new RTL),
>
> 1) checkout fpc/branches/unicode
> 2) do a make cycle to get a fresh 2.7.1
>
I did a make all at the top level directory, which ignores my fpc.cfg
(good) and calls make cycle in the compiler dir (good). It fail
Am 13.06.2013 21:23, schrieb Michael Van Canneyt:
On Thu, 13 Jun 2013, Marco van de Voort wrote:
On Thu, Jun 13, 2013 at 11:51:38AM +0200, Michael Van Canneyt wrote:
The problem is not in the compiler.
The problem is that IF your code assumes that WideString=UnicodeString
That is Delphi i
On Thu, Jun 13, 2013 at 09:23:59PM +0200, Michael Van Canneyt wrote:
> >> The problem is not in the compiler.
> >> The problem is that IF your code assumes that WideString=UnicodeString
> >
> > That is Delphi incompatble. Simply don't enable Delphi compatibility mode
> > then.
>
> Which Delphi ver
On Thu, 13 Jun 2013, Marco van de Voort wrote:
On Thu, Jun 13, 2013 at 11:51:38AM +0200, Michael Van Canneyt wrote:
The problem is not in the compiler.
The problem is that IF your code assumes that WideString=UnicodeString
That is Delphi incompatble. Simply don't enable Delphi compatibilit
On Thu, 13 Jun 2013, Marco van de Voort wrote:
On Thu, Jun 13, 2013 at 11:32:36AM +0200, Michael Van Canneyt wrote:
ObjFPC was encountered) and I added the FPC_OS_UNICODE define.
All the more reason not to try to emulate Delphi defines.
Why? We define "Windows" and "MSWindows" too?
Maybe
On Thu, Jun 13, 2013 at 11:32:36AM +0200, Michael Van Canneyt wrote:
> > ObjFPC was encountered) and I added the FPC_OS_UNICODE define.
>
> All the more reason not to try to emulate Delphi defines.
Why? We define "Windows" and "MSWindows" too?
Maybe not use "linux" because Kylix does ? :-)
> UNI
On Thu, Jun 13, 2013 at 11:51:38AM +0200, Michael Van Canneyt wrote:
>
> The problem is not in the compiler.
> The problem is that IF your code assumes that WideString=UnicodeString
That is Delphi incompatble. Simply don't enable Delphi compatibility mode
then.
--
_
On 06/13/2013 11:51 AM, Michael Van Canneyt wrote:
The problem is not in the compiler. The problem is that IF your code
assumes that WideString=UnicodeString
then you will need to differentiate the 2 cases.
I suppose you are correct. But if I understand correctly what my Delphi
addicted col
Am 13.06.2013 11:32, schrieb Michael Van Canneyt:
On Thu, 13 Jun 2013, Sven Barth wrote:
Am 12.06.2013 17:36, schrieb Michael Van Canneyt:
On Wed, 12 Jun 2013, Marco van de Voort wrote:
On Wed, Jun 12, 2013 at 10:55:24AM +0200, Michael Schnell wrote:
On 06/10/2013 08:55 AM, Michael Van
On Thu, 13 Jun 2013, Michael Schnell wrote:
On 06/13/2013 11:32 AM, Michael Van Canneyt wrote:
And they'll need defines anyway because widestring <> unicodestring on
windows.
The compiler does know whether it compiles for Windows or not. Doesn't it ?
The problem is not in the compiler.
On 06/13/2013 11:32 AM, Michael Van Canneyt wrote:
And they'll need defines anyway because widestring <> unicodestring on
windows.
The compiler does know whether it compiles for Windows or not. Doesn't it ?
-Michael
--
___
Lazarus mailing list
La
On Thu, 13 Jun 2013, Sven Barth wrote:
Am 12.06.2013 17:36, schrieb Michael Van Canneyt:
On Wed, 12 Jun 2013, Marco van de Voort wrote:
On Wed, Jun 12, 2013 at 10:55:24AM +0200, Michael Schnell wrote:
On 06/10/2013 08:55 AM, Michael Van Canneyt wrote:
Where is UNICODE defined ?
Isn'
Am 12.06.2013 17:36, schrieb Michael Van Canneyt:
On Wed, 12 Jun 2013, Marco van de Voort wrote:
On Wed, Jun 12, 2013 at 10:55:24AM +0200, Michael Schnell wrote:
On 06/10/2013 08:55 AM, Michael Van Canneyt wrote:
Where is UNICODE defined ?
Isn't the define "UNICODE" a heritage from Delp
On 06/12/2013 05:31 PM, Marco van de Voort wrote:
No. This is part of that, but only the most initial level. Much is not
yet decided.
... including how compatible it will be. (and more importantly, how
portable the compatibility will be)
As I followed (an took part in) several discussions on t
On 06/12/2013 05:36 PM, Michael Van Canneyt wrote:
Now why on earth would we do that ? We don't define VERXYZ either in
mode delphi ??
As, String-wise, Delphi (as of version xyz) is not compatible to itself,
IMHO it does make perfect sense to provide the $mode delphiunicode,
additional to
On 06/12/2013 05:29 PM, Marco van de Voort wrote:
Yes, and if you chose the explicit compatibility mode for that
version, $mode delphiunicode, it _is_ defined.
Great. I see my concerns about this kind of compatibility seem already
to be cared for.
Thanks !
-Michael
--
On Wed, 12 Jun 2013, Marco van de Voort wrote:
On Wed, Jun 12, 2013 at 10:55:24AM +0200, Michael Schnell wrote:
On 06/10/2013 08:55 AM, Michael Van Canneyt wrote:
Where is UNICODE defined ?
Isn't the define "UNICODE" a heritage from Delphi (> version xyz) ?
Yes, and if you chose the ex
On Wed, Jun 12, 2013 at 10:55:24AM +0200, Michael Schnell wrote:
> On 06/10/2013 08:55 AM, Michael Van Canneyt wrote:
> >
> > Where is UNICODE defined ?
> >
>
> Isn't the define "UNICODE" a heritage from Delphi (> version xyz) ?
Yes, and if you chose the explicit compatibility mode for that versi
On Wed, Jun 12, 2013 at 11:00:58AM +0200, Michael Schnell wrote:
> Is there already published (or somehow definable) road map for a
> string-wise Delphi XE compatible FPC / Lazarus combination ?
No. This is part of that, but only the most initial level. Much is not
yet decided.
... including ho
On 06/12/2013 02:39 PM, Michael Van Canneyt wrote:
Adding -dUNICODE on the fpc commandline is difficult ?
Not at all. A problem would arise, if fpc or Lazarus would define
UNICODE in _a_different_ way than Delphi does, and thus simply doing "
-dUNICODE" would be not allowed or not possible.
On Wed, 12 Jun 2013, Michael Schnell wrote:
On 06/12/2013 02:18 PM, Michael Van Canneyt wrote:
It is bad practice to rely in code on the defines defined by the compiler.
Of course I do know this (and many more similar portability-paradigms). But
my colleagues do coding only with Delphi (and
On 06/12/2013 02:18 PM, Michael Van Canneyt wrote:
It is bad practice to rely in code on the defines defined by the
compiler.
Of course I do know this (and many more similar portability-paradigms).
But my colleagues do coding only with Delphi (and thus Windows) in mind.
I can't help this. But
On Wed, 12 Jun 2013, Michael Schnell wrote:
On 06/12/2013 01:35 PM, Michael Van Canneyt wrote:
Add
{$IFDEF FPC}
{$DEFINE UNICODE}
{$ENDIF}
to your source, or, alternatively, fpc -dUNICODE
Both do the trick.
I'm not sure if this is the trick requested, as the target is to
automatical
On 06/12/2013 01:35 PM, Michael Van Canneyt wrote:
Add
{$IFDEF FPC}
{$DEFINE UNICODE}
{$ENDIF}
to your source, or, alternatively, fpc -dUNICODE
Both do the trick.
I'm not sure if this is the trick requested, as the target is to
automatically modify their source code in a way that it wor
On Wed, 12 Jun 2013, Michael Schnell wrote:
On 06/12/2013 11:10 AM, Michael Van Canneyt wrote:
Not necessarily. Compatible concerning Language/rtl functions, yes.
Defines, this is debatable.
I do know that my colleagues use "UNICODE" a lot when porting their (huge)
code-base from pre-Unico
On 06/12/2013 11:10 AM, Michael Van Canneyt wrote:
Not necessarily. Compatible concerning Language/rtl functions, yes.
Defines, this is debatable.
I do know that my colleagues use "UNICODE" a lot when porting their
(huge) code-base from pre-Unicode Delphi to Unicode aware Delphi versions.
So
On Wed, 12 Jun 2013, Michael Schnell wrote:
On 06/10/2013 08:55 AM, Michael Van Canneyt wrote:
Where is UNICODE defined ?
Isn't the define "UNICODE" a heritage from Delphi (> version xyz) ?
It has a different meaning.
I suppose FPC and Lazarus need to stay compatible on that behalf.
Is there already published (or somehow definable) road map for a
string-wise Delphi XE compatible FPC / Lazarus combination ?
I am eager to (finally !!) show my colleagues - who always use the
current Delphi release - a way to port their projects to Linux
-Michael
--
___
On 06/10/2013 08:55 AM, Michael Van Canneyt wrote:
Where is UNICODE defined ?
Isn't the define "UNICODE" a heritage from Delphi (> version xyz) ?
I suppose FPC and Lazarus need to stay compatible on that behalf.
-Michael
--
___
Lazarus mailing li
Am 11.06.2013 01:16 schrieb "Paul Ishenin" :
>
>
>
> 10.06.13, 23:20, Sven Barth пишет:
>
>
>> Nope, WinCE uses FPC_OS_UNICODE ;)
>
>
> Not in FPC 2.6.2 which must be supported by Lazarus too.
Of course not, because the WinCE target was only broken a few weeks ago.
There the define wasn't FPC_UNIC
10.06.13, 23:20, Sven Barth пишет:
Nope, WinCE uses FPC_OS_UNICODE ;)
Not in FPC 2.6.2 which must be supported by Lazarus too.
Best regards,
Paul Ishenin
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepa
Am 10.06.2013 15:31 schrieb "Paul Ishenin" :
>
> 10.06.2013 14:55, Michael Van Canneyt пишет:
>
>
>>> {$ifdef UNICODE}
>>> TResourceType = PWideChar;
>>> {$else}
>>> TResourceType = PChar;
>>> {$endif}
>>
>>
>> Where is UNICODE defined ?
>>
>> Because the RTL is compiled with the FPC_UNIC
On Mon, 10 Jun 2013, Paul Ishenin wrote:
08.06.2013 21:53, Marco van de Voort пишет:
During the recent FPC hackathon, Michael van Canneyt and I created a branch
to switch some RTL routines to unicode. (to be exact, rawbytestring and
unicodestring versions).
Does your branch also includes J
On Mon, 10 Jun 2013, Paul Ishenin wrote:
08.06.2013 21:53, Marco van de Voort пишет:
graphic.inc(155,66) Error: Incompatible type for arg no. 3: Got "PChar",
expected "PWideChar"
Stream := TResourceStream.CreateFromID(Instance, ResID, ResType);
ResType is of type TResourceType which is de
87 matches
Mail list logo
