cash@csmil.umich.edu (Howard Cash) (05/16/89)
Here's another one of those programming tasks that I'm sure has been solved fifty-dozen times. I know the problem isn't tough, but why reinvent the wheel? Who is willing to part with the code for an editable text item that only accepts valid numbers (real or integer)? For an example, try the PRINT command in almost any application. There are usually two tedit records where you can input the first and last pages to be printed. Try typing in a non- numeric character and see what happens. Free chocolate at my place for the winning respondent. -Howard cash@csmil.umich.edu
odawa@well.UUCP (Michael Odawa) (05/18/89)
In article <1076@mailrus.cc.umich.edu> cash@csmil.umich.edu (Howard Cash) writes: > Who is willing to part with the code for an editable text item > that only accepts valid numbers (real or integer)? You can intercept the keystrokes in the FilterProc you call with ModalDialog. Then peek at every key event as it comes in. If it's not a digit, change the event into a nullEvent and mark it as handled: function AddFilter (Dlg: DialogPeek; var CE: EventRecord; var itemHit: integer): boolean; var begin AddFilter := false; if CE.what in [keyDown, autoKey] then if CE.modifiers = 0 then if not (BitAnd(CE.message, $00ff) in ['0'..'9']) then begin AddFilter := true; CE.what = nullEvent; end; { if not (BitAnd(CE.message, $00ff) in ['0'..'9']).. } end; { AddFilter } procedure MainDlgProc; var ItemNo; begin . . ModalDialog(@AddFilter, itemNo); . . end; > For an example, try the PRINT command in almost any application. The Print dialog is a special dialog that requires more effort to hack. You need to read Tech Note 95 to learn about this. > Free chocolate at my place for the winning respondent. Just send it to me over the net. :-) Michael Odawa Simple Software odawa@well.uucp
milne@ics.uci.edu (Alastair Milne) (06/02/89)
odawa@well.UUCP (Michael Odawa) writes >In article <1076@mailrus.cc.umich.edu> cash@csmil.umich.edu (Howard Cash) writes: >> Who is willing to part with the code for an editable text item >> that only accepts valid numbers (real or integer)? > >You can intercept the keystrokes in the FilterProc you call with >ModalDialog. Then peek at every key event as it comes in. If it's not >a digit, change the event into a nullEvent and mark it as handled: I have a small problem with that approach: the user has no way of knowing why his keystrokes aren't registering. There is nothing here to alert the user that only digits (and signs, and ".", etc.) are to be used. I think an alert is necessary for this, either right at the keystroke (perhaps the filterproc could show it, before turning the event into a null); but I don't know whether filterproc's are allowed to fire up alerts or dialogs. The other way, of course, is simply to let the user finish and enter the text, then give the alert and restart the entry if the format is not completely numeric. Advantages: simple slips of the finger are not rewarded with a whole alert, and the user gets the chance to edit and modfy as s/he sees fit. Now for the nasty part. I assuming we've been thinking so far about the entry of integers. What about real numbers? I may just have missed it, but I don't recall seeing any standards in I-M for real number format (beyond the settings of components that differ between countries.) Having worked on CAI material for some years, where such entry has to be made very tolerant for students who've never used a computer before, I can attest the number of difficulties to consider. Are there any standards for this? Alastair Milne
lippin@jif.berkeley.edu (The Apathist) (06/02/89)
Recently Alastair Milne <milne@ics.uci.edu> wrote: [...] > Now for the nasty part. I assuming we've been thinking so far about the > entry of integers. What about real numbers? I may just have missed it, but > I don't recall seeing any standards in I-M for real number format (beyond > the settings of components that differ between countries.) Having worked > on CAI material for some years, where such entry has to be made very > tolerant for students who've never used a computer before, I can attest the > number of difficulties to consider. Are there any standards for this? If you use the SANE routines (Str2Dec and a call to fp68k) to convert strings to numbers, you get error codes if the input isn't right. I haven't seen much documentation on how to use SANE, but it's not too hard to figure out from the Apple Numerics Manual (which I've only seen the preliminary edition of), and from looking through the files <sane.h> and the math libraries (in LSC; your development system may vary.) I found it worth knowing -- the routines are very versatile, and they make your code more internationally compatible. I even use the SANE routines to check the validity of integer input. In addition to using the SANE checks, you should, of course, check the range of your input, and also check that it is not a NAN (that is, a not-a-number). --Tom Lippincott lippin@math.berkeley.edu "Ask a fish head anything you want to. It won't answer you; they can't talk."
d83_sven_a@tekno.chalmers.se (Sven (Sciz) Axelsson) (06/02/89)
In article <25190@agate.BERKELEY.EDU>, lippin@jif.berkeley.edu (The Apathist) writes: > Recently Alastair Milne <milne@ics.uci.edu> wrote: > [...] >> Now for the nasty part. I assuming we've been thinking so far about the >> entry of integers. What about real numbers? I may just have missed it, but >> I don't recall seeing any standards in I-M for real number format (beyond >> the settings of components that differ between countries.) Having worked >> on CAI material for some years, where such entry has to be made very >> tolerant for students who've never used a computer before, I can attest the >> number of difficulties to consider. Are there any standards for this? > > If you use the SANE routines (Str2Dec and a call to fp68k) to convert > strings to numbers, you get error codes if the input isn't right. I > haven't seen much documentation on how to use SANE, but it's not too > hard to figure out from the Apple Numerics Manual (which I've only > seen the preliminary edition of), and from looking through the files > <sane.h> and the math libraries (in LSC; your development system may > vary.) I found it worth knowing -- the routines are very versatile, > and they make your code more internationally compatible. I even use > the SANE routines to check the validity of integer input. > > In addition to using the SANE checks, you should, of course, check the > range of your input, and also check that it is not a NAN (that is, a > not-a-number). How about using the new script manager routines Str2Format and FormatStr2X? They provide a totally general means of inputting numbers in any format using templates as in 4th Dimension, Excel etc. (i.e. you can input a telephone number as (123) 4567-890 and get back then numerical 1234567890). I haven't actually used these, but from reading the Script Manager manual that was posted to comp.binaries.mac a while ago they sure look useful. You might have some problems getting the glue to use these if you don't use MPW though. +-------------------------+--------------------------------+------------------+ | Sven Axelsson | d83_sven_a@tekno.chalmers.se | DISCLAIMER: | | dep:t of Linguistics | (^^ best ^^) | | | univ. of Gothenburg | dlv_sa@hum.gu.se | This is not | | SWEDEN | usdsa@seguc21.bitnet | a disclaimer. | +-------------------------+--------------------------------+------------------+
zben@umd5.umd.edu (Ben Cranston) (06/03/89)
In article <16413@paris.ics.uci.edu> Alastair Milne <milne@ics.uci.edu> writes: > odawa@well.UUCP (Michael Odawa) writes >> In article <1076@mailrus.cc.umich.edu> cash@csmil.umich.edu (Howard Cash) writes: >>> Who is willing to part with the code for an editable text item >>> that only accepts valid numbers (real or integer)? >> You can intercept the keystrokes in the FilterProc you call with >> ModalDialog. Then peek at every key event as it comes in. If it's not >> a digit, change the event into a nullEvent and mark it as handled: > ... the user has no way of knowing why his keystrokes aren't registering. > There is nothing here to alert the user that only digits > (and signs, and ".", etc.) are to be used. I think an alert is necessary... The Macintosh way of doing this would be to use staged alerts. For the first few bad keystrokes one would just beep. This is a cognitively cheap way to remind a knowlegable but confused user that he is doing something wrong. We let a few go by with beeps because it takes awhile to interrupt his keying and get his attention. He looks at the situation afresh, realizes he is in a numeric-only context, and proceeds to enter the CORRECT data. For the novice we set the last stage to be a fully-blown alert, which explains in excruciating detail (:-) just what is going on. Actually I really dislike being interrupted by alerts that are not any fault of my own, like SFPutFile DRIVE-ing into a write-inhibited volume. I would MUCH rather some indicator that does not need an explicit mouse click or CR on my part to dismiss. My personal suggestion would be a blinking line of text in the window, saying "write-inhibited disk" or something. The analogy with the above would be a blinking "please enter a number" or some such rot. If you think this intrusive, have it appear (or START blinking) on the first bad keystroke given. > Now for the nasty part. I assuming we've been thinking so far about the > entry of integers. What about real numbers? I may just have missed it, but > I don't recall seeing any standards in I-M for real number format (beyond > the settings of components that differ between countries.) Having worked > on CAI material for some years, where such entry has to be made very > tolerant for students who've never used a computer before, I can attest the > number of difficulties to consider. Are there any standards for this? Check the Apple Numerics (?) manual. If there isn't something in there, there should be (are we listening, Apple?). There is an internationalization issue here too, and I think this is an area in which Apple could profitably standardize... I'm a systems programmer. We don't do floating point... :-) -- Ben Cranston <zben@umd2.UMD.EDU> (Kingdom of Merryland UniSys 1100/92) Copyright 1989 (you may redistribute ONLY if your recipients can).