Aaron wrote:
> I know why it fails... This doesn't remove the fact that our
> application depends
> far too much upon this working that it has (for now) stopped any
> investigation
> into designing around a plugin architecture - shame really
> because it would
> be a powerful bonus for us...
Ah, I see.
> > 1) You can use packages. When Delphi introduced packages they
> added an extra
> > level of indirection into the parent TClass VMT pointer chain.
> You can see
> > this by comparing the pre-packages Delphi System.pas code with
> the current
> > System.pas code.
>
> > 2) Without packages, you can implement your own 'is' style
> operator which
> > compares via _ClassNames_ (i.e. strings), not via TClass values
> (i.e. VMT
> > pointers). This will succeed even across an EXE/DLL boundary.
> It will be a
> > bit slower that Delphi's hand-tuned assembler VMT pointer version but it
> > _will_ work.
>
> Solution 2 is trivial but cumbersome...
Yes. You could wrap all your is calls into a IsClass method which resolves
to a simple 'is' test or a DLL safe ClassName version depending on an
{$IFDEF}. But I gather you must have a lot of these tests.
> What are the pros and cons of packages... I understand that
> packages introduce a
> fairly heavy memory overhead - is this true for compiletime and
> run-time packages?
I'm not aware of any significant memory overhead for packages over that of
normal DLLs. As far as I understand it, they essentially _are_ normal DLLs
with a little bit of extra initialization magic. The TClass redirection and
like is already there in all EXEs as of right now, packages or not.
I'd be interested to know of anything to the contrary. Is it in the docs?
AFAIK, the only cons to packages are if you have patched your VCL source
since you'll need to build and distribute your _own_ VCL run-time packages
(with different names) which you link against but I don't think that is such
a huge deal.
TTFN,
Paul.
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
