[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [cgmo-webcgm] <object> interoperability issue
Benoit,
Yes, it helps. Thanks for taking the time to spell it out.
-Lofton.
At 08:13 AM 6/15/2010 -0400, Bezaire, Benoit wrote:
>Answering: "I'm curious after reading that explanation why a test that
>uses only the 'data' attribute, and no PARAMs, should fail."
>
>All the ActiveX implementation I've worked with use DoPropExchange. This
>functional is called early in the initialization process. It's used to
>receive/send properties to and from the ActiveX. WebCGM implementations,
>most likely use DoPropExchange to retrieve PARAM values. Note that
>DoPropExchange is called regardless if any PARAM values are specified.
>You can't query IE to find out which PARAM values are set. Instead MS
>provides a set of macros: PX_String( propExchangeInstance, "param name
>here", variableToStoreData, defaultValueHere) used on all possible
>properties (regardless if present or not).
>
>The limitation in IE is: as soon as you have 'data' on the object tag,
>those macros can give you garbage data. That's why a test with 'data'
>only can fail.
>
>Hope this helps.
>Benoit
>
>-----Original Message-----
>From: Lofton Henderson [mailto:lofton@rockynet.com]
>Sent: Monday, June 14, 2010 3:15 PM
>To: cgmo-webcgm@lists.oasis-open.org
>Subject: RE: [cgmo-webcgm] <object> interoperability issue
>
>Benoit, All --
>
>Thanks for the MS feedback. The MS technical explanation seems clear.
>I
>know it doesn't ultimately matter, but I'm curious after reading that
>explanation why a test that uses only the 'data' attribute, and no
>PARAMs,
>should fail.
>
>That detail aside, the real issue is the choice that you indicate. The
>best solution would be a change to WebCGM, to make it officially valid
>what
>two implementations already do (pass a 'src' <param>). Such a change
>would
>not change the metafile definition, nor the DOM/XCF definitions. It
>would
>add one viewer conformance requirement.
>
>Although it looks like an erratum, it might be considered substantive
>because it affects viewer conformance requirements (even tho' it adds no
>
>new functionality.) So it would require a small (about 1 paragraph) 2.2
>
>upgrade. (To be continued...here and 6/30 telecon)
>
>What about workarounds -- part 2 of the investigation? Is there any way
>in
>one's ActiveX control code to get 'data' and <param> values other than
>as
>described by MS in your message? Failing that, is it possible to
>rephrase
>the example in 3.4 to use the DOM to capture the load event, i.e., a
>work-around to avoid using the onload param, such as we do in existing
>tests?
>
>-Lofton.
>
>p.s. Is anyone involved with the W3C HTML5 project? The html5 <object>
>
>element is unchanged in allowing 'data' attribute together with <param>
>child elements. It might be useful input that the biggest browser
>doesn't
>support that.
>
>At 09:16 AM 6/14/2010 -0400, Bezaire, Benoit wrote:
> >My understanding is the same; I initially tried to simplify the issue
>by
> >saying that using PARAMs and data together isn't supported by IE. Query
> >or not, to me that's relatively minor. Bottom line, the spec describes
>a
> >practice that is not officially supported by IE. Either WebCGM
> >implementations have to change or the spec has to change.
> >
> >The technical explanation from Microsoft:
> >"As you might have already found out experimentally, the current IE
> >design does not allow an ActiveX control to be initialized by values
> >coming from both the PARAM tag and the data attribute. You can use
> >either the PARAM tag or the data attribute one at a time, but will not
> >be able to use both. When IE instantiates the ActiveX control via the
> >OBJECT tag, it will look to see if there are any PARAM values and call
> >the control's IPersistProeprtyBag implementation to pass in the data.
> >If no PARAM tag is used, then it will next look at the OBJECT tag's
>data
> >attribute. If one is present it will call the control's
>IPersistMoniker
> >implementation to pass the data in an IMonkier form. The control can
> >then call IMoniker::GetDisplayName to get the value. As you can see
> >from this implementation, you will not be able to use both the PARAM
>tag
> >and the data attribute simultaneously."
> >
> >Benoit
> >
> >-----Original Message-----
> >From: Lofton Henderson [mailto:lofton@rockynet.com]
> >Sent: Friday, June 11, 2010 6:52 PM
> >To: Bezaire, Benoit; cgmo-webcgm@lists.oasis-open.org
> >Subject: RE: [cgmo-webcgm] <object> interoperability issue
> >
> >At 03:13 PM 6/11/2010 -0400, Bezaire, Benoit wrote:
> > >Here is my sample attached.
> >
> >Thanks.
> >
> >
> > >You will notice that 'data' is used, but there are no <PARAM>s. Yet
>the
> > >problem exist since a typical windows application will query for the
> > >PARAMs using DoPropExchange regardless if they are specified or not.
> >
> >It sounds like your understanding of the problem has evolved somewhat.
> >So
> >is it the "query for the PARAMs", even if it is none is present, that
> >causes the problem? Earlier you wrote about the need for both 'data'
> >and
> >PARAM to be present:
> >
> > >...Our implementation (COleControl ActiveX) is passed in corrupted
>data
> >
> > >when both the 'data' attribute is specified on the <object> tag and
> >when
> > ><PARAM> elements are also specified.
> > >
> > >According to Microsoft, HTML 4 doesn't state that an implementation
>(of
> >
> > >HTML) has to pass all values ('data' attribute, <PARAM>s)
> >simultaneously
> > >to the ActiveX. Either 'data' without <PARAM> is used; or <PARAM>s
> >without
> > >the 'data' attribute is used.
> >
> >FWIW, I modified your sample.html slightly, so that the <object> sits
> >directly in the table in place of the div/divTag stuff. Your old beta
>6
> >
> >showed the cube fine, whereas old beta 6 crashed on your original
> >sample.html code (w/ div/divTag scheme). It escapes me, why that bit
>of
> >
> >extra script execution matters before the <object> element gets
> >processed.
> >
> >Ugh...
> >
> >It is hard to believe that this has not become a critical problem for
> >MS. One would think it quite common to use <object>'s 'data' attribute
> >with child <param> elements.
> >
> >-Lofton.
> >
> >
> >
> > >-----Original Message-----
> > >From: Lofton Henderson [mailto:lofton@rockynet.com]
> > >Sent: Friday, June 11, 2010 1:09 PM
> > >To: cgmo-webcgm@lists.oasis-open.org
> > >Subject: [cgmo-webcgm] <object> interoperability issue
> > >
> > >Implementors (et al) --
> > >
> > >Stuart volunteered when I asked for a straightforward test case of
> > ><object
> > >data=>/<param>: "Volunteer? (To turn it into a simple, minimal
> >complete
> > >test case of the 3.4 Example?)"
> > >
> > >I decided to modify his test to make the simplest possible <object>
> >test
> > >case: one <object> element referencing a CGM, and no <param>. See
> > >attached.
> > >
> > >Results: I tried 3 viewers (don't have access to Ulrich's right
>now).
> > >
> > >PTC's very old Beta 6 passed. The other two did not.
> > >
> > >Don, Forrest (, Ulrich) -- could you look into it please? This is a
> > >most basic test of referencing a CGM into an HTML document. It
>really
> > >should work, regardless of whether the viewer is capable of more
> > >advanced configurations (like loading via DOM), and regardless of
> > >whether IE sometimes has issues with <param> child elements.
> > >
> > >Regards,
> > >-Lofton.
> > >
> > >---------------------------------------------------------------------
> > >To unsubscribe from this mail list, you must leave the OASIS TC that
> > >generates this mail. Follow this link to all your TCs in OASIS at:
> >
> >https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe from this mail list, you must leave the OASIS TC that
> >generates this mail. Follow this link to all your TCs in OASIS at:
> >https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
>---------------------------------------------------------------------
>To unsubscribe from this mail list, you must leave the OASIS TC that
>generates this mail. Follow this link to all your TCs in OASIS at:
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
>---------------------------------------------------------------------
>To unsubscribe from this mail list, you must leave the OASIS TC that
>generates this mail. Follow this link to all your TCs in OASIS at:
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]