On Mon, 16 Apr 2007 08:49:53 +0200
Mattias Gaertner <[EMAIL PROTECTED]> wrote:
> On Mon, 16 Apr 2007 08:01:07 +0200
> Vincent Snijders <[EMAIL PROTECTED]> wrote:
>
> > Mattias Gaertner schreef:
> > > On Sun, 15 Apr 2007 23:01:28 +0200
> > > Vincent Snijders <[EMAIL PROTECTED]> wrote:
> > >
> > >> Questions:
> > >> * Is this code actually to be executed? Was it designed so that
> > >> the IDE could execute this code at design time? I think the
> > >> answer is yes.
> > >
> > > Short answer: yes
> > > Long answer: It is the really dirty hack in the IDE.
> > > It was done, because assigning a 'real' TMethod to an event has
> > > the advantage that all OI, RTTI and all streaming code work
> > > without hacks or additions.
> >
> > As expected.
> >
> > >
> > >
> > >> * I tested on windows XP 64. Does anybody know if the 64 bits
> > >> version of windows works differently in this respect than the 32
> > >> bits version? For example does it proctect the memory on the heap
> > >> from execution?
> > >
> >
> > Does anybody else *know* this? I am just guessing about the actual
> > cause of the crash.
> >
> > I did an additional test. I replaced
> > Result.Code:=NewCode;
> > by
> > Result.Code:=CodeTemplate;
> > in TJITComponentList.CreateNewMethod. This fixed the crashes (but
> > probably breaks something else).
Yes. Events become readonly.
> > > If yes, then it is finally time to use the Delphi half Assigned
> > > trick and to check and extend the whole OI, RTTI and Streaming
> > > code to support this.
> >
> > How hard is this?
>
> I'm not sure. Probably a good day work. The main problem could be FPC.
>
>
> > Can you explain the half Assigned trick? Or is it
> > faster for you to implement it. ;-)
>
> The trick itself is easy:
> TMethod contains two pointers: code (the address) and data (the
> TObject). Normally you assign both and everything works normally. But
> if you set only one of them nil, then the test "AMethod<>nil"
> still is true, but "Assigned(AMethod)" gives false.
> If all components always use "if Assigned(AMethod) then AMethod(...)",
> then this trick prevents calling the method at designtime, while still
> holding a pointer. The pointer can be used by the IDE to know, which
> method name to stream.
> I don't remember which of the pointers are set to nil by Delphi.
> A quick test revealed: FPC's Assigned does not support this.
On a second test: FPC works great. The <>nil works just the same as
Assigned, which is IMHO even better. We can store a pointer in "data"
and keep "code" nil.
> What needs to be changed:
> FPC's Assigned, TReader, TWriter, TMethodPropertyEditor, jitforms and
> all other places where AMethod.Code and AMethod.Data is used.
>
> Of course this trick works only for methods, not procedures.
The question is: Do we want to support procedures? AFAIK no component uses it.
> There are two alternatives:
> 1. set all events to nil and extend TReader and friends to use some
> highly sophisticated method lookup.
> 2. Do it like msegui and add a
> not (csdesigning in componentstate)
> to every method check in every component. (not Delphi compatible)
Mattias
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
