[lazarus] New Bug Entered

[Mattias Gaertner]

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

> 
> 
> On Mon, 14 Jul 2003, Mattias Gaertner wrote:
> 
> > 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.
> 
> Yes, but implementing such things is very bad coding IMHO.
> 
> >
> >
> > > [..]
> > > >   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.
> 
> Normally not, as the compiler should do type cheking on assignment
> statements. It's only because this 'TMethod' record is used that the type
> checking is lost.

Yes, and therefore we can't set/unset events for reading/writing.

 
> > > 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.
> 
> I'm all for that. Feel free to propose/implement improvements.

I'm busy at the moment. I will have time for that in a month. I hope lazarus
will then also work again with fpc 1.1.


Mattias