<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
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.<br>
<br>
Sarah<br>
<br>
David Temkin wrote:
<blockquote
cite="mid:279191F6-9FF3-4752-B5FF-6169A2DBC55E@laszlosystems.com"
type="cite">
<div>The docs say:</div>
<div><br class="webkit-block-placeholder">
</div>
<div>
<blockquote type="cite" class=""><span class="Apple-style-span"
style="color: rgb(51, 51, 51); font-family: Verdana; font-size: 12px; line-height: 18px;">Everything
within a <code class="tagname"
style="font-family: 'Courier New',Courier,monospace; font-size: 13px; background-color: rgb(234, 234, 234);"><state></code> tag
acts as if it were written inside the parent when the state is applied.
States can contain attributes, methods, and other nodes.</span></blockquote>
</div>
<div><br class="webkit-block-placeholder">
</div>
<div>This is a clean conceptual model, IMHO. No exceptions.</div>
<div><br class="webkit-block-placeholder">
</div>
<div>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).</div>
<div><br>
</div>
<div>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. </div>
<div><br class="webkit-block-placeholder">
</div>
<div>Regarding the proximate issue mentioned by Tucker: Sounds like a
bug in the SWF debugger, and not a general problem with dragstate. </div>
<div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
<div><br class="webkit-block-placeholder">
</div>
<div><br class="webkit-block-placeholder">
</div>
<div>
<div>On Feb 21, 2008, at 7:21 AM, Sarah Allen wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">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.<br>
<br>
The question is: should contraints that are overridden when a state is
applies be "put back" when a state is removed?<br>
<br>
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.<br>
<br>
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:<br>
<canvas><br>
<checkbox id="cbox" text="Show"<br>
x="10" y="10" /><br>
<state apply="${cbox.value}"><br>
<view bgcolor="blue" x="5" y="30"<br>
width="150" height="150" /><br>
</state><br>
</canvas><br>
<br>
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"<br>
<br>
<canvas><br>
<simplelayout/><br>
<attribute name="t" value="4"/><br>
<text text="${canvas.t}"/><br>
<checkbox id="cbox" text="Show"<br>
x="10" y="10" /><br>
<state apply="${cbox.value}"><br>
<attribute name="t" value="10"/><br>
<view bgcolor="blue" x="5" y="30"<br>
width="150" height="150" /><br>
</state><br>
</canvas><br>
<br>
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.<br>
<br>
<canvas debug="true"><br>
<simplelayout/><br>
<attribute name="t" value="4"/><br>
<text text="${canvas.t}"/><br>
<checkbox id="cbox" text="Show"<br>
x="10" y="10" /><br>
<state apply="${cbox.value}"><br>
<attribute name="t" value="10"/><br>
<view bgcolor="blue" x="5" y="30"<br>
width="150" height="150" /><br>
<method name="doSomething"><br>
Debug.write('new');<br>
</method><br>
</state><br>
<br>
<button onclick="canvas.doSomething()">doSomething</button><br>
<method name="doSomething"><br>
Debug.write('orginal');<br>
</method><br>
</canvas><br>
<br>
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.<br>
<br>
<canvas debug="true"><br>
<simplelayout/><br>
<attribute name="t" value="4"/><br>
<text text="${canvas.t}"/><br>
<checkbox id="cbox" text="Show"<br>
x="10" y="10" /><br>
<state apply="${cbox.value}"><br>
<attribute name="t" value="10"/><br>
<view bgcolor="blue" x="5" y="30"<br>
width="150" height="150" /><br>
<handler name="onmousedown" reference="LzGlobalMouse"><br>
Debug.write('new');<br>
</handler><br>
</state><br>
<br>
<button onclick="canvas.doSomething()">doSomething</button><br>
<handler name="onmousedown" reference="LzGlobalMouse"><br>
Debug.write('original');<br>
</handler><br>
</canvas><br>
<br>
<br>
P T Withington wrote:<br>
<blockquote type="cite">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!<br>
</blockquote>
<blockquote type="cite"><br>
</blockquote>
<blockquote type="cite">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.<br>
</blockquote>
<blockquote type="cite"><br>
</blockquote>
<blockquote type="cite">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.<br>
</blockquote>
<blockquote type="cite"><br>
</blockquote>
<blockquote type="cite">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?<br>
</blockquote>
<br>
</blockquote>
</div>
<br>
</blockquote>
<br>
</body>
</html>