Yip, that's what I said... "either a new interface to be added, ....". ----- Original Message ----- From: "Dennis Chuah" <[EMAIL PROTECTED]> To: "NZ Borland Developers Group - Delphi List" <[EMAIL PROTECTED]> Sent: Thursday, September 09, 2004 9:35 AM Subject: Re: [DUG] Passing Objects to a DLL
> > The idea of using interfaces is once published, you do not change the > interface. If you need to make any changes, you publish another interface > (with a different GUID) and as long as the implementation is backwards > compatible (ie., supports both interfaces), you do not need to recompile the > consumers. > > ----- Original Message ----- > From: "Phil Middlemiss" <[EMAIL PROTECTED]> > To: "NZ Borland Developers Group - Delphi List" <[EMAIL PROTECTED]> > Sent: Thursday, September 09, 2004 8:27 AM > Subject: Re: [DUG] Passing Objects to a DLL > > > > 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 > > > _______________________________________________ > 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
