Dennis wrote:
> > > 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...
>
> "Solution 2" is not really trivial. It will not work if 2
> classes share the
> same name but are different. Eg., I can create a TMenu class in
> unit X and
> pass that to the DLL. It will not be able to tell if that class is TMenu
> from the VCL or my TMenu class.
Um, well, at the risk of being flippant: 'Don't do that then'.
Even aside from the 'is' via ClassName issue, a lot of DLL entry point
linkage is still based on name resolution (as opposed to ordinals) so you're
asking for trouble.
To be frank, if you're going to pollute your namespace with different
concepts and classes with the same name, DLL/EXE issues are going to be only
one of your worries. Trying to have someone else maintain or grok that
project is potentially rather tricky.
Having to say things like 'No, I meant the other TMenu' is not that
different from giving directions involving statments like 'Sorry, I meant
the other left' :-)
TTFN,
Paul.
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
