[Laszlo-dev] Constraints on non-LZX objects [Was: are there any tips on how to debug swf9 player excpetions?]

[P T Withington]

> 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 <rajubitter at me.com>  
>> 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.