Another emthod again breaks the compatibilty rules - and as for clients
which need the 'other' interface Qi will do just fine -

Well if u could just make it mandatory that the new dll (with new
interface)
is used everywhere it should be fine - scripting clients should have no
problem with interface ID change - if compile clients are there atleast they
wouldnt
bomb coz u have kept interface constant and changed the vtable - they
would get a chance to report something and get out

----- Original Message -----
From: Madhusudanan R <madhuRSI.RAMCO.COM>
To: <DCOMDISCUSS.MICROSOFT.COM>
Sent: Thursday, February 07, 2002 3:28 PM
Subject: Re: Interfaces and new methods

> For scripting clients having to access the 'non-default' interfaces, why
not
> use a method in the default interface which returns an interface pointer
to
> the 'non-default' interface. Another form of QI.
>
> > -----Original Message-----
> > From: Steve Johnson [SMTP:sjohnson3TSYSTEMS.COM]
> > Sent: Friday, January 25, 2002 10:08 PM
> > To: DCOMDISCUSS.MICROSOFT.COM
> > Subject: Re: Interfaces and new methods
> >
> > CG> What would the approach be if an existing method was changed?
> >
> > CG> Would you rename it to MethodName2 in the new interface?
> > CG> Is there no other option?
> >
> > Theoretically, you could add a new method with a different ID to the
> > existing interface. This would provide compatibility for existing
> > clients and allow new clients to take advantage of new functionality.
> > The problem is that if clients depending upon the new method
> > encounter a component implementing the old interface, they will fail.
> > A better solution would be to create a new interface. However, if
> > you are servicing scripting clients, they have no means of QI'ing
> > for an interface, so this won't work. There has been discussion this
> > problem on this
> > list in the past, but I don't remember the solutions. If you are in
> > this situation with scripting clients, I'm afraid I can't be of
> > further assistance as I've never had to solve this problem myself.
> >
> >
> > Steve Johnson
> > 3t Systems
> >
> > ----------------------------------------------------------------
> > Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
> > contains important info. Save time, search the archives at
> > http://discuss.microsoft.com/archives/index.html .
> > To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM
>
> ----------------------------------------------------------------
> Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
> contains important info. Save time, search the archives at
> http://discuss.microsoft.com/archives/index.html .
> To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM

----------------------------------------------------------------
Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
contains important info. Save time, search the archives at
http://discuss.microsoft.com/archives/index.html .
To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]