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]
