We have a plugin mechanism that we are using the DLLs for. We looked at BPLs when we were starting out with the plugin mechanism. The biggest problem with them was that if a unit changed that was shared by multiple BPLs and/or the main app, then all of them needed to be updated which kind of defeated one of the purposes of the plugin system that allowed smaller update downloads for just the plugins that have been changed.
We also use interfaces a little bit, but did not want to build our plugin architecture on them either since a new method/property on an underlying object requires either a new iterface to be added, or the existing one changed which then requires, again, that all plugins that use that changed interface, and the main app, need to be updated. With approx 10000 users we could just imagine the support nightmare as people somehow ended up with BPLs or interfaces that were out of sync! In case anyone is interested (probably not) - in the end we built more of a script-like mechanism for plugins. That way a plugin only needs to respond to events/commands that it supports (the script commands are versioned) and likewise the app can ignore requests that it doesn't support. Seems to be working OK so far, although as you can see from the original thread post, there are issues that need working around. I suppose you could use the same "either supports it or doesn't" approach with interfaces also, but trying to provide our current functionality with interfaces is a daunting task - there are a lot of classes! Cheers, Phil. ----- Original Message ----- From: "Dennis Chuah" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, September 08, 2004 9:14 PM Subject: Re: [DUG] Passing Objects to a DLL > > BPL's are the only way to go. You typically version your BPL's by appending > the version number to the filename. > > If you have to stick to DLL's try using interfaces and query for an > interface rather than whether an object belongs to a hierarchy. Interface > querying uses GUID's and not VMT pointers. > > >From: "Phil Middlemiss" <[EMAIL PROTECTED]> > > > >Thanks Max, I thought it was something like that, but didn't know the > >specifics. BPL's are out of the question for us... we looked at that and > >ruled it out earlier since the versioning nightmare is even worse than with > >DLL's. Is the BPL the only way around it? > > > >Cheers, > >Phil. > >----- Original Message ----- > >From: "Max Nilson" <[EMAIL PROTECTED]> > >To: "'NZ Borland Developers Group - Delphi List'" <[EMAIL PROTECTED]> > >Sent: Wednesday, September 08, 2004 5:07 PM > >Subject: RE: [DUG] Passing Objects to a DLL > > > > > > > Phil Middlemiss asks: > > > > > > > When an object is passed to a DLL it comes across fine and all > >properties > > > and > > > > methods can be accessed, but somehow the class information gets > >handled > > > > differently. Using the "is" comparison fails when it should work - > >even > > > > InheritsFrom doesn't work. We've got around this in the past by using > >a > > > > recursive routine to compare class/ancestor names but I'm beginning to > > > wonder > > > > if there is a trick that I have missed somewhere. > > > > > > > Can anyone shed any light on this? > > > > > > Class type comparisions are done using the VMT tables that are generated > >for > > > each class. When you compile a DLL a separate copy of the VMT's are > >linked > > > in, leading to the situation that App.TFoo <> Dll.TFoo. > > > > > > Borland fixed this problem when the add their BPL libraries (in Delphi 5 > >I > > > think?), as these have the knowledge built in to allow then to reference > >the > > > calling applications VMT's. > > > > > > Simple solution then it to use BPL rather than DLL packaging technology. > > > > > > Cheers, Max. > > > > > > > > > > > > > > > _______________________________________________ > > > Delphi mailing list > > > [EMAIL PROTECTED] > > > http://ns3.123.co.nz/mailman/listinfo/delphi > > > >_______________________________________________ > >Delphi mailing list > >[EMAIL PROTECTED] > >http://ns3.123.co.nz/mailman/listinfo/delphi > > _________________________________________________________________ > Need more speed? Get Xtra JetStream @ http://xtra.co.nz/jetstream > > _______________________________________________ > Delphi mailing list > [EMAIL PROTECTED] > http://ns3.123.co.nz/mailman/listinfo/delphi > _______________________________________________ Delphi mailing list [EMAIL PROTECTED] http://ns3.123.co.nz/mailman/listinfo/delphi
