edmoy@violet.berkeley.edu (02/18/88)
Now that I've done some fairly heavy duty HyperCard programming (and having been in the programming business for about 10 years), I would like to see the following enhancements/fixes in some future version of HyperCard (they are in no particular order): 1) Background buttons and fields with either global of local states/data. Right now, background buttons have global state across all cards in the background, while background fields have local data (to each card). It would be nice to have background buttons with local states (each card would have its own state, but the same button across all cards). Also, having a background field with global data would be extremely useful, so that the same text put into the field would appear on all cards (and only with one copy of the text). 2) The offset() function is quite useful, but two other similar function would make life a lot easier. First, a function the returns the character position of the last occurrence of string is useful for pathname manipulation. Second, it would be nice to be able to start the search from an arbitrary position within the string. This is useful for searching for multiple occurrences of the same string, without having to copy string into a temporary variable and delete the first occurrence. 3) HyperCard should rebuild its desk accessory menu every time it opens a new stack. This would allow individual stacks to have private desk accessories. (Fonts already work fine.) 4) If openField messages are always generated when entering a field, then a corresponding closeField should also be generated when leaving, independent of the field being modified. The message could contain an argument, either true of false, whether the field was modified. Right now, I have a background with a lot of opaque fields that turn into rectangular fields when you click on them (showing it can be modified). Only one field at a time can be modified. Now, I have to have global variables that tell which field is currently opened, so that on opening another field, I can remember to close the last field. Without the closeField message always occurring, I have to test for the open field, not just on opening other fields, but for all buttons, and when clicking in the background or closing the card. This is very messy. 5) The fact that a newCard message comes AFTER the corresponding openCard message should be clearly documented, if not changed. The order of all such messages that occur more than one at a time should be documented (like closeCard and deleteCard). 6) On getting a deleteCard message, "exit deleteCard" should abort the delete, giving you a chance to save yourself. For consistency, this may mean that deleteCard handlers must have "pass deleteCard" to continue the delete. 7) Screen updates done seem to occur as expected when setting "lockScreen". Updates seem to stop sometime before the actual occurrence of "set lockScreen to true" and and don't continue right when setting it to false. I now have to do a "go this card" to refresh the screen, before setting the lockScreen. 8) I'd like to see List Manager functions in HyperCard. Sure, there is a XCMD that will pop up a temporary list dialog, but I'd like one that is permanent on a card. 9) Perhaps there should be a blank window object, that will allow XCMD's to maninpulate permanent areas of the card. These blank window objects could receive a new message, refreshWindow, when all or part need to be redrawn. This would allow some fancier graphics (or even animation) in cards. 10) "open printing with dialog" never returns to the handler if the user clicks "Cancel". I think it should return, with the button name clicked in "the result". 11) To design scripts, you have to be at the highest user level. Thus, scripts should be able to access all function independent of current userLevel setting. This would allow the script, acting in a stack at userLevel 2, to use the paint tool (userLevel 3) without letting the user at them. Also, a closeStack handler could compact the stack without changing the userLevel to at least 3. 12) HyperCard doesn't work well with desk accessories. Cutting and pasting between DAs and HC is tedious, because you either have to close the DA window each time, or use the trick I discovered, where you have the message box displayed, and you click on the message box titlebar to activate HC, with the DA window still visible. Why now just allow clicking on the card to activate HC, but still leave it behind any DA window? 13) From a previous message I sent out, but I want visual effects on my color monitor, without having to switch to 1 bit per pixel. It should at least be a user-defainable option. 14) The problem has since gone away, after converting all fields of a card to all the same font. But before, with different fonts in different fields, I would get fields using the same font to sometimes print using the built-in LaserWriter font (Courier in this case) or print using a bitmap of Courier. Strange indeed! 15) It might be useful to have a third type of variable, other than global and local ones. It is useful to a variable known up to a certain level (say only within the handlers of a single button, or up to a single background, etc). This might be a little confusing for a novice programmer, but is quite useful in sophisticated applications, where you might worry about having reused a global variable name. (for you C fans, this would be like the "static" declaration). Well, I think that is enough for now, though I would like to throw in one more thing, speed. Or lack thereof. I realize that HyperTalk is interpreted, but wouldn't it be nice to have a compiled option? Edward Moy Workstation Software Support Group University of California Berkeley, CA 94720 edmoy@violet.Berkeley.EDU ucbvax!violet!edmoy
syap@ur-tut.UUCP (James Fitzwilliam) (02/19/88)
> Edward Moy (edmoy@violet.berkeley.edu) writes: > 12) HyperCard doesn't work well with desk accessories. Cutting and pasting > between DAs and HC is tedious, because you either have to close the DA window > each time, or use the trick I discovered, where you have the message box > displayed, and you click on the message box titlebar to activate HC, with > the DA window still visible. Why now just allow clicking on the card to > activate HC, but still leave it behind any DA window? I found a fix for this in an Fkey available on sumex which sends the current active window to rear. This at least enabled me to use MockWrite-style one-window word processing DAs; hitting the Fkey would hide the DA, allowing a paste, and re-selecting the DA from the apple menu would bring it forward again. I think the sumex file is called WINDOW-FKEYS or something similar. If you're having trouble with ftp, I can try mailing, but our mail server is extremely buggy. I hadn't found the menubar trick; at least the Fkey keeps your mouse from wearing a rut in your desk during repeated cut/pastes. Hopefully in a future version clicking on HC will be supported. James domain: syap@tut.cc.rochester.edu path: rochester!ur-tut!syap "Piano is my forte" (-: GEnie: FITZWILLIAM ========================================================================
mab@batcomputer.tn.cornell.edu (Mark Bodenstein) (02/22/88)
In article <7019@agate.BERKELEY.EDU> edmoy@violet.berkeley.edu () writes: >6) On getting a deleteCard message, "exit deleteCard" should abort the >delete, giving you a chance to save yourself. For consistency, this may >mean that deleteCard handlers must have "pass deleteCard" to continue the >delete. More generally, there needs to be a mechanism to abort queued up system actions. Here's another example: I have a stack that does input consistency checking in a closeCard handler. Assume the user does something to leave the current card, and the closeCard handler finds bad input. What I'd like to do is put up an error message dialog box, and somehow tell HyperCard to STAY AT THE CURRENT CARD, allowing the user to fix the problem. What I've had to do instead is go through a perhaps lengthy series of dialogs to get the correct information. (Another solution would be to not show the menubar and/or trap for anything that causes us to leave the current card. I don't consider this an acceptable solution.) -- Mark Bodenstein {ihnp4,rochester}!cornell!batcomputer!mab mab@batcomputer.tn.cornell.edu