I'd keep it where the applyConstraint is happening for now, unless you
understand this component very well.
The issue is that applyConstraint took a plain function, but that
function would not have any access to the instance in swf9, so you
have to move the function body to an actual method, and then use
applyConstraintMethod to name the method (instead of passing the
function).
On 2008-12-17, at 14:48EST, Lee Lundrigan wrote:
Very interesting.
So where would be the best place to use
'this.applyConstraintMethod'? Would it be in oninit, construct,
onconstruct?
P T Withington wrote:
Here's the clue:
On 2008-12-17, at 14:01EST, Lee Lundrigan wrote:
incubator/scrolledittext.lzx#79/30 @incubator/scrolledittext.lzx#92
The transformation you have to make (and this is if you ever want
this to work in swf9) is to take the functions that are being
applied as constraints there, make them into named methods on the
class instead (you'll have to make up your own names, like
__constrainX, __constrainStepSize, etc.) and then call
applyConstraintMethod, e.g.:
<method name="__constrainX">this.setAttribute("x",
this.parent.width - this.width );</method>
...
this.applyConstraintMethod('__constrainX', [p, "width", this,
"width", p, "border"]);
I don't understand what the original designer was trying to do
here. It looks like they took some normal constraints (in the
comments ` x="${parent.width - this.width - parent.border + 1}"`)
and hand-expanded/fudged them to do something similar but
different. There might be a simpler way to acheive this by simply
writing normal constraints, but I can't tell. Clearly writing them
as normal constraints, the compiler handles all the magic of making
methods, etc. It's because these constraints were written out by
hand that they are running into the deprecation warning.
