[comp.sys.mac.programmer] ModalDialog filterprocs

oster@dewey.soe.berkeley.edu (David Phillip Oster) (12/27/89)

In article <10125@saturn.ucsc.edu> sirkm@ssyx.ucsc.edu (Greg Anderson) writes:
>I wrote a filterproc for ModalDialog that allows the user to cut, copy
>and paste to fields in a modal dialog box by pressing command-c, command-x
>and command-v, respectively.  The filterproc works great--cutting and
>pasting work as expected.  However, if the user presses <Return>,
>ModalDialog no longer returns with itemHit = 1.

>pascal int cutPasteFilter( DialogPtr dlog, EventRecord *theEvent, int *itemHit )
        ^^^
Should be:
pascal Boolean cutPasteFilter( ...

remember, in pascal a Boolean and an "int" are not the same, or even
compatible. A pascal Boolean TRUE looks like 0x01?? as an integer on the
stack.

In addition, your filterProc should also:
1.) handle <Command>-. or <Escape> as synonyms for Cancel.
2.) handle <Clear> as a synonym for clear (from the edit menu.)
3.) handle the <undo> <cut> <copy> & <paste> keys on the extended keyboard.
4.) handle <Shift>Tab to tab backwards  through the fields.
5.) On synonyms for Edit commands, flash the word "Edit" on the menu bar.
6.) On synonyms for buttons, flash the button for a fraction of a second
	before disposing the dialog.
7.) handle <Command>-Z as a synonym for undo.
8.) support undo of the Edit commands, and of typing.
9.) if the dialog includes any scrollbars, then the <home> <end> <page up>
and <page down> keys one the extended keyboard apply to the scrollbar. If
there are more than one scrollbar, they apply to the one with data that
was most recently acted upon.
10.)  <Option>-<UpArrow> is a synonym for <Page Up>, <Option>-<Down
Arrow> is a synonym for page down. <Command>-<UpArrow> is a synonym for
<home> and <Command>-<DownArrow> is a synonym for <end>.
11.) Scrollbars are governed in a processor-speed-independent manner, so
they won't scroll too fast on fast machines.

At least, that is what _my_ filterProcs do. For an example, see my program
"Address Book Plus", from Power-Up! software of San Mateo, CA.

I am currently adding:
12.) Handle the <help> button, on the extended keyboard to bring up help
about this dialog.
13.) Handle <Command>-?  or <Command>-/  (on the same key in the U.S.)
as synonyms for the <help> button.

There is some justification for all of the above points in the user
interface guidlines. Have I left anything reasonable out?

Do you think we should have:
a.) smart quotes? (i.e., replace  "'" and '"' by the appropriate opening
and closing left and right quote marks.)

b.) smart cut & paste? (i.e., when you cut text, it remembers whether the
text ended or began on a word boundary, and deletes extra white space if
so. When you paste, if deletes or inserts white space as necessary.) (This
is documented in the User Interface Guidelines. Few programs bother with
it.)

c.) transform <Capital-Oh> to <Zero> and <Small-El> to <One> in numeric
only fields?

--- David Phillip Oster            --  No, I come from Boston. I just work
Arpa: oster@dewey.soe.berkeley.edu --  in cyberspace.
Uucp: {uwvax,decvax}!ucbvax!oster%dewey.soe.berkeley.edu

d88-jwa@nada.kth.se (Jon Watte) (12/27/89)

In article <33385@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes:

>pascal Boolean cutPasteFilter( ...

>remember, in pascal a Boolean and an "int" are not the same, or even
>compatible. A pascal Boolean TRUE looks like 0x01?? as an integer on the

pascal char works, on the other hand... :-)


>In addition, your filterProc should also:

Many good suggestions deleted. Now, why doesn't the ROMs support these
nifty features in a flexible way ? It sure would be "easy" to add ! (At
least easier than every programmer doing it his own way)

>At least, that is what _my_ filterProcs do. For an example, see my program
>"Address Book Plus", from Power-Up! software of San Mateo, CA.

Great ! Send me a (free) copy and I'll admire you !

>I am currently adding:
>12.) Handle the <help> button, on the extended keyboard to bring up help
>about this dialog.
>13.) Handle <Command>-?  or <Command>-/  (on the same key in the U.S.)
>as synonyms for the <help> button.

Remember to handle foreign keyboards as well ! I have ? as Shift-+,
and / as shift-7

>There is some justification for all of the above points in the user
>interface guidlines. Have I left anything reasonable out?

Intelligent cut&paste

>Do you think we should have:
>a.) smart quotes? (i.e., replace  "'" and '"' by the appropriate opening
>and closing left and right quote marks.)

Nope. There is lotsa room for ambiguities here. Also, these standards
differ between coutries.

>b.) smart cut & paste? (i.e., when you cut text, it remembers whether the

Oh, there it was. Yes, I like this. MS Word uses it to some extent, but not
the full-fledged version.

>c.) transform <Capital-Oh> to <Zero> and <Small-El> to <One> in numeric
>only fields?

Nope. Beep on all non-numerical signs in a numerical.only field. Remember
that different countries have different comma-point-thousend-whatever-
characters.

Happy hacking !

-- 
   ---  Stay alert !  -  Trust no one !  -  Keep your laser handy !  ---
             h+@nada.kth.se  ==  h+@proxxi.se  ==  Jon Watte
                    longer .sig available on request

sirkm@ssyx.ucsc.edu (Greg Anderson) (12/28/89)

Thanks to all who pointed out that my filter declaration should read:

pascal Boolean cutPasteFileter(
       ^^^^^^^
	DialogPtr dlog, EventRecord *theEvent, short *itemHit)
	                                       ^^^^^

In article <33385@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes:
>In addition, your filterProc should also:
>1.) handle <Command>-. or <Escape> as synonyms for Cancel.
>2.) handle <Clear> as a synonym for clear (from the edit menu.)
>3.) handle the <undo> <cut> <copy> & <paste> keys on the extended keyboard.
>5.) On synonyms for Edit commands, flash the word "Edit" on the menu bar.
>6.) On synonyms for buttons, flash the button for a fraction of a second
>	before disposing the dialog.

Those are good suggestions, and are simple enough to implement.  I'll add
those features right away.

>4.) handle <Shift>Tab to tab backwards  through the fields.

How should that be done?  Forge a mouseDown event inside the appropriate
editable text field?

>8.) support undo of the Edit commands, and of typing.
>7.) handle <Command>-Z as a synonym for undo.

My filterProc is being called from a dialog box that is invoked from a
desk accessory, so I can't use globals in the usual way (I have a Handle
that holds all of the global data, & pass that from routine to routine).
Any suggestions on how I might pass this handle into the filterProc?

>11.) Scrollbars are governed in a processor-speed-independent manner, so
>they won't scroll too fast on fast machines.

How do you determine if the user is clicking in a scrollbar?  Use a custom
filterProc for each dialog that 'knows' (via hard-coding) which items have
scrollbars?

>9.) & 10.)
 [stuff related to keyboard equivalents for scrolling lists deleted]

I can do that, but there's still the problem of recognizing scrollable
items (I'm begining to think that custom filterProcs, rather than one
general one, is the only feasible solution to this problem) and getting
the ListHandle passed into the filterProc.

>At least, that is what _my_ filterProcs do. For an example, see my program
>"Address Book Plus", from Power-Up! software of San Mateo, CA.

I'll try to do that.

>Do you think we should have:
>a.) smart quotes? (i.e., replace  "'" and '"' by the appropriate opening
>and closing left and right quote marks.)

I don't like smart quotes.  They might be nice in a Word Processor, perhaps,
but once someone put an INIT on my Mac (the Black Box?) that did smart
quotes in ALL applications -- even the MPW editor!  _That_ was very annoying.

>b.) smart cut & paste? (i.e., when you cut text, it remembers whether the
>text ended or began on a word boundary, and deletes extra white space if
>so. When you paste, if deletes or inserts white space as necessary.) (This
>is documented in the User Interface Guidelines. Few programs bother with
>it.)

Sounds like a nice feature, but I can see why few programs bother to do it.
It's not very noticable when present, and not terribly annoying when absent.

>c.) transform <Capital-Oh> to <Zero> and <Small-El> to <One> in numeric
>only fields?

Since this is only a few lines of code, you might as well do it, but I
think it should be an undocumented feature, not something that people
start expecting all dialog boxes to do automatically.

>--- David Phillip Oster            --  No, I come from Boston. I just work
>Arpa: oster@dewey.soe.berkeley.edu --  in cyberspace.
>Uucp: {uwvax,decvax}!ucbvax!oster%dewey.soe.berkeley.edu


  ___\    /___               Greg Anderson              ___\    /___ 
  \   \  /   /         Social Sciences Computing        \   \  /   /
   \  /\/\  /    University of California, Santa Cruz    \  /\/\  /
    \/    \/              sirkm@ssyx.ucsc.edu             \/    \/

oster@dewey.soe.berkeley.edu (David Phillip Oster) (12/29/89)

Here are some more things your filterProc should do, that mine does, that
I forgot in my previous message:
12.) supress and ignore Cut/Copy/Clear commanas if nothing is selected.
13.) change the mouse cursor to an I-Beam if it is over a edittext field, and
	back to an arrow when it leaves it.
14.) When you start typing, the dialog manager does an ObscureCursor(). If
you terminate the dialog by using a button equivalent, the cursor is still
obscured.Your filter proc should  force the cursor visible on dialog
exit.
15.) if I have scrollbars or ListManager items in a dialog, pass them
Activate & Deactivate events.
16.) filter invisible control characters out of the input stream so they
won't get into editText items.

Another area where I have to improve:
) Beep if a keystroke is inappropriate for the type of an editText entry,
for example trying to type 'A'..'Z' in a numeric only field.

">" is sirkm@ssyx.ucsc.edu (Greg Anderson)
">>" is me
>>5.) On synonyms for Edit commands, flash the word "Edit" on the menu bar.

Don't forget: (like ACTA forgets) ignore Cut/Copy/&Clear commands if no
text is selected.  It is obnoxious to simply empty the clipboard, placing
nothing there.

>>4.) handle <Shift>Tab to tab backwards  through the fields.
>How should that be done?  Forge a mouseDown event inside the appropriate
>editable text field?
if your filter proc sees <Shift>Tab, it just does a SelIText() of the
appropriate field, and changes the "what" of the event record to
nullEvent, so the dialog manager will do no more with it. It ususally
group all the EditText items in a dialog as one contiguous group of items.
Since I sometimes gray out editable text items, I don't make the
<shift>Tab function completely automatic: I have a generic filterproc that
is called with extra arguments from each specific dialog's filterproc, so
I can customize the behavior of the filterproc while reusing as much code
as possible.

>My filterProc is being called from a dialog box that is invoked from a
>desk accessory, so I can't use globals in the usual way (I have a Handle
>that holds all of the global data, & pass that from routine to routine).
>Any suggestions on how I might pass this handle into the filterProc?

There are two issues here, since there are two kinds of "global" data. One
is true globals, the other is per-window globals. (A dialog might start a
second dialog, for example, an error message dialog. Since you have two
dialogs on the screen, you can't depend on a single set of filterproc
variables.)  Use SetWRefCon(theDialog, (long) winVarHandle) to stash the
gloabls handle, and GetWRefCon(theDialog) to retrieve it. That is what the
refCon is for.  I would make a field in my window variables be a reference
to my application globals.

>How do you determine if the user is clicking in a scrollbar?  Use a custom
>filterProc for each dialog that 'knows' (via hard-coding) which items have
>scrollbars?

Well scrollbars are userItems. You detect clicks on an item by calling
FindDItem() (I.M.V4). If your porgram maintains 64K ROM compatibility,
you'll need to write your own version of this routine, but it si simple.
My filterproc needs to call this so it can track the cursor to handle
changing it to an iBeam as appropriate.  i don't try to write one
completely general filterProc, instead, I write a simple, single, short
one for each dialog, that calls MyGenericFilterProc() to do most of the
work.

Does MacApp miss any of the subtle user interface points I catch? What
does it do along these lines that I don't? 
THINK C Class Library doesn't seem to have much filterproc support, or am
I missing something there?

> The mac is a detour in the inevitable march of mediocre computers.
> drs@bnlux0.bnl.gov (David R. Stampf)
--- David Phillip Oster          -master of the ad hoc odd hack. 
Arpa: oster@dewey.soe.berkeley.edu 
Uucp: {uwvax,decvax}!ucbvax!oster%dewey.soe.berkeley.edu