NT4/private/ole32/ole232/doc/autolink.txt

From: Douglas Hodges
To: Alexander Gounares
Subject: possible change for next OLE version.
Date: Tuesday, November 02, 1993 12:16PM

a suggestion for consideration.

doug
----------
From: Rao Remala
To: Bob Atkinson; Craig Wittenberg; Tony Williams
Cc: Douglas Hodges
Subject: RE: Autoconversion of links
Date: Thursday, September 23, 1993 3:08PM

Thanks for the info and help! No changes now and Publisher is out of luck
--rao

----------
|From: Bob Atkinson
|To: Craig Wittenberg; Rao Remala; Tony Williams
|Cc: Douglas Hodges
|Subject: RE: Autoconversion of links
|Date: Thursday, September 23, 1993 10:36AM
|
|I agree with Doug.
|
|If the class is different, then we cannot *automatically* go
|ahead, in any of our (present) APIs, as we have no idea as to
|what action the action the caller took based in the erroneous
|information we gave him. We must give the opportunity to the
|piece of code that took action on the erroneous info the
|opportunity to do something different based on the new
|information, as only it knows what it did.
|
|Doug's suggestion makes it easy for an app to write a simple
|helper function that ignores certain changes while deals with
|others. Hopefully it would be easy for us; it seems so.
|
|One might ask whether we should put such a new helper function
|in our libraries. I believe I am against that: 1) it's a new
|OLE api, and 2) I really want applications to be conscious of
|the fact that this change can happen.
|
|	Bob
|----------
|| From: Douglas Hodges
|| To: Bob Atkinson; Craig Wittenberg; Rao Remala; Tony Williams
|| Subject: RE: Autoconversion of links
|| Date: Thursday, September 23, 1993 10:08AM
|| Priority: High
||
|| unfortunately i don't think it is correct to do this. i don't
|| think there is anything we can do for shipping apps (or soon
|| to be shipped apps) that don't do this correctly.
||
|| we need to have apps handle the OLE_E_CLASSDIFF situation
|| correctly. but our problem is that we don't really have our
|| whole story straight as to how this is to be handled.
|| currently we recommend that if the OLE_E_CLASSDIFF error comes
|| then the app should simply call IOleLink::BindLinkSource with
|| the flag OLELINK_EVENIFCLASSDIFF. this is correct ONLY if both
|| the old class and the new class use OLE's DefLink. if either
|| class uses a custom link, then in fact the link must be
|| recreated.
||
|| we need to give a different error code from OleRun when in
|| fact it is required to re-create the link (ie. re-binding with
|| OLELINK_EVENIFCLASSDIFF is not good enough).
||
|| suggestion: OLE_E_CLASSDIFFMUSTRECREATELINK
|| this scode should be returned instead of OLE_E_CLASSDIFF if
|| either the old or new class uses a custom link handler (there
|| is REGDB info that tells us if a class uses a custom link).
||
|| currently the OUTLINE sample apps handle the OLE_E_CLASSDIFF
|| error by re-creating the link in all situations because this
|| always works. it is a lot of overhead  and is a lot more
|| complicated than simply re-binding with the
|| OLELINK_EVENIFCLASSDIFF flag. if we had the two error codes
|| then, the OUTLINE sample code code be easily modified to
|| handle both cases. i can imagine that if we add the new error
|| code, that some apps could choose to handle the
|| OLE_E_CLASSDIFF case and simply fail to ever bind a link that
|| is in the OLE_E_CLASSDIFFMUSTRECREATE case.
||
|| doug
|| ----------
|| |From: Rao Remala
|| |To: Douglas Hodges
|| |Subject: FW: Autoconversion of links
|| |Date: Wednesday, September 22, 1993 5:20PM
|| |Priority: High
|| |
|| |
|| |----------
|| |From: B. Ashok
|| |To: Rao Remala; Srini Koppolu
|| |Cc: Paul Klemond
|| |Subject: FW: Autoconversion of links
|| |Date: Wednesday, September 22, 1993 5:06PM
|| |Priority: High
|| |
|| |
|| |I tried changing the bindflags to OLELINK_EVENIFCLASSDIFF under
|| |the debugger and autoconversion of links works just fine.  I'm
|| |convinced that this should be the default behavior when OleRun
|| |is called.   Otherwise, there seems to be no way to autoconvert
|| |a link correctly without breaking some containers.
|| |
|| |-- Bash
|| |
|| |----------
|| |From: bash
|| |To: natbro; paulkle; phaniv; raor; seanch; srinik; vikramn
|| |Cc: bash
|| |Subject: Autoconversion of links
|| |Date: Wednesday, September 22, 1993 4:40PM
|| |Priority: High
|| |
|| |
|| |I ran across the following problem while debugging
|| |autoconversion of works 2.0 objects and it seems like a fairly
|| |serious one from the user's point of view.
|| |We do autoconversion of works 2.0 objects to works 3.0 and
|| |everything works fine from a 1.0 container.  However we have
|| |the following problem with Publisher 2.0 (and with other ole
|| |2.0 containers that call OleRun to activate links):
|| |
|| |Let's say Pub 2.0 had a linked works 2.0 object in it.  When we
|| |try to activate this, Pub 2.0 calls OleRun, which ends up
|| |returning OLE_E_CLASSDIFF since the clsids are indeed
|| |different.  The only workaround that I know of at present is to
|| |have the container call BindToSource with
|| |OLELINK_EVENIFCLASSDIFF which of course it is too late to do
|| |since there exist shipped apps like Pub 2.0 out there which
|| |call OleRun to activate links... (FYI, the Works WP and DB do
|| |the same thing too).  My question is this: is it possible to
|| |make OLELINK_EVENIFCLASSDIFF as the default behavior when
|| |OleRun is called ?  Or is there anything at all we can do on
|| |the server side (reg.dat or any other hack) to get
|| |autoconversion of links to work ?
|| |
|| |Thanks for any info.
|| |
|| |-- Bash
|| |
|| |
|| |
||
||
|