I think I see the root of the problem:
LzState is overriding __LZapplyArgs, but it is doing a poor job of
it. It does not deal with early setters or ordering. I have a fix
that I am testing...
On 2006-12-08, at 20:12 EST, Henry Minsky wrote:
Here's a patch that seems to work, I moved the call to
checkDelegates to happen in LzState. LZapplyargs, after the heldArgs
table has been filled in with all the $m2, $m3 etc method names.
The bug with this solution is that for some reason checkDelegates
gets called a second time with undefined as an arg,
so I had to put in a check for it. But anyway this seems to be on
the right track for what is happening..
Index: LzState.lzs
===================================================================
--- LzState.lzs (revision 2990)
+++ LzState.lzs (working copy)
@@ -40,12 +40,14 @@
/**
* @access private
*/
-//setters.$delegates = "__LZstoreDelegates"; // Redefined a few
lines down
+setters.$delegates = "__LZstoreDelegates";
+//setters.$delegates = "checkDelegates";
+
+
/**
* @access private
*/
setters.$refs = "checkRefs";
-setters.$delegates = "checkDelegates";
var staterefs = { apply : true };
var stateevents = { onremove : true , onapply : true };
prototype.$isstate = true; // Defined in LzNode
@@ -222,6 +224,10 @@
this.heldArgs[a] = args[a];
}
}
+
+ this.checkDelegates(this.heldArgs.$delegates);
+
+
}
/**
@@ -255,9 +261,13 @@
* @access private
*/
function checkDelegates ( delarr ){
+ if (!delarr) return;
var pardels = [];
var mydels = [];
+ Debug.info(this, "checkDelegates handling ", delarr);
+
+
for ( var i = 0; i < delarr.length;i +=3 ){
//does this go with the state or the state's owner?
//goes with the state ONLY IF the event is an event that
the state
@@ -268,13 +278,19 @@
//now, capture the method that this calls
var mname = delarr[ i +1 ];
+
//check to see if we already processed this method
//in __LZapplyArgs
+
+ Debug.write("looking at ", mname, "this.heldArgs
[mname]:", this.heldArgs[mname]);
+
if ( this.heldArgs[ mname ] ){
this[ mname ] = this.heldArgs[ mname ];
delete this.heldArgs[ mname ];
}
+
+
//create a setter for this method; by definition
attributes that
//the state has a setter for are handled by the state
this.__LZaddSetter( mname , '__LZsetProperty' );
On 12/8/06, Henry Minsky <[EMAIL PROTECTED]> wrote: So here is
a clue as to why the delegate isn't working for onapply in the state.
I put a debug print into the LzState. checkDelegates , to print out
what it is doing, I print out the 'delarr' arg
function checkDelegates ( delarr ){
var pardels = [];
var mydels = [];
Debug.write(this, "checkDelegates handling ", delarr);
It prints out this delegate array
«LzState#0| LzState » checkDelegates handling [onremove, $m2, null,
onapply, $m3, null]
So there's gensym'ed methods named "$m2" and "$m3" it wants to use.
They are defined on the parent
lzx> app.$m2
«LzView function(0)#2| $states$2Elzx_9_70_$m2»
lzx> app.$m2
«LzView function(0)#2| $states$2Elzx_9_70_$m2»
checkDelegates looks for them in the "heldArgs" slot of the state,
and they are there when I look for them in the debugger later:
lzx> app.splashstate.heldArgs
«Object#3| {}»
lzx> Debug.inspect
( {})
{} {
$hasdefaultattrs: true
$m2: «LzView function(0)#2| $states$2Elzx_9_70_$m2»
$m3: «LzView function(0)#4| $states$2Elzx_9_70_$m3»
}
«Object#3| {}»
lzx>
BUT, they are not present in heldArgs when checkDelegates runs. So
this might be an ordering issue, the code which sets stuff into
state.heldArgs
maybe isn't storing the $m2 and $m3 attributes until after the
delegate handler code has run??
--
Henry Minsky
Software Architect
[EMAIL PROTECTED]
--
Henry Minsky
Software Architect
[EMAIL PROTECTED]
