> Marco,
>
> Let me see if I understand your concern...
>
> >>wxWindows is a good library/framework indeed. But why do we need a
> >>pascal interface to it ? It adds too many layers to the whole system.
> >>eg: to create a button => pascal-layer->wxWindows->gtk+/motif/win32->window system
>
Marco,
I'm not debating whether a feature should or should not be considered
for inclusion in FP. It just occurred to me that class attributes are
constructs that have *real* use beside just stylish correctness. Class
methods have been implemented, right? Aren't them just as equivalent to
glob
Mattias Gaertner wrote:
>
AFAIK the main reason, why the gtk interface for the LCL was started, was
simply, that the devels had experience with gtk, but no one had experience
with wxWindows.
I'm stretching my memory here but as Marco indicated, wxWindows wasn't
mature at the time. Also if I remem
> Object Pascal in son eclusively Borland
Translateion - "Object Pascal is not exclusivly Borland"... um yeah, new
keyboard people ;-)
> Afaik is Object Pascal an Apple invention, which was submitted as dratf
> standard for standarisation
Sure, that is why I said they 'originated' the *Delphi*
> > ok, another feature not found in Object Pascal!
>
> Be careful here... FPC implements Object Pascal too. Say 'Delphi' if you
> mean Delphi. Object Pascal in son eclusively Borland (though they originated
> it in it's Delphi instance.)
Afaik is Object Pascal an Apple invention, which was submi
> > same thing more or less.
> >
> > Both can be solved properly, and personally I find the
> > workaround presented in the article uglier than the simple
> > variable in the implementation of the unit.
> >
> >
>
> I think you missed the point of the article. I had no intention
> to list
On Thu, 13 Nov 2003 16:01:56 +0100 (W. Europe Standard Time)
Michael Van Canneyt <[EMAIL PROTECTED]> wrote:
>
>
> On Thu, 13 Nov 2003, Marco van de Voort wrote:
>
> > > On Thu, 13 Nov 2003, Marco van de Voort wrote:
> >
> > > > The LCL is much more than a widget set. It is the base building
> >
> ok, another feature not found in Object Pascal!
Be careful here... FPC implements Object Pascal too. Say 'Delphi' if you
mean Delphi. Object Pascal in son eclusively Borland (though they originated
it in it's Delphi instance.)
Matt
___
fpc-pascal
> There are some extensions yes, and in the future, foreign
> OSes and processors might cause some more extensions.
>
> However in general we reluclantly add features, usually
> because the main argument from most people is "it would
> be nice to have ", and there are many more reasons
> n
>> As to that, the answer is simple: RTTI for all objects would
>> blow up your executable. RTTI information takes up a *lot* of
>> space in your executable. It's a burden, and people who don't
>> need it should have the chance not to use it. This is impossible
>> if you force RTTI in TObject.
>
>
Michael,
> As to that, the answer is simple: RTTI for all objects would
> blow up your executable. RTTI information takes up a *lot* of
> space in your executable. It's a burden, and people who don't
> need it should have the chance not to use it. This is impossible
> if you force RTTI in TOb
> RTTI is enabled by a switch {$M+} and it is also inherited
> by descendant classes.
Just like Object Pascal...
> That is already supported by an fpc extension allowing
> static members. Just add the static directive after the
> field.
ok, another feature not found in Object Pascal!
Thanks,
On Thu, 13 Nov 2003, Marco van de Voort wrote:
> > On Thu, 13 Nov 2003, Marco van de Voort wrote:
>
> > > The LCL is much more than a widget set. It is the base building block of a
> > > RAD system. And also it quite Delphi VCL compatible in spirit (to allow easy
> > > porting).
> > >
> > > More
> On Thu, 13 Nov 2003, Marco van de Voort wrote:
> > The LCL is much more than a widget set. It is the base building block of a
> > RAD system. And also it quite Delphi VCL compatible in spirit (to allow easy
> > porting).
> >
> > Moreover wxWindows is relatively recent. It wasn't around in a stab
> I see that many responses refer to Delphi compatibility. I understand
> that the FP compiler has a switch that tells it to compile the pascal
> code as Delphi code. In that sense, I'd expect FP to provide a superset
> of the Object Pascal dialect. And that is true indeed!
There are some exten
On Thu, 13 Nov 2003, Demian Lessa wrote:
> Peter,
>
> Thanks for clearing things a little further!
>
> I see that many responses refer to Delphi compatibility. I understand
> that the FP compiler has a switch that tells it to compile the pascal
> code as Delphi code. In that sense, I'd expect FP
On Thu, 13 Nov 2003, Marco van de Voort wrote:
> > Marco,
> >
> > Let me see if I understand your concern...
>
> Most of the things you replied to aren't my comments, anyway.
>
> > >>wxWindows is a good library/framework indeed. But why do we need a
> > >>pascal interface to it ? It adds too man
> Peter,
>
> Thanks for clearing things a little further!
>
> I see that many responses refer to Delphi compatibility. I understand
> that the FP compiler has a switch that tells it to compile the pascal
> code as Delphi code. In that sense, I'd expect FP to provide a superset
> of the Object Pasca
> Marco,
>
> Let me see if I understand your concern...
Most of the things you replied to aren't my comments, anyway.
> >>wxWindows is a good library/framework indeed. But why do we need a
> >>pascal interface to it ? It adds too many layers to the whole system.
> >>eg: to create a button => p
Peter,
Thanks for clearing things a little further!
I see that many responses refer to Delphi compatibility. I understand
that the FP compiler has a switch that tells it to compile the pascal
code as Delphi code. In that sense, I'd expect FP to provide a superset
of the Object Pascal dialect.
Marco,
Let me see if I understand your concern...
wxWindows is a good library/framework indeed. But why do we need a
pascal interface to it ? It adds too many layers to the whole system.
eg: to create a button => pascal-layer->wxWindows->gtk+/motif/win32->window system window.
How does LCL work
> > Free Pascal Compiler version 1.9.1
> >
> > Compiler Date : 2003/11/11
> > Compiler Target: i386
> >
> > on FreeBSD
> > So it could be it that is already fixed after 1.9.0
> Great, :-)
> One more question, where can I find the version 1.9.1 ?
Versions with an odd third numbers are development
> Hmm, here it returns
>
> -bash-2.05b$ ./bugtest
> TMyObject
> -bash-2.05b$
>
> with
>
> Free Pascal Compiler version 1.9.1
>
> Compiler Date : 2003/11/11
> Compiler Target: i386
>
> on FreeBSD
> So it could be it that is already fixed after 1.9.0
Great, :-)
One more question, where can I find th
> When porting a Kylix/Delphi project to FPC (version 1.9.0 Linux) I've
> encountered this small problem using class methods:
> When I pass an object instance as parameter in class methods I have a
> sigsev
> like in this example
>
> Am I doing something wrong or is a bug I've found?
It was a bug
> When porting a Kylix/Delphi project to FPC (version 1.9.0 Linux) I've
> encountered this small problem using class methods:
> When I pass an object instance as parameter in class methods I have a sigsev
> like in this example
Hmm, here it returns
-bash-2.05b$ ./bugtest
TMyObject
-bash-2.05b$
When porting a Kylix/Delphi project to FPC (version 1.9.0 Linux) I've
encountered this small problem using class methods:
When I pass an object instance as parameter in class methods I have a sigsev
like in this example
program TestFail;
uses
SysUtils;
Type
TMyObject = Class
private
Hello again -
Still testing the new 1.9.0 beta compiler (Win32), I have come across
another issue which is much easier to demonstrate:
Take the following program:
program asmtest;
procedure myasmstuff;
var
BOB : dword;
begin
asm
mov eax,BOB
xor eax,eax
mov BOB,ea
> wxWindows is a good library/framework indeed. But why do we need a pascal interface
> to it ? It adds too many layers to the whole system.
> eg: to create a button => pascal-layer->wxWindows->gtk+/motif/win32->window system
> window.
>
> Do we really need these layers ? (wrapper wrapping a wr
>>> #2. Does the exception handling architecture provide easy
>>> to the call stack and other potentially useful information
>>> about the exception?
Yes, the frame pointer is passed
>>>
>>> #3. Is there (planned) support for object serialization?
>>>
>>> #4. Is there (planned) support for obje
29 matches
Mail list logo
