On 2009-06-21, at 20:56EDT, Henry Minsky wrote:
Yes, that is the issue, and it only comes up in swf9 because the
runtime is
so picky about type checking.
We do need to make some kind of workaround or better error message
for this.
Maybe a catch in the new LzDelegate, so that we can give a clue as
to what
expression is causing the error, and/or keep going with a debug
warning.
On Sun, Jun 21, 2009 at 7:19 PM, Raju Bitter <[email protected]>
wrote:
Interesting, Henry. That means constraints can only be used with
most LFC
and all LZX objects, not with anything on an AS3 level below the
LFC? What
was the reason to make some objects not extend LzEventable?
We've had some discussions on this previously, and don't have a good
answer.
The constraint system relies on the event system for its
implementation. If you constrain a value to an expression that
contains a property reference `thing.value`, the constraint analyzer
tells the compiler that your expression needs to be re-evaluated when
`thing.value` changes. I.e., it tells the compiler to set up a
delegate to listen for `thing.onvalue` and to recompute the constraint
if that happens. For this reason, constraints can only _really_ work
if `thing` is an `lz.eventable` object, because that is the interface
that defines how events are sent.
o In swf8, the compiler and the runtime silently ignore any error that
might occur if `thing` is not an eventable object, but you are only
getting the illusion that your constraint is working if you do that,
because there will be no event send (or heard) if `thing.value` changes.
o In swf9, because we declare types, and the compiler is very strict
about compile-time type-checking, it can tell you at compile-time that
your constraint is not going to work.
So, really, what is happening in swf9 is what you want, if the error
could be made more understandable. It would probably also help if we
inserted some runtime debugging code to issue a corresponding warning
in swf8/dhtml.
---
Ideally, our constraint analyzer would be as smart as the swf9
compiler, know when a property-reference is not to an lz.eventable
object, and give you a warning at compile time. But it's not that
smart. Here's some guidelines on what to do in the mean time:
1) If there is an LZX class that you are trying to constrain to and
you are getting this error, I would say that is a bug and you should
file it.
2) In some cases, you may just realize that you didn't need to involve
that property-reference in your constraint, that it is actually a
constant. In that case, you can rewrite your constraint, either to a
$once expression, or, move the property-reference out of the
constraint (put it in a $once expression of its own, assigned to a
local property of your class).
3) But, suppose you really _do_ need to constrain an value to some
platform object property, how can you do it? The best thing you could
do is set up a wrapper for the value. E.g., in the LFC there is a
wrapper around the platform mouse that looks (abstractly) like this:
<class name="mousewrapper">
<attribute name="mousex">
<attribute name="mousey">
<method name="__mousemove">
this.setAttribute('mousex', platform.getMouseX();
this.setAttribute('mousey', platform.getMouseY();
</method>
<handler name="oninit">
platform.attachEventHandler('mousemove', this, '__mousemove');
</handler>
</class>
<mousewrapper id="mouse" />
As a result you can say things like:
x="${mouse.x}";
and `x` will track the x position of the mouse.
Of course, the actual implementation of the LFC mouse API is platform-
dependent. There is an abstract API that the LFC presents to you, and
separate kernel implementations for each platform that map the
underlying runtime mouse to the abstract LFC mouse.
If you think your platform property that you want to track in a
constraint would be useful to everyone, you should propose an
improvement to the LFC.
