Those docs don't make it clear what happens when there is a collision,
and then what happens when the state is removed. Under discussion is
the behavior when an attribute is defined in the state AND in the parent
of the state -- in this case, states currently may have a "side effect,"
as I discussed in my note. If states never had side effects, when you
removed a dragstate then the window or whatever would zap immediately
back to where it came from. The application of a state should never
affect anything that is not defined within the state.
Sarah
David Temkin wrote:
The docs say:
Everything within a |<state>| tag acts as if it were written inside
the parent when the state is applied. States can contain attributes,
methods, and other nodes.
This is a clean conceptual model, IMHO. No exceptions.
I would expect elements within the state to be added/removed when the
state is applied/removed. I would not expect elements that are not
specified within in the state (e.g., other attributes, other methods,
other views) to be affected by apply/remove of the state. (That's what
enables what Sarah calls "side effects" below).
I *am* surprised that methods added when a state is applied aren't
removed when the state is removed -- if that is in fact what Sarah is
saying below. That sounds like a bug.
Regarding the proximate issue mentioned by Tucker: Sounds like a bug
in the SWF debugger, and not a general problem with dragstate.
On Feb 21, 2008, at 7:21 AM, Sarah Allen wrote:
Interesting question! cc'ing Laszlo-user list, since LZX coders on
there might have some thoughts on this, or at least be interested in
the details of how states work and whether that should be changed in
the future. I did a little experimentation (see below) to remind
myself how states work, and recall a little history of how we got to
where we are. I do like the current behavior (the convenience of
implementing dragstate and friends), but I do admit that some of the
nuances of states can be confusing and I don't know if they are
clearly documented.
The question is: should contraints that are overridden when a state
is applies be "put back" when a state is removed?
Conceptually when you apply a state, a bunch of stuff is added, and
when you remove it that stuff is removed; however, states are allowed
to have side effects, when attributes are modified by a state they
stay modified. So, attributes and methods when applied remain as
side effects; however, views and events are temporal and get removed.
Way back in LPS v1, Adam Wolff and I decided that constraints are
conceptually like attribute values, even if their implementation is
more like an event; which is why we have the behavior we do today.
In an abstract sense, it feels like a bug that when a state is
removed, you don't just put everything back the way it was. If you
look at this simple example, that might be your expectation:
<canvas>
<checkbox id="cbox" text="Show"
x="10" y="10" />
<state apply="${cbox.value}">
<view bgcolor="blue" x="5" y="30"
width="150" height="150" />
</state>
</canvas>
However, it is a powerful feature of states that you are allowed to
leave a side-effect behind (which is really what enables the
simplicity of dragstate and related coding patterns.) If you change
the value of an attribute, it stays that way. In the following
example, after clicking on the checkbox twice to turn it on and off
again, the value of the attribute "t" is 10, not it's original value "4"
<canvas>
<simplelayout/>
<attribute name="t" value="4"/>
<text text="${canvas.t}"/>
<checkbox id="cbox" text="Show"
x="10" y="10" />
<state apply="${cbox.value}">
<attribute name="t" value="10"/>
<view bgcolor="blue" x="5" y="30"
width="150" height="150" />
</state>
</canvas>
Now, I wonder what happens with a method. In the example below, you
will see that if I toggle the checkbox on and back off, the state's
method remains, just like an attribute.
<canvas debug="true">
<simplelayout/>
<attribute name="t" value="4"/>
<text text="${canvas.t}"/>
<checkbox id="cbox" text="Show"
x="10" y="10" />
<state apply="${cbox.value}">
<attribute name="t" value="10"/>
<view bgcolor="blue" x="5" y="30"
width="150" height="150" />
<method name="doSomething">
Debug.write('new');
</method>
</state>
<button onclick="canvas.doSomething()">doSomething</button>
<method name="doSomething">
Debug.write('orginal');
</method>
</canvas>
Events, get added and removed like views. In the example below, you
end up with two events when the state is applied, then just the
original event when the state is removed.
<canvas debug="true">
<simplelayout/>
<attribute name="t" value="4"/>
<text text="${canvas.t}"/>
<checkbox id="cbox" text="Show"
x="10" y="10" />
<state apply="${cbox.value}">
<attribute name="t" value="10"/>
<view bgcolor="blue" x="5" y="30"
width="150" height="150" />
<handler name="onmousedown" reference="LzGlobalMouse">
Debug.write('new');
</handler>
</state>
<button onclick="canvas.doSomething()">doSomething</button>
<handler name="onmousedown" reference="LzGlobalMouse">
Debug.write('original');
</handler>
</canvas>
P T Withington wrote:
As part of fixing LPP-631 in r8032, states now remove constraints
that they override when applied, and they _restore_ those
constraints when removed. This breaks dragging and resizing of the
swf debugger window!
The swf debugger starts out with its dimensions defaulted to a
percentage of the canvas. Percentage values are constraints. This
is nifty, because if you resize your browser window, the debugger
window nicely resizes too.
But if you try to drag or resize the window, the drag or resize
state gets applied, the window tracks the mouse, but when you let go
of the mouse, the state gets removed and the previous percentage
constraints are reinstalled, snapping the window back to its
starting position.
My question: Is this a bug in states? Should they _not_ restore
constraints they removed? Is this a bug in drag/resize states?
Should they be overriding the base state behavior of restoring
constraints? Or, is this just a bug in the swf debugger? Should it
only size to the canvas initially and not respond to canvas changes?
Or should it be improved to track the canvas until it is resized or
dragged?
