scott@wam.umd.edu (John Lynwood Scott) (01/22/91)
Hi all.
First, an apology. This is a reposting. I originally posted
this to comp.sys.mac.programmer. Since then I discoved that it should
have been posted here. I got no response on the other newsgroup. I hope
there will be some response from Apple here, since I believe this describes
a serious flaw in HyperCard 2.0.
A while ago, somebody (sorry, I don't remember who) suggested on
either comp.sys.mac.programmer or comp.sys.mac.hypercard (sorry, I don't
remember which) using the SendHCEvent callback to maintain HyperCard
functionality while still retaining control in an XCMD. I would like to
do just that, but I have run into a snag.
I would like to use HyperCard as a user interface to several
programs running on a local unix box. I have written a HyperCard 1.2.5
stack using the Apple Serial Port Toolkit XCMD suite. It uses HyperTalk
both to interact with the user and to script commands to the unix box.
This works, but performance is disappointing. Here is what I would like
to do: I want to move to HyperCard 2.0 and the Communications Toolbox. I
wish to use HyperTalk solely to interact with the user. Scripting to the
unix box will be done completely through an XCMD written in Think C using
OOP. The XCMD will watch for characters from the Comm Toolbox, which it
will handle, or for events from the Toolbox Event Manager, which it will
pass to HyperCard.
This is where I run into trouble. I wrote a short XCMD that
simply waits for events and passes them back to HyperCard. Everything
seems to work okay: moving the mouse off the HyperCard window changes the
cursor, menus can be pulled down and commands selected, etc. But Command
Keys will not work. Pressing Command-M will not bring up the message
box--it only produces beeps. I was disappointed; thought maybe I was
trying to use the callback in a way it was not intended. Then I
discovered some truly bizarre behavior. If I command-click on the
HyperCard window's title bar then Command Keys will suddenly start to
work. Unfortunately, key presses without the Command key down will also
be interpreted as menu equivalents. Both Command-M and M will bring up the
message box. You can type in the message box, but you can't use a letter
that appears in a menu. This convinces me that it is HyperCard and not
me that is at fault here.
Here is the entire XCMD, "foo":
#include "HyperXCmd.h"
pascal main(XCmdPtr paramPtr)
{
EventRecord * theEvent;
long sleepTime = 3L;
while (1) {
WaitNextEvent(everyEvent, theEvent, sleepTime, 0);
SendHCEvent(paramPtr, theEvent);
}
}
Here is the only script in the stack:
on openStack
foo
end openStack
Here is the configuration:
Macintosh IICX, 5 Meg RAM, 80 Med HD
System 6.0.7, Finder 6.1.7
HyperCard 2.0
Apple's "HyperXCmd.h", ported to THINK C by me
Apple's "HyperXLib.o", converted by Symantec's "oConv", A5
addressing (I tried A4 addressing too, with the same results).
My questions are: is this bug corrected in HyperCard 2.0v2 and,
if not, is there a work around? (Actually, the first question is: is
this really a bug or am I doing something incredibly stupid?) I realize
that I could create an xWindow which I could keep invisible, and request
a lot of idles from HyperCard to handle incoming chars from the Comm
Toolbox. However, I am uncomfortable about XCMDs creating invisible
windows willy-nilly. There is unnecessary overhead involved, it seems
kludgy, and I really would like the XCMD to dole time out to HyperCard
rather than the other way around. The "SendHCEvent" callback is a
fantastic feature of HyperCard 2.0 and I really wish it would work. Any
suggestions?
John L. Scott, Programmer/Analyst
Dahlgren Library, Medical Center, Georgetown University
scottj@gumedlib.georgetown.edujkc@Apple.COM (John Kevin Calhoun) (01/23/91)
In article <1991Jan22.153802.22992@wam.umd.edu> scott@wam.umd.edu (John Lynwood Scott) writes: > > A while ago, somebody suggested using the SendHCEvent callback to >maintain HyperCard functionality while still retaining control in an XCMD. >I would like to do just that, but I have run into a snag. > > I wrote a short XCMD that >simply waits for events and passes them back to HyperCard. Everything >seems to work okay: moving the mouse off the HyperCard window changes the >cursor, menus can be pulled down and commands selected, etc. But Command >Keys will not work. > > My questions are: is this bug corrected in HyperCard 2.0v2 and, >if not, is there a work around? This is a bug in HyperCard. It's not fixed in 2.0v2. I don't recommend using SendHCEvent for this purpose even after we fix the bug. SendHCEvent was implemented for use by XCMDs that absolutely have to call GetNextEvent or WaitNextEvent, in order to inform HyperCard of update events and app4events as they occur. If it's at all possible to avoid calling GNE in an XCMD, you should avoid it. HyperCard needs idle time in order to keep its environment clean. > I realize >that I could create an xWindow which I could keep invisible, and request >a lot of idles from HyperCard to handle incoming chars from the Comm >Toolbox. It's much better to use the "invisible window" approach. In fact, I know of one developer who used this approach to his benefit. "I've got to have a window in order to do this," he said, "so I might as well use it." He's implemented some very helpful configuration controls in his window, although they weren't part of his original design. They turned out to be very valuable features. Kevin Calhoun HyperCard Team Apple Computer, Inc.