tomj@oakhill.UUCP (Tom Johnson) (09/23/88)
In article <17439@apple.Apple.COM> dan@apple.com.UUCP (Dan Allen) writes: >In article <3047@pt.cs.cmu.edu> ns@cat.cmu.edu (Nicholas Spies) writes: >>IsADigit(c) -- return true if c is a digit >>....several deleted neat ideas... >>ParseFrom(text,string) -- return text from any character in string > >Good ideas. We'll see what we can do for 2.0... > >Dan Allen >Apple While we are (now) on the subject...how about a little help for those of us who would like to test for the presence of a file or volume (or MacServe, TOPS, or AppleShare partition) **prior** to attempting to open a file and have the open request trapped by Hypercard? This is a problem when you are attempting to design a stack for people who have only a vague idea of what a file **is**, much less where it lives. It sure would be handy to be able to code a script something like: if FExists(fname) then --do file stuff here endif or: if VExists(volume_name) and FExists(volume_name&":"&path&":"&fname) then --ditto above else beep answer "You must mount the volume" && volume_name endif That's my 3.295 cents worth. |Standard Disclaimer |Tom Johnson |tomj@oakhill.UUCP
ns@cat.cmu.edu (Nicholas Spies) (09/23/88)
Is there a way to tell whether you can evaluate the contents of a field (with "the value of") to avoid getting the error dialog when "the value of" fails? In general, HyperCard errors of all types should be trappable, instead of giving an unwelcome dialog warning. How about an "error" system message, so an "on error" handler could be written to handle illegal user inputs gracefully. The system does it already, in some sense, to provide the dialog boxes... -- Nicholas Spies ns@cat.cmu.edu.arpa Center for Design of Educational Computing Carnegie Mellon University