First, thank you for the most excellent examination of my script.
On Jan 26, 2005, at 10:16 AM, J. Landman Gay wrote:
Kee,
It sounds like you are getting trapped in Revolution's backscript, which has its own appleEvent handler. This should not be happening -- your own appleEvent handler should be blocking the one in the backscript, unless you pass it on.
The clue was that enabling the "answer" lines causes your script to work. Revolution's handler exits to top if the answer dialog is showing, so that seems to be what is happening. Rev's handler exits and allows yours to work. This is backwards, it seems to me, as your handler ought to have precedence in the message hierarchy.
When a backscript is running, you do not actually "go" to that stack -- the script functions just as though it was part of your own stack. That being the case, you don't need any of the push/pop or "go" statements. The only thing that happens when you use those is that you push the current card, then pop it again or go to it again; that is, there is no navigation in progress, you stay on the same card regardless. So you can remove all that stuff from the handler.
When I did not use those navigation elements, my answer statements would indicate that I was in a library, not my stack. The way I happened across that was it was unable to find the field and so one of my test scripts asked it to count the number of fields, the answer was zero. Since the card actually has around 5 fields, that clued me in to the fact that it was going somewhere else.
The rule about passing the appleEvent is not dependent on whether you reply or not, but rather whether your handler manages the event or not. If your handler does something with an event, then don't pass it. If your handler does not handle the event, then do pass it. Your script does this correctly already.
All that being said, I can't figure out why Rev's appleEvent handler is being triggered at all unless the appleEvents you are debugging are not really "dosc" events. Those events that are not "dosc" should indeed be passing on and managed by Rev's handler. If they are "dosc" events, then your script should be trapping them. So the first thing to check would be to walk through your script in the debugger and make sure that "dosc" events are handled by your own handler, and that others are going through to Rev's.
I cannot try this because the only way for me to get this to work is to compile it as an application. And as far as I have been able to figure out, you cannot drop into the debugger when you are an app. But, during testing I did have an answer statement prior to the initial IF statement and it would show the class and ID and my script was processing just the misc dosc and passing all the others.
Trim your handler down to the basics before stepping through it. Try this:
on appleEvent theClass,theID if theClass is "misc" and theID is "dosc" then request appleEvent data put it into thedata put thedata into field "theSQL" send doSQL to button "execute SQL" put field "soapResult" into theResult replace return with numtochar(13) in theResult reply theResult else pass appleEvent end if end appleEvent
Set a breakpoint by the "if" in the second line. Open the variable watcher and see what the class and ID of the event is. If you receive a "dosc" event and execution does not stay within your own handler then there is a bug in the message hierarchy somewhere.
hmmm. bug in the message hierarchy in my code or in revolution? If it is in my code, I'm not sure how to view the messages when in an application.
However, if you examine the class and ID of the event, you may find that those which are not "dosc" events are being passed on to Revolution's backscript, and the "dosc" events are being managed by your own handler. This would be correct behavior.
from what I was able to see with a bunch of answer statements, that was what was happening. I was handling the misc dosc and all the other events were going to pass appleEvent
Maybe something in the above will at least give you a clue where to start looking for the problem. Let us know.
Since you say that I should not need the push pop stuff, I'll try an experiment where I push/pop only if I really am on another card. Perhaps some times it is doing the correct thing and sometimes not. I'll test.
Nope that test did not work. Basically if the card id of "the card" matched the card where the fields were located, I would bypass the push pop stuff and if not, I'd do them. That worked for the very first query. The second query was unable to locate the field.
OK, this seems to be working. Here's what I did.
I'm looking at the card id before I try to interact with the card. Then, if I am not on that card I go there. I don't push and pop so that I end up back to where ever I started from. I just go there if I am not there and stay there. This is working great now. No idea why the script ends up elsewhere sometimes and sometimes it does not, but going there if I am not there seems to work.
Thanks for the hint that it might not be me, but that revolution might be broken. Looks like your guess was correct. Thanks, Kee
_______________________________________________ use-revolution mailing list [email protected] http://lists.runrev.com/mailman/listinfo/use-revolution
