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 || | || | || | || || |