KOFOID@cc.utah.edu (02/03/90)
I recently posted the following letter, with *no* replies.
However, several people wrote saying they want to know the answer. Can
anybody help?
================
Hypercard, for some reason, does not allow the command or
option keys to send standard trapable messages. Instead, the messages
sent by these two keys bypass the entire Hypercard hierarchy and
go directly to the program or the operating system.
This makes it impossible to create keyboard command
equivalents except by redefining the existing ones with an "on doMenu"
handler. This is a limited solution and inelegant, as the existing
commands are appropriate and should not be changed.
Has anyone a solution to this problem, perhaps using an XCMD
which traps the nonstandard messages? I don't want to use the control
key message, as many Mac users still have the smaller Mac+ keyboards.
I suspect that the prerelease versions of HyperCard *did* send
standard commandKey and optionKey messages, as many of the earlier
books - probably written from experience with beta versions -
described them as such. A case in point is Dan Shafer's "HyperTalk
Programming" (Hayden Books).
Cheers,
Eric.
==================================================================
][ Eric Kofoid ][ Internet: ][
][ Department of Biology ][ BI.KOFOID%SCIENCE@UTAHCCA ][
][ University of Utah ][ BitNet: ][
][ S.L.C., Utah 84112 ][ BI.KOFOID@SCIENCE.UTAH.EDU ][
==================================================================tim@hoptoad.uucp (Tim Maroney) (02/04/90)
In article <41399@cc.utah.edu> KOFOID@cc.utah.edu writes: > Hypercard, for some reason, does not allow the command or >option keys to send standard trapable messages. Instead, the messages >sent by these two keys bypass the entire Hypercard hierarchy and >go directly to the program or the operating system. > > This makes it impossible to create keyboard command >equivalents except by redefining the existing ones with an "on doMenu" >handler. This is a limited solution and inelegant, as the existing >commands are appropriate and should not be changed. There is an inelegant but more complete solution. Use an XCMD that patches GetNextEvent and WaitNextEvent, catching all keyDown and autoKey events which have the command or option key bits set, turning them to null events (but leaving all other events unchanged). It then stores them somehow (perhaps in another resource). This XCMD is called on openStack with an argument telling to initialize, and is called on closeStack with a different argument that tells it to put the traps back the way they were. It is called at idle time with yet a third argument that tells it to examine its private storage to see if any events were received since the last idle; if so, it uses the callback mechanism to post messages for those events, or else stores a value in "the result" which the idle script then uses to post the message itself. Messy, but workable. Incidentally, you could use the jGNEfilter instead of tail patching GetNextEvent, but this could conflict with any INIT or other software that uses the same hook. Be sure to note and call the old routine if you do this. > I suspect that the prerelease versions of HyperCard *did* send >standard commandKey and optionKey messages, as many of the earlier >books - probably written from experience with beta versions - >described them as such. A case in point is Dan Shafer's "HyperTalk >Programming" (Hayden Books). I don't have that book, but I doubt this very much. I think you are likely misinterpreting the commandKey and optionKey *functions*, e.g., "the commandKey is down". These are not messages; they are routines which you can check at any time, but which never cause messages to propagate through the hierarchy. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com FROM THE FOOL FILE: "Yet another piece of evidence that it's a Communist society which is being presented as good, but which we probably would not want to live in." -- Ken Arromdee on rec.arts.startrek, on the Federation's Red Menace
np@doc.ic.ac.uk (Nigel Perry) (02/05/90)
This may not solve all your problems, but I have written an XCMD
"ControlLock" which enables ordinary keys to produce "controlKey
<keynum>" messages - even on keyboards WITHOUT the control key. You
have to bracket your code with "ControlLock on" and "ControlLock off"
calls, when "on" command keys are passed asis, so menus still work.
This XMCD may be found in the stacks "macintalk" & "resource-library"
on sumex. Hope this helps. Nigel
--
---
Nigel Perry Department of Computing
Imperial College
Janet: np@uk.ac.ic.doc London
DARPA: np%uk.ac.ic.doc@ucl-cs SW7
Uucp: np@icdoc.UUCP, ukc!icdoc!np England