Having RunRev Standalone accept and reply to AppleEvents?

[kee nethery]

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