jr@amanue.UUCP (Jim Rosenberg) (07/30/89)
I don't get a regular feed of this newsgroup, so please excuse if this subject
has already been discussed.
When I converted one of my stacks from HyperCard to SuperCard it just plain
didn't work. I'm not talking poor performance, I'm talking buttons not
working *AT ALL* as in dead as a doornail, kaput, no response. When this
first happened I cursed and fumed at Silicon Beach, wondered how they could
release such a piece of garbage, had visions of a 1-mouse MacUser review. I'm
a big fan of SuperPaint, and something told me it *COULDN'T* be that bad, that
there had to be a sensible reason why I was having the problem. It took me
the better part of a weekend to figure out what was going on. I am being
bitten not by bugs, but by, you guessed it, a *FEATURE*.
My stacks contain a number of backgrounds, each shared by several cards. To
simplify I'll just talk about a single background, so we'll assume there is
one background and several cards. Each card has no buttons, no fields, no
card script; the only thing on a card is a graphic. The background is *tiled*
with invisible rectangular buttons, each of which has only a single on
mouseEnter handler, and all this handler does is a go card for one of the
cards. So what we have is very simple: a set of cards with the screen
divided into rectangular "hot regions"; as the mouse moves around the screen
depending on what region it's in a different card is shown. This works fine
under HyperCard; the reason I'm not happy with it under HyperCard is the
amount of disk space the stack is taking with all the cards.
Now under HyperCard there is really no such thing as "a graphic". In
SuperCard a graphic is an object, i.e. an entity with a script and a receiver
of messages. Moreover the SuperCard message hierarchy works in such a fashion
that a foreground graphic stands *in front of all background buttons*. My
stacks don't work because the rectangle of the card graphic in SuperCard is
receiving (and eating!) the mouseEnter messages; the background buttons never
see them unless I happen to be outside the rectangle of the foreground
graphic. The obvious dodge of having a handler for the foreground graphic
that attempts to do a pass on the mouseEnter message doesn't seem to work.
I called Silicon Beach about this and got them to understand the problem, and
also made a suggestion for what I think is the right way to fix this. The
fellow I talked to on the hotline agreed it was a good suggestion. When you
get the object info dialogue box, you have a check-box for visible/invisible.
There needs to be an additional choice, participant/non-participant. The
visibility box would cover *only graphic* visibility; the participant box
would cover "message visibility". I.e. with visible on and participant off,
the object would be graphically visible but would be "not there" as far as the
message hierarchy was concerned. The default should be visible on and
participant off when converting HyperCard stacks. Currently the visible box
applies to both graphic and message visibility, and there's no way to separate
the two.
I don't know whether other people have run into my problem, but buyer beware:
if you use on mouseEnter for much of anything you could be in big trouble with
this release of SuperCard. (What was that someone said about not buying
release x.0 of *anything*? ...)
Incidentally the slow performance of SuperCard is every bit as bad as everyone
is saying. With their STEP feature they claim to be able to flash entire
cards as fast as 30 per second, but a series of hide graphic statements in a
handler -- where the graphics are only a very small part of the screen --
seems to execute no faster than one or two per second!!!
--
Jim Rosenberg
CIS: 71515,124 decvax!idis! \
WELL: jer allegra! ---- pitt!amanue!jr
BIX: jrosenberg uunet!cmcl2!cadre! /