What Tucker said is correct. And yes, in DHTML we could scale inner view resources but not text. There's a warning for now. Thanks Phil!
-Max P T Withington wrote: > We want what you implemented. These are the LZX semantics and the > correct answer. It is a bug in the DHTML implementation that inner > views are not scaled. You will get a warning to that effect in the > current implementation. [It is my contention that we could use the > portable linkage implementation to correctly scale inner views.] > > On 2006-10-10, at 09:16 EDT, Philip Romanik wrote: > >> Hi Max, >> >> The change I made moves getAttributeRelative() from LzSprite to LzView >> because there is no width/height support in the dhtml version. Example >> apps such as calendar call getAttributeRelative() with >> x,y,width,height. It sounds like there are two choices when someone >> asks for width/height from dhtml: >> >> - Return the view's width/height. >> - Return the same (scaled) width/height for dhtml and swf. >> >> My change is doing the latter. Is the first choice more consistent? >> >> Thanks! >> >> Phil >> >> >> >>> > 2) As with .as, I don't think there needs to be any sprite >>> > getAttributeRelative. The portable code already maintains accurate >>> view >>> > dimensions. [Max: please verify.] >>> >>> Right, except getAttributeRelative() works with height and width in .as, >>> but not .js. This shouldn't be a problem, since width and height can't >>> be transformed/scaled for subviews in .js. The API needs to be >>> consistent and should return something sensible for width/height >>> though... >> > _______________________________________________ Laszlo-dev mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
