[comp.sys.mac.hypercard] Drawing _on_top_of_ HyperCard's window

sirkm@ssyx.ucsc.edu (Greg Anderson) (03/08/90)

Is it possible to patch into HyperCard's window update / redraw
process and subsequently draw custom items on top of the card?

I have an XFCN that currently draws _temporary_ items on the screen;
the grafPort is conveniently set to HyperCard's window when my XFCN
gains control (I trust I can count on this always being the case?).
However, said XFCN erases anything it draws (via posting an invalidate
event or re-inverting objects drawn in XOR mode) before returning to
HyperCard, as things otherwise get messy when HyperCard starts doing
screen updates.

I know I could "domenu Paste" & copy my images onto the card graphic
or background layer of HyperCard, but I would rather leave these
layers undesturbed, as my objects could potentially move or go away,
& I wouldn't want the card or background graphics to be oblitterated
if this happened.  Also, things would get wierd if the user selected
a painting tool and blasted over my objects.

For the curious:  I have implemented transparant polygon buttons
for HyperCard, & would like to give the script-writer the option of
making them opaque or outlined if desired.  (The existing code
works quite well, however, and I will post it after I do a little
more work on it.)

On a related (but much more evil) note:  is it possible to add a new
menu _item_ (such as "New polybutton", perhaps...) under an existing
HyperCard menu (maybe "Objects"...)?  I don't want to add my own menu,
as some stacks might fill up all existing menu space with new menus
of their own.  Changes to the home stack should be transparant to stacks
that don't know about them.  I'm still trying to think of a good
method to use to get into the (as yet unwritten) polybutton editor;
creating my own HyperCard tool is obviously out of the question!  (Unless
I join the HyperCard development team and start working on v3.0. :>  ).

Any advice (other than "buy SuperCard"  :> ) would be appreciated.
  ___\    /___               Greg Anderson              ___\    /___ 
  \   \  /   /         Social Sciences Computing        \   \  /   /
   \  /\/\  /    University of California, Santa Cruz    \  /\/\  /
    \/    \/              sirkm@ssyx.ucsc.edu             \/    \/

KOFOID@cc.utah.edu (03/10/90)

Greg --

    About your "evil note": funny you should mention...

    I've been writing a stack which I want to look as much as possible like an
application running under the standard Mac GUI. I'm doing it partly out of
curiosity, partly as the people it's written for know zilch about HyperCard and
don't want to. They want a tool that behaves like the average Mac program
(requiring no manual reading) that works yesterday.

    What I've found is that the entire menu bar can be completely redefined
from an XCMD. You can use all menu items, as long as you kill the normal HC
event loop with the stack scripts

        on doMenu theItem
        end doMenu

        on choose myTool
        end choose


    You use the menus from an idle handler at stack level running a second XCMD
which screens menu events. This is all relatively easy. I will post the code as
soon as it is debugged sufficiently. Please do your own experiments, however,
as I'm working in a vacuum and you may find much better ways to do this. Please
keep in touch.

    If you just want to add a couple of items to existing menus, make sure they
are added to the end of the item list. You can trap them with the appropriate
statements in an "on doMenu" handler. Things will get mysterious if you try to
upset the order of things in the normal list. Apparently, HC deals with its
intrinsic menu items only through the item number, and doesn't look at the menu
definition itself. I'm sure this makes the code more compact and efficient. If
you rename "Copy Card..." to "FooBar", for instance, you will not be able to
use "FooBar" in the handler, as HC will stubbornly insist on sending the "Copy
Card..." command. Things get even stickier if you do item *insertions*. You can
actually end up sending the disabled gray-line separator as a parameter to
doMenu.

    If you decide to redefine the menu bar, do it with an MBAR resource. This
is faster, saves memory, and is very convenient, as you can define several of
them and swap them about quickly.

    In the meantime, I'll try to finish up my little project and post it ASAP.

    By the way, the groans you hear in the background are voices of
HyperCardists thirsting for my blood. This advice is heresy and I expect the
Apple cops to take away my Mac any day now.

    Good luck and cheers,

        Eric.