marlene@arcsun.arc.ab.ca (Marlene Jones) (01/19/91)
I've been developing a project that uses HyperCard 2.0 as the front end. My general reaction is generally 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. (7) Executing the following handler in a scrolling field when the field is not currently open causes an exitField message to be sent immediately after the scroll is set in line 3: on doIt put the scroll of me into saveScroll select char 1 to 10 of me set the scroll of me to saveScroll answer "The exitField message was sent prior to this command" end doIt 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.
wilkins@jarthur.Claremont.EDU (Mark Wilkins) (01/19/91)
In article <1991Jan18.190735.17999@arc.ab.ca> marlene@arcsun.arc.ab.ca (Marlene Jones) writes: >HC Bugs: [ Bugs deleted ] >(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. A stack, in fact, can become invisible in that manner without a scripted action. In fact, this situation is far more common than are scripts which move the window offscreen. Suppose you create a stack on a 19" monitor, move it to the lower-right corner, and quit HyperCard. Drag your stack onto a floppy and take it over to your Mac Plus. Chances are that when you open the stack on the Plus you want it on the screen. A suggestion to the HyperCard team might be to check, when the stack's position is being saved, whether the stack intersects at all with the current screen, and if not, then the next time the stack is opened the code which moves the window onscreen is not executed. However, this flies in the face of the assumption that most people don't want their open stacks inaccessible, and could lead to serious user interface difficulties. -- Mark Wilkins P.S. A better way is some kind of "hide stack" command which takes care of it for you, in case someone is thinking of implementing this. -- ******* "Freedom is a road seldom traveled by the multitude!" ********** *-----------------------------------------------------------------------------* * Mark R. Wilkins wilkins@jarthur.claremont.edu {uunet}!jarthur!wilkins * ****** MARK.WILKINS on AppleLink ****** MWilkins on America Online ******
jkc@Apple.COM (John Kevin Calhoun) (01/19/91)
In article <10350@jarthur.Claremont.EDU> wilkins@jarthur.Claremont.EDU (Mark Wilkins) writes: > Suppose you create a stack on a 19" monitor, move it to the lower-right >corner, and quit HyperCard. Drag your stack onto a floppy and take it over >to your Mac Plus. Chances are that when you open the stack on the Plus you >want it on the screen. I doubt that you have actually tried this. When you open a stack on a machine with a different configuration of monitors then the machine on which it was last opened, HyperCard 2.0 will center the stack on the current monitor. Kevin Calhoun HyperCard Team Apple Computer, Inc.
wilkins@jarthur.Claremont.EDU (Mark Wilkins) (01/19/91)
Kevin Calhoun writes: > >In article <10350@jarthur.Claremont.EDU> wilkins@jarthur.Claremont.EDU >(Mark Wilkins) writes: >> Suppose you create a stack on a 19" monitor, move it to the lower-right >>corner, and quit HyperCard. Drag your stack onto a floppy and take it over >>to your Mac Plus. Chances are that when you open the stack on the Plus you >>want it on the screen. > >I doubt that you have actually tried this. > >When you open a stack on a machine with a different configuration of >monitors then the machine on which it was last opened, HyperCard 2.0 >will center the stack on the current monitor. That's exactly why I made the point. The original poster was complaining about that behavior, and I was explaining why HyperCard did what it did. The poster claimed that this was undesirable because of an associated behavior which causes card windows which are offscreen to be moved onscreen the next time the stack was opened, rather than remaining offscreen. She wanted to get rid of her home stack window by moving it offscreen, permanently. I just wanted to make clear that I believe the way the HyperCard team handled that particular user interface issue is the best way, not to mention firmly within the user interface guidelines suggested by Apple. Did I misunderstand what you were getting at? -- Mark Wilkins -- ******* "Freedom is a road seldom traveled by the multitude!" ********** *-----------------------------------------------------------------------------* * Mark R. Wilkins wilkins@jarthur.claremont.edu {uunet}!jarthur!wilkins * ****** MARK.WILKINS on AppleLink ****** MWilkins on America Online ******
jkc@Apple.COM (John Kevin Calhoun) (01/20/91)
My apologies to Mark Wilkins. And my thanks also, for clearing things up. Kevin Calhoun