In Basic, we might introduce debug-time parameter checking to catch people
setting NaN as a value. Basic will continue to choose higher-level least code
APIs.
I've been unable to get you to see the line that I see between
platform-specific and higher-level abstractions. If you want to expose
Hi Alex,
El sáb., 28 dic. 2019 a las 2:46, Alex Harui ()
escribió:
>
> Yes, it is fine to change them to protected.
>
ok will try to do
> The original discussion included the topic of higher-level abstractions vs
> platform-specific APIs. It seems you really want Jewel users to use a
>
On 12/27/19, 7:02 AM, "Carlos Rovira" wrote:
Hi Harbs,
I assume your implementation is part of the StyledUIBase class.
One thing I see is _width and _height are private (as well the rest of
underscored vars in UIBase), should be change it to protected?
Yes, it is fine to
Hi Harbs,
I assume your implementation is part of the StyledUIBase class.
One thing I see is _width and _height are private (as well the rest of
underscored vars in UIBase), should be change it to protected?
if you consider NaN to be error prone, we should consider other option,
since for me the
I would implement it differently:
COMPILE::SWF//assuming this works in SWF
public function inheritDimensions(width:Boolean=true,height:Boolean=true):void{
if(width){
this.width = NaN;
}
if(height){
this.height = NaN;
}
}
COMPILE::JS
public function
In Framework, was as a result of these days discussion about width = NaN in
other threads. Search for "inheritWidth" or "sizeWidthToContent"
Hi Harbs and Alex,
trying an implementation of "inheritWidth" function
public function setInheritWidth(noEvent:Boolean = false):void
{
setWidth(NaN);//we need _width = NaN
COMPILE::JS
{
this.positioner.style.width = null;//remove style.width after setWidth sets
_width to "NaNpx" for JS
}
}
