Yes, remove the warning. It seems we need to allow them... although
we should document that they are always there, that they don't get
applied/removed like attributes.
On 2008-03-16, at 10:26 EDT, Henry Minsky wrote:
Yeah I guess a state is a mixin, whose apply() method adds some views
and installs some constraints, and the remove() method removes them.
So we could implement that at compile time
I guess...
So, I should remove the warning for methods in states , right?
On Sun, Mar 16, 2008 at 9:52 AM, P T Withington <[EMAIL PROTECTED]> wrote:
Yeah, but it seems we need to allow methods in states, as common
subroutines. I think we just have to document that a method in a
state is really just a method on the parent. We need to do this at
compile time eventually, and warn you if you are trying to override a
method on the parent... hey, maybe a state is really just a mix-in?
On 2008-03-16, at 09:42 EDT, Henry Minsky wrote:
Oh, my check only warns when you use method in an instance that is a
descendant of state, not in a
class definition that extends state. I'll add that check.
On Sun, Mar 16, 2008 at 9:38 AM, Henry Minsky
<[EMAIL PROTECTED]> wrote:
I'll check why the warning isn't getting generated.
On Sun, Mar 16, 2008 at 8:51 AM, P T Withington <[EMAIL PROTECTED]>
wrote:
We have a problem:
dragstate has an internal method, __dragstate_get_newpos, that is
used
by the constraints that it installs. The constraints run in the
parent, so they expect that internal method of dragstate to be in
the
parent. It doesn't really need to be applied/removed; it just
needs
to be there for when the constraints are applied.
I thought I had updated to include your new warning, but I am not
getting a warning on this. It is used by the swf debugger, so
should
be triggering a warning, no?
Anyways, we might have to re-think our policy about no methods in
states. Not that they can't have methods, but that any methods
they
contain become methods on the parent, automatically.
On 2008-03-15, at 16:45 EDT, Henry Minsky wrote:
in base/basewindow.lzx, I moved the setDragPos method to be
outside of
the state, given that we will
be phasing out support for methods inside of states.
<state name="_windowDrag">
<attribute name="starty" value="$once{this.y}"/>
<attribute name="startx" value="$once{this.x}"/>
<attribute name="ydoffset" value="this.getMouse( 'y' )"
when="once" />
<attribute name="xdoffset" value="this.getMouse( 'x' )"
when="once" />
<attribute name="y"
value="${setDragPos('y',
this.immediateparent.getMouse( 'y' ))}"/>
<attribute name="x"
value="${setDragPos('x',
this.immediateparent.getMouse( 'x' ))}"/>
</state>
<method name="setDragPos" args="xory, mousepos"> <![CDATA[
var newpos = mousepos - this[xory + 'doffset'];
var diff = this[xory] - this['start' + xory];
if (Math.abs(diff) > 3) {
setAttribute('state', 3);
}
return newpos;
]]>
</method>
--
Henry Minsky
Software Architect
[EMAIL PROTECTED]
--
Henry Minsky
Software Architect
[EMAIL PROTECTED]
--
Henry Minsky
Software Architect
[EMAIL PROTECTED]
--
Henry Minsky
Software Architect
[EMAIL PROTECTED]
