|
|
From: Douglas HodgesTo: Alexander GounaresSubject: possible change for next OLE version.Date: Tuesday, November 02, 1993 12:16PM
a suggestion for consideration.
doug----------From: Rao RemalaTo: Bob Atkinson; Craig Wittenberg; Tony WilliamsCc: Douglas HodgesSubject: RE: Autoconversion of linksDate: 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|| ||| ||| ||||||
|
