--- In [email protected], "Amy" <amyblankens...@...> wrote: > Honestly, I'm not sure how it is that you don't see any difference between > what I my example shows and what you're doing. My fault/result method > signatures are completely different--they have a different number of > arguments and expect different data types. These are the kind of details you > need to train yourself to pick up on, or you're going to continue to find the > documentation unhelpful.
*chuckle* Arguments are easily detected, as are the differences - it simply wont work if you're sending too many or too few arguments to a new function call (custom or stock). But in the case of your fault/result method, it's a simple thing to work around. The way the other responder works, at least in the documentation and code examples I've seen, it's pretty clear how to get the result/fault and the AsyncToken. But in the end, that's not the issue ... if the responder never seems to be called, everything else is moot :\ This is why I'm wondering if you can't wrap AsyncToken calls around AsyncToken calls - if the SDK just gets confused or ignores nesting like that. Either way, closure appears to be working for me right now, which is the important part. Tref
