Having RunRev Standalone accept and reply to AppleEvents?
J. Landman Gay
jacque at hyperactivesw.com
Wed Jan 26 13:16:46 EST 2005
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.
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.
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. 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.
Maybe something in the above will at least give you a clue where to
start looking for the problem. Let us know.
On 1/25/05 7:32 PM, kee nethery wrote:
> I have a one card stack in RunRev that gets saved as an application, and
> is used to catch, process and reply to AppleEvents. It is supposed to be
> controllable via AppleEvents. I've gone through over 20 iterations to
> try to duplicate some existing functionality in an existing Hypercard
> stack/standalone application. I scanned all the example stacks and
> RunRev docs I could find that mention AppleScript. Nothing talks about
> these issues.
>
> I can get the standalone app to reply to the first appleevent but then
> after that it is deaf.
> But, if I uncomment the two "answer" lines, this application will reply
> to all the appleevents sent to it.
>
> Second weirdness is that the on appleEvent takes the script to a library
> stack and for this to work at all, I have to actively go back to the one
> single card in my standalone application, interact with the buttons and
> fields, and then go back to whatever stack I got diverted to when
> processing the appleEvent. To my mind that is completely weird behavior.
> But if I do not do it, this stack doesn't even work the first time.
>
> Oh yes, the docs say that "on appleEvent" can be in a card script but
> doing that causes it to not catch a "misc" class wth a "dosc" ID
> appleevent.
>
>
> Here's the stack script:
>
>
> on preOpenStack
> -- I put the name of the standalone into a global so that I can get
> back to this standalone stack
> -- when processing an AppleEvent to do the tasks.
> global thisStackName
> start using "revSOAP"
> put the name of this stack into thisStackName
> end preOpenStack
>
> on appleEvent theClass,theID -- execute a set of statements
> global thisStackName
> -- When I uncomment this answer line, and the other one below, it
> works more than once
> -- answer theClass && theID
> if theClass is "misc" and theID is "dosc" then
> request appleEvent data -- get the content of the AppleEvent
> put it into thedata
> -- the other answer line that gets uncommented
> -- answer thedata with "thedata"
>
> push card
> -- OK this is strange. I'm in this stack script but in actual fact,
> I'm in some runrev library when
> -- I'm at this point in the script and unless I actively go back to
> the stack where this script
> -- is located, I cannot interact with the fields or buttons of this
> standalone. So this
> -- push and pop moves me back to where I would normally think I was.
> go to stack thisStackName
>
> -- this line executes the first time through and then after that,
> thedata never makes it into the field
> -- uncomment the "answer" lines and this line executes as do the
> remaining lines
> put thedata into field "theSQL"
>
> -- doSQL takes the SQL and sends it to the database and then puts
> the results into the soapResult field
> send doSQL to button "execute SQL"
>
> put field "soapResult" into theResult
>
> -- Since I'm in this stack, and for some reason RunRev wants me to
> be in another stack, I pop back
> -- to the library where I am supposed to be. That's the theory at
> least.
> pop card
>
> -- I format the text for a Mac.
> replace return with numtochar(13) in theResult
>
> -- this sends the data back to the application that sent the
> appleEvent.
> reply theResult
> else
> -- it is my understanding that if I do not "reply" then I must "pass
> AppleEvent"
> -- it is also my understanding that if I do "reply" I do not "pass
> appleEvent"
> pass appleEvent
> end if
> end appleEvent
>
> So why is this not working? Any ideas?
> Thanks in advance.
> Kee Nethery
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution
>
>
>
--
Jacqueline Landman Gay | jacque at hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
More information about the use-livecode
mailing list