[lazarus] New Bug Entered

[Mattias Gaertner]

On Mon, 14 Jul 2003 16:13:33 +0200 (W. Europe Daylight Time)
Michael Van Canneyt <michael.vancanneyt at wisa.be> wrote:

> [..]
> > > > One correct solution is to create better "empty procedures". This
> > > > means an empty procedure, with the right length of parameters. I'm
> > > > not sure how to do this for all kinds of calling conventions and
> > > > processors.
> > >
> > > You can't.
> >
> > Why that?
> 
> Because the callee clears the stack. This is unlike C, where the caller
> knows how much is pushed on the stack, and removes exactly this amount.
> in FPC, the caller expects a certain amount on the stack, and removes
> this amount from the stack, irrespective of whether this amount was
> indeed pushed or not.

Then you mean: You don't see a way to do this easily.
It will only be impossible, when a processor does not allow to execute code
in data mem.


> [..]
> >   MyDataModule.AnNotifyEvent:=TNotifyEvent(@MyDataModule.SimpleProc);
> >
> > A simple
> >
> > AnNotifyEvent(Self)
> >
> > works (at least on i386). But a
> >
> > try
> >   AnNotifyEvent(Self);
> > except
> > end;
> >
> > does not work.
> 
> Of course not, since the stack is messed up.
> The exact error will depend on the particular code.
> 
> The way I see it is that during design time, NO callbacks may be set.

Right. But NO really means NO. If an event is set at any time, it can be
called and destroy the stack.


> This also means that you must
> - After form load, replace all filled in event handlers with nil, and
>   keep a record of this.
> - In the object inspector, show the 'fake' record which you saved.
> - When creating new events, put them in fake records.
> - Before form saving, fill all callbacks again
> - after form saving clear them again.
> 
> The best way of doing it IMHO is to make descendents of the
> TReader/TWriter which do this automatically, and which also keep the
> list of 'fake' records.

Ok.
There are enough other good reasons to improve TReader/TWriter (better error
handling, interactive reading). But Borland wrote TReader/TWriter in a very
closed way. Not enough virtual methods and it uses a lot of private
variables. Of course we can use the workarounds you mentioned, but it would
be much nicer, to open TReader/TWriter for extensions.


Mattias