commons@Sunburn.Stanford.EDU (Peter Commons) (08/18/90)
Two questions about Editable Text Objects in Dialog Boxes: 1) Can you limit the length and/or prevent carriage returns? Theoretically I could check after every keypress to see if the length is too big or if they just hit return (and then delete the last character and redraw), but I was hoping for something nicer... 2) A month ago some people were saying that to make a password dialog where the password was not legible, you change the font to something where all chars are undefined??? How do I do this? Thanks. -- |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| | Peter Commons "Zut, alors! I have meesed one!!!" | | commons@cs.stanford.edu | | Computer Science Department, Stanford University |
jackiw@cs.swarthmore.edu (Nick Jackiw) (08/18/90)
commons@Sunburn.Stanford.EDU (Peter Commons) writes: > Two questions about Editable Text Objects in Dialog Boxes: > 1) Can you limit the length and/or prevent carriage returns? Theoretically I > could check after every keypress to see if the length is too big or if they > just hit return (and then delete the last character and redraw), but I was > hoping for something nicer... It's not that bad---you can forget the parenthetical part, at least. Install a filterProc--it will get called before _ModalDialog. Thus, if you get a keydown and the length of your item is at it's maximum, simply convert the keydown into a nullEvent. You might want to beep, to let them know they've typed enough, and you'll probably want to let backspace, delete, arrow-left, arrow-right, arrow-up and arrow-down pass through unscathed, so they can still edit even if they can't add more. Likewise, it's trivial for a filter to convert keydown/keyCode=13 (returns) into nullEvents. > 2) A month ago some people were saying that to make a password dialog where > the password was not legible, you change the font to something where all chars > are undefined??? How do I do this? Put up the dialog. DrawDialog. Then switch the font (TextFont) of the current port to something more interesting---Zapf Chancery or your own "every-character-a-bullet" font. Alternately, you can try intercepting and parsing all the keydowns in the way that editText does, store them yourself in some string, and convert them in your filterProc to bullet-downs (option-shift-8). This is much more of a hassle than the former method, however. > Thanks. > > > -- > |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| > | Peter Commons "Zut, alors! I have meesed one!!!" | > | commons@cs.stanford.edu | > | Computer Science Department, Stanford University | -- _ _|\____ Nick Jackiw | Visual Geometry Project | Math Department / /_/ O> \ ------------+-------------------------+ Swarthmore College | O> | 215-328-8225| jackiw@cs.swarthmore.edu| Swarthmore PA 19081 \_Guernica_/ ------------+-------------------------+ USA
ts@cup.portal.com (Tim W Smith) (08/19/90)
In your filterproc, store the "real" character off in some string, and then convert the event to have some character like "*". When the dialog is done, you can check the string to see what the password was. I like this better than changing the font, because then you have to worry about someone replacing that font with something that has all the characters, and then passwords show up. Maybe you can prevent this somehow, but why take chances? Tim Smith
urlichs@smurf.sub.org (Matthias Urlichs) (08/20/90)
In comp.sys.mac.programmer, article <4X6NVMD@cs.swarthmore.edu>, jackiw@cs.swarthmore.edu (Nick Jackiw) writes: < commons@Sunburn.Stanford.EDU (Peter Commons) writes: < > 1) Can you limit the length and/or prevent carriage returns? Theoretically I < > could check after every keypress to see if the length is too big or if they < > just hit return (and then delete the last character and redraw), but I was < > hoping for something nicer... < < [...] Thus, if you get a < keydown and the length of your item is at it's maximum, simply convert the < keydown into a nullEvent. You might want to beep, to let them know they've < typed enough, and you'll probably want to let backspace, delete, arrow-left, < arrow-right, arrow-up and arrow-down pass through unscathed, so they can < still edit even if they can't add more. < I think that the first method (deleting any characters after the Nth) is better. - Typing in the middle does what the user would expect. - Supporting Paste, likewise. - It's easier to program -- just check for length in the beginning of the filterproc, before you even look at the event, and if it's too long (by however many characters), shorten and beep. Likewise, if it's empty, replace with default selection but don't beep. (Instead, select the whole replacement so that typing after a backspace still works.) < Likewise, it's trivial for a filter to convert keydown/keyCode=13 (returns) < into nullEvents. Or beeps, or Tabs, or whatever. (When the user does something, something should happen.) < <>2) A month ago some people were saying that to make a password dialog where <>the password was not legible, you change the font to something where all chars <>are undefined??? How do I do this? < < Put up the dialog. DrawDialog. Then switch the font (TextFont) of the < current port to something more interesting---Zapf Chancery or your own < "every-character-a-bullet" font. Alternately, you can try intercepting < and parsing all the keydowns in the way that editText does, store them < yourself in some string, and convert them in your filterProc to bullet-downs < (option-shift-8). This is much more of a hassle than the former method, < however. < Hassle? Not at all. Just take canned code...: (from SingleShare's password handling dialog, managing two passwort fields which should be identical:) Cut/Copy/Paste are not allowed. Neither is autorepeat. This is supposed to be a write-only password, after all. Not changing the dialog's TextFont has the further advantages that (a) you can have other editable fields in it, (b) the whole thing is still legible after Pyro has been messing up the screen. ;-) BTW, the % down there is supposed to be a bullet character. Handling the EditText itself is left as an exercise to the Dialog Manager. :-) ELSE IF (dialogPeek(theDialog)^.editField = inPW1-1) OR (dialogPeek(theDialog)^.editField = inPW2-1) THEN BEGIN selStart := dialogPeek(theDialog)^.textH^^.selStart; selEnd := dialogPeek(theDialog)^.textH^^.selEnd; isPW1 := dialogPeek(theDialog)^.editField = inPW1-1; IF isPW1 THEN PW := thePW1 ELSE PW := thePW2; IF ch = CHR(bs) THEN BEGIN IF selStart = selEnd THEN BEGIN IF selStart > 0 THEN PW := concat(copy(PW,1, selStart - 1), copy(PW, selStart + 1, length(PW) - selStart)); END ELSE PW := concat(copy(PW, 1, selStart), copy(PW, selEnd + 1, length(PW) - selEnd)); END ELSE BEGIN PW := concat(copy(PW, 1, selStart), ch, copy(PW, selEnd + 1, length(PW) - selEnd)); theEvent.message := BitAnd(theEvent.message, -1-charCodeMask) + ord('%'); END; IF isPW1 THEN thePW1 := PW ELSE thePW2 := PW; END; END -- Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(Voice)/621227(PEP)
mattiasb@nada.kth.se (Mattias Berglund) (09/07/90)
An easy way to have a password field in a modal dialog is to modify the Quickdraw bottleneck procedures StdText and StdTxMeas of the Dialog- Record in question. If the text to draw or measure is the one to be protected, the procedure simply draws or measures bullets (or whatever), otherwise it draws the requested text. The tricky part is knowing if the text is that of the protected field. My solution is to save the handle of the desired field (as returned by GetDItem) in a global variable. Later I can check if the pointer passed as an argument falls within this handle. Mattias Berglund mattiasb@cyklop.nada.kth.se