roebuck@dvinci.USask.CA (Terry Roebuck) (06/10/89)
I have been a long time reader of this newsgroup and want to first compliment the group for the overall quality of the articles posted. I have a few small suggestions to make regarding future releases of hyperCard. 1) there should be a method of clearing (on request) at least the values, if not the actual GLOBAL variables used in a stack (like clearGlobal <globalName>). A most interesting debugging situation can arise when you traverse different stacks where authors have used the same variable name (like theUserLevel) to hold a value. 2) when you select 'new stack' you are prompted (via checkBox) to 'copy current background', the default. While more experienced authors are aware that this implies copy of the script of the current background, I suspect that there are a lot of stacks in use now that carry with them such 'scriptBits' as the script of the background of the home stack - another interesting debugging situation. An additional checkBox (copy script of current background) would help. 3) stack security is almost humerous. While hyperCard is NOT AN APPLICATION DEVELOPMENT TOOL (like MacApps, MPW, etc.) it appears that more and more application development IS occuring (applications for the rest of us ;-). For example, consider the ASK PASSWORD "question" with "string". A posible method for authorWare security - I realize that this can now be done, BUT try and ASK a question that will not echo the response. There is no method that I am aware of to stop commands like "put the script of stack xxx into field yyy" so any method that involves storing of the response is flakey at best (illusionary security being worse in the long run than no security). Compile of key script segments into xcmds or xfcns will help (though this is already past the rest of us, and into the best of us :-). This is a non-trivial change; consider the ease of virus writing in hyperCard (set the script of stack home to myVirusContainer) or using resCopy/resMover/xCmds to trash or alter resources. Would you like to have 'write-locked, no peeking' scripts in stacks? Would you trust the author? Maybe the better answer is 'allow peeking but no-changes", which is only possible if there are are mechanisms to avoid hard coding expected responses (see point 8) but then you would have to (and I assume do) take great care in running any stack not self-authored. 4) extraneous event trapping (by this I mean for example, the extra mouseClick that causes the handler to execute twice - especially a problem when designing stackWare for children (and PH.D's - NOTE: no funny face). A simple xcmd can be generated like FlushEvent(everyEvent,0), but the ramifications of a complete flush of a users event queue is not clear (like on a network with multifinder); better would be a supported series, like Flush <type of event> which could be added before a hander end to take care of any user events that may have occured while the handler was executing. (I found even the everyEvent option very handy when scripting for my 3 year old who has a habit of 'multiClicking' instead of just watching the pretty pictures.) 5) Admitting my ignorance in advance (always safe) I can not see a method for control of the cursor position from a script (I can change the clickLoc, but the mouse position is represented in the MAC user metaphor by the location of the cursor, which (I think) is handled via hardware interupt at a level far below that of the TOOLBOX calls - there may be a method here; CONTEST!!!! write a handler that drags the CURSOR to a new location! (Say that you wanted to have a stack that shows a 'user' working). PRIZES!!!? A note for the contestants: remember that the cursor position on launch of hyperCard is the same after the launch and the same after you quit ... By adding this ability (if possible) several interactive training stacks can be designed.... 6) The HELP stack is a lot more valuable to people who have the basic overview of object orientated programming (even if hyperTalk is not a classic object orientated programming language, it sure can act that way) - some better overview (reference) in this regard would not be out of line I think. 7) Better abilities to communicate with other applications would be a real plus. For example, the DA menu is reachable from hyperTalk just as any other menu item (try domenu "find file" in the msgBox for example). Now try to pass the name of the file to find. Smart are you? Then try and get the found location. (SEND <message> TO MENU <menuItem> would be interesting). GET would be alot harder I think.... 8) A big weakness (I think) is the lack of (writtable and secure) storage space for handlers - a file is too cumbersome; you have to check if its there or create it, (buggy in old versions, user device may be write locked, stack may be locked by another user on network, etc.) and the use of a file violates the stackware metaphor. Globals are only possible if you plan on recreating the contents (but then you have to do this on every openStack to be sure or check the contents of the global - OK as a workaround). What I had in mind is a 'permanent' container, accessed like a global - probably stored as a resource. (Again, writtable as a xcmd but see next point ... ). A current workaround would be to use the script space of some available object, since you can load and unload it - this is slow, cumbersome and lacks the access control of a container. 9) I am concerned about a side effect I see developing with the concept of the xcmd. [You have probably already decided that everything I have suggested should be built (by me) as an xcmd]. Increasingly, xcmds and 'extensible' hyperTalk (a wonderful feature) is being used to 'patch' weaknesses in the original hyperTalk vocabulary. A good example is the S.Maller(?) fileNames (etc.) Xcmds to handle opening of files with a standard dialoge box. This is obviously a better way to open for interactive situations, and should be part of the language. Failing this makes new users climb a real training curve before they might have to (the MAC as a library of Resources - here's how resources work - here is how to call them - use them - move them - an analogy that works for me in training hyperTalk). Now before I have to get an asbestos suit (or forward mail to /bin/bit/bucket :-) let me add that I am aware of 'Resource Mover', 'ResCopy' and HyperSound and other make-it-easy stacks, but my point is that a lot of potential authors do not have access to these stacks, or have any idea at all about extension for that matter, the use of xcmds is great but there should be some concern at Apple to see that xcmds that are are valid for a large (or all of the) user community should eventually migrate into a release as a supported feature. (This would also encourage more xCmd development, but would be a real legal foo-for-all for copywrite reasons; say, given the apparent size of Apple's legal department, maybe that's a feature not a problem :-) In looking back at this message before posting it (a wild and crazy kind of radical idea not much in vogue) I may have left the impression that hyperCard and hyperTalk is no friend of mine; let me correct that; I suspect that the future of the MAC is closely linked with the ease of end-user development. HyperCard with its broad distributed base, object orientated structure and easy syntax and type checking offers the potential for the fufillment of the role of the computer as an extension of the human mind. ------------------------------------------------------------- DISCLAIMER: These are my opinions. I like them. I will stand by them. I have a deal with the University; I work and they pay me. ------------------------------------------------------------- Terrance (Terry) Roebuck * Dept. of Computing Services * University of Saskatchewan * Saskatoon, Sask., CANADA * "It never rains but it freezes" S7N 0W0 (306) 966 - 4841 * - tr in the great white north BITNET: roebuck@Sask.Usask.CA * -------------------------------------------------------------
np@doc.ic.ac.uk (Nigel Perry) (06/15/89)
Terry Roebuck set a "challange" to move the cursor under script control.
An XCMD to do this has been sent to sumex and should appear soon - note
of course thgat this violates Apple User Interface Guidelines, so I'm
waiting the knock on the door from the thought police!
(Stacks mailed to sumex include a resource library, MacinTalk plus
miscellaneous stuff. You'll find ControlLock, StandardFile, SortLines
plus many other XMCD/XFCN's in there + a couple of XPRC's to handle
global storage for XCMD/XFCN's - another of Terry's requests.)
---
Nigel Perry Department of Computing
Imperial College
Janet: np@uk.ac.ic.doc London
DARPA: np%uk.ac.ic.doc@ucl-cs SW7
Uucp: np@icdoc.UUCP, ukc!icdoc!np Englandmjohnson@Apple.COM (Mark B. Johnson) (06/17/89)
In article <894@gould.doc.ic.ac.uk> np@doc.ic.ac.uk (Nigel Perry) writes: > > >Terry Roebuck set a "challange" to move the cursor under script control. >An XCMD to do this has been sent to sumex and should appear soon - note >of course thgat this violates Apple User Interface Guidelines, so I'm >waiting the knock on the door from the thought police! Knock, knock. Very naughty. Enough said. Mark B. Johnson AppleLink: mjohnson Developer Technical Support domain: mjohnson@Apple.com Apple Computer, Inc. UUCP: {amdahl,decwrl,sun,unisoft}!apple!mjohnson "You gave your life to become the person you are right now. Was it worth it?" - Richard Bach, _One_