[comp.sys.mac.hypercard] HyperCard experience so far

marlene@arc.ab.ca (Marlene Jones) (01/15/91)

I've been developing a project that uses HyperCard 2.0 as the front end.  My 
general reaction is positive.  Even so, there are some problems that 
I've uncovered that may be of interest as well as some of the things in HC 
that have made my job more difficult than should have been necessary.


HC Bugs:
(1)  The openField message does not get sent to an unlocked field if the
first mouse click in the field is on the scrollbar.
(2)  The mouseEnter message does not get sent to a field if the window
containing the field is made active by a mouse click within the field.
(3)  Typing the command-. character in a dialog box aborts a script that has 
the cantAbort property set to true.  To be fair, it isn't clear what should be 
done in this case.  Perhaps the dialog should return a result of "aborted"?
(4)  Move the window of a stack off of the screen.  Close the stack.  Reopen 
the stack.  The stack reappears.  I can understand the motivation for 
making the stack visible upon open, but a stack wouldn't
become invisible in this manner without some explicit (and desired) scripted
action.  Can you guess?   I want to launch HC without having the home stack
appear.
(5)  It is possible to edit the script of a stack whose cantPeek property is 
set to true.
(6)  I have a stack whose double click (causing the launch of HC) followed by 
a rash of command-. keyclicks sometimes causes the system to freeze.

Some of my HC Peeves:
(1)  There is no concept of a script-local variable.
(2)  There are no #define style constants.
(3)  32K maximum fields and scripts (I know, I know)
(4)  There is no doToggle type of operation for type faces a la TESetStyle.
At least I have discovered the high-order bit of tsFace for the groups
style, but it is really silly to have to copy a whole field via
GetFieldTE, change the styles efficiently, and then replace via
SetFieldTE.
(5)  Clicking an autoHilite button (that has no script) causes a disk access.
(6)  It is far too difficult to tell what portion of a scrollable field is 
currently visible when it is not the case that every line is terminated by a 
return character.  You have to recompute where the word wrap occurs on every 
line.  This is not something that is done on-the-fly in an efficient
manner.
(7)  There are no messages indicating a scroll has occurred, though you can
cause a scroll by making your own buttons and placing them over the scrollbar 
buttons.

Hope this list is of some use.

	Dan Field