155 lines
5.5 KiB
Plaintext
155 lines
5.5 KiB
Plaintext
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
|
|
|| |
|
|
|| |
|
|
|| |
|
|
||
|
|
||
|
|
|
|
|
|
|
|