moore@cs.washington.edu (Charles Moore) (06/05/90)
It appears to me that with the Ask command there is no way to distinguish between the user clicking "Cancel" and clicking "OK" with an empty edit window. Thus, if empty is a legitimate answer to the question, one can't use Ask. Is this really the case, or am I missing something (like a more recent version of Hypercard)? Charles Moore
jgsmith@watson.bcm.tmc.edu (James G. Smith) (06/05/90)
I also noticed that problem with the Ask command (clicking "Okay" with a blank line looks just like clicking "Cancel"). My answer to this was to: ask "Whatever" with " " --I forget whether there is a variable called space The major problem with this approach is aesthetic. The whole blank line is selected. Otherwise, it seems to work. (i.e. if the user just clicks okay, then it contains a space instead of being empty). * (I live to kludge)
moore@cs.washington.edu (Charles Moore) (06/06/90)
In article <1010@gazette.bcm.tmc.edu>, jgsmith@watson.bcm.tmc.edu (James G. Smith) writes: > > I also noticed that problem with the Ask command (clicking "Okay" with a > blank line looks just like clicking "Cancel"). My answer to this was to: > > ask "Whatever" with " " --I forget whether there is a variable called space > > The major problem with this approach is aesthetic. The whole blank line is > selected. Otherwise, it seems to work. (i.e. if the user just clicks okay, > then it contains a space instead of being empty). That's a good idea but it doesn't work as well when the default answer should be something other than empty. In that case (also my case), the user has to hit the delete key and then type a space in order to achieve the empty response. Unfortunately, that's pretty unintuitive. Charles
sirkm@ssyx.ucsc.edu (Greg Anderson) (06/06/90)
In article <12142@june.cs.washington.edu> moore@cs.washington.edu (Charles Moore) writes: >It appears to me that with the Ask command there is no way to >distinguish between the user clicking "Cancel" and clicking "OK" with >an empty edit window. Thus, if empty is a legitimate answer to the >question, one can't use Ask. Is this really the case, or am I missing >something (like a more recent version of Hypercard)? That's pretty much the state of things. I've written an ask XFCN that behaves identically to "ask" (right down to the undesirable behavior you describe)--plus, it allows the user to enter "secret" things (which show up as bullets instead of clear text). It would not be difficult to modify my XFCN so that pressing "Cancel" returns the string litteral "Cancel" instead of empty. Of course, you then would be unable to distinguish between the user typing "Cancel" and hitting "OK" with a normal click on the "Cancel" button, but this isn't a terrible handicap. If someone does the modification, it should really be made an option of the ask XFCN. The XFCN is already set up to accept "secret" and "password" options; just add a "cancel" option. Source is available for anonymous ftp from ssyx.ucsc.edu -- I think. I can put it up if it's not there. ___\ /___ Greg Anderson ___\ /___ \ \ / / Social Sciences Computing \ \ / / \ /\/\ / University of California, Santa Cruz \ /\/\ / \/ \/ sirkm@ssyx.ucsc.edu \/ \/
tom@wcc.oz (Tom Evans) (06/07/90)
In article <12142@june.cs.washington.edu>, moore@cs.washington.edu (Charles Moore) writes: > It appears to me that with the Ask command there is no way to > distinguish between the user clicking "Cancel" and clicking "OK" with > an empty edit window. I always pop up an "answer "Blank Ehtry of Cancel?" with "Cancel" or "Blank" ". Crude but effective. You can always "roll your own" dialog box (Field, buttons which are normally hidden but are made visible by the script) but it is a pest. --------- Tom Evans tom@wcc.oz.au | Webster Computer Corp P/L | "The concept of my 1270 Ferntree Gully Rd | existence is an Scoresby VIC 3179 | approximation" Australia | 61-3-764-1100 FAX ...764-1179 | D. Conway
pepke@gw.scri.fsu.edu (Eric Pepke) (06/08/90)
In article <4120@darkstar.ucsc.edu> sirkm@ssyx.ucsc.edu (Greg Anderson) writes: > It would not be difficult to modify my XFCN so that pressing "Cancel" > returns the string litteral "Cancel" instead of empty. Of course, you > then would be unable to distinguish between the user typing "Cancel" > and hitting "OK" with a normal click on the "Cancel" button, but this > isn't a terrible handicap. One could pass the cancel string in the invocation of the XFCN. Then it would be up to the caller to use a string that would be an inappropriate answer for the particular question. A truly paranoid caller might build the string from characters that cannot be typed. Eric Pepke INTERNET: pepke@gw.scri.fsu.edu Supercomputer Computations Research Institute MFENET: pepke@fsu Florida State University SPAN: scri::pepke Tallahassee, FL 32306-4052 BITNET: pepke@fsu Disclaimer: My employers seldom even LISTEN to my opinions. Meta-disclaimer: Any society that needs disclaimers has too many lawyers.
sirkm@ssyx.ucsc.edu (Greg Anderson) (06/10/90)
In article <72@sun13.scri.fsu.edu> pepke@gw.scri.fsu.edu (Eric Pepke) writes: >In article <4120@darkstar.ucsc.edu> I write: >> It would not be difficult to modify my XFCN so that pressing "Cancel" >> returns the string litteral "Cancel" instead of empty. > >One could pass the cancel string in the invocation of the XFCN. Then it >would be up to the caller to use a string that would be an inappropriate >answer for the particular question. A truly paranoid caller might build >the string from characters that cannot be typed. A most excellent idea. Also: put "a bunch of option characters" & the ticks into cancelstring ... would insure that the user could not 'forge' a cancel even if he knew how the stack was written. This is, of course, overkill, as the idea is not to prevent the user from forging a cancel, but to distinguish a cancel from useful input. If no one makes this mod right away, I'll do it after I graduate. (One more week...) ___\ /___ Greg Anderson ___\ /___ \ \ / / Social Sciences Computing \ \ / / \ /\/\ / University of California, Santa Cruz \ /\/\ / \/ \/ sirkm@ssyx.ucsc.edu \/ \/