"Allen Browne" <AllenBrowne@SeeSig.Invalid> wrote in
news:43c9c97a$0$23542$5a62ac22@per-qv1-newsreader-01.iinet.net.au:
[color=blue]
> "David W. Fenton" <XXXusenet@dfenton.com.invalid> wrote in message
> news:Xns974B97612ECF5f99a49ed1d0c49c5bbb2@127.0.0. 1...[color=green]
>> "Allen Browne" <AllenBrowne@SeeSig.Invalid> wrote in
>> news:43c883ae$0$24708$5a62ac22@per-qv1-newsreader-01.iinet.net.au:
>>[color=darkred]
>>> "Kevin" <wicket59@hotmail.com> wrote in message
>>> news:pan.2006.01.14.04.37.19.79774@hotmail.com...
>>>>
>>>> 1. Where's the best/recommended placement for command buttons
>>>> for things like delete, save, edit, cancel buttons - in the
>>>> footer, or on the form detail section?
>>>
>>> In the Toolbar.[/color]
>>
>> I strongly disagree with this response in general.
>>
>> Dialog boxes *must* have their command buttons on the form, since
>> the toolbars are not accessible when a form is open with
>> acDialog.[/color]
>
> If you open bound forms in dialog mode, . . .[/color]
.. . . which I almost never do. . .
[color=blue]
> . . . then your point is valid. . . .[/color]
You're saying that an unbound dialog form should not have any
command buttuns on it? Well, that's ridiculous. Every dialog box
you're going to encounter in Windows or any Windows application is
going to have command buttons on it. Creating a dialog in Access
that doesn't conform to that design is going to confuse users and
make it harder for people to learn you application.
[color=blue]
> Personally, I do that only when absolutely necessary. Probably 19
> our to 20 of the forms I create are opened in normal mode, so the
> user can go anywhere, do anything, at any time, in any order. Each
> form's AfterUpdate and AfterDelConfirm events keep any open forms
> up to date. IME, even users who have little computer experience
> love this flexibility, and adapt to it very quickly.[/color]
Well, then those forms are not dialogs.
To step back a moment here, it seems you made a categorical
statement about how things should be done but didn't qualify your
assertions. I disagree even with the qualifications (insofar as I'm
guessing them correctly from your followup here), but for the person
who asked the original question, they seem crucial to me.
For instance, I do not see any difference between bound and unbound
forms in regard to the problems you said a CANCEL button causes. If
you have a BeforUpdate event that you don't want to fire when
cancelling the edit, then it doesn't really matter whether the form
is bound or unbound. That only matters where you have validation
rules in your underyling bound fields, and data entered into them at
the time of the CANCEL is invalid. In that case, assuming you are
depending on the default behavior with field validation failures,
the solution is not to get rid of cancel buttons, but to add a
BeforeUpdate event that you can cancel in the event of clicking the
cancel button.
Now, a point from my side of the discussion;
I'd never put a CANCEL button on a data entry form, because, to me,
it doesn't mean anything! I can't quite figure out what a CANCEL
command button on a bound form should do. Nor on an unbound form.
Clear the form? Close without saving? Undo edits?
I'd much rather have buttons, wherever they are, that clearly
indicate what they do.
[color=blue]
> Essentially it's just an event-driven mindset instead of a
> procedural mindset. I usually have no idea what procedural order a
> user will follow to achieve a result, and often find they take
> creative paths that I never considered. The one thing I do teach
> them is that they can double-click any combo to get at the data
> behind that list, to find, add, edit, or delete the list. Some of
> them launch the target (e.g. to make an invoice) and never bother
> with the switchboard again in that session, using this drill-down
> to go anywhere else they want to go.[/color]
You're saying you have *no* dialogs in your applications? Or no
bound forms that are opened with the acDialog constant? The latter
is *very* different. I am not using the latter to define a dialog --
a dialog is a strictly defined form that collects essential
information for performing a task, and cannot be closed without
supplying all the information relevant to the task being performed,
unless one abandons the task entirely. That's the case where CANCEL
makes perfect sense. It means "oops, I don't wnat to do this after
all -- never mind!"
These kinds of forms *must* be modal as they are part of a sequence
of events that must take place before a task can be performed.
They are most often unbound, but that doesn't mean your controls
won't have BeforeUpdate events for validating data input. Mine
certainly do, and I've yet to encounter a problem with having a
CANCEL button on these forms.
To repeat: these are forms where a user *can't* just go wherever
they want, because they are forms that mimic DIALOG BOXES, which, by
definition, cannot be left until you click OK or CANCEL. And every
dialog box in every Windows application EVER has the command buttons
*in* the dialog box, since by definition, they *must*.
[color=blue][color=green]
>> Secondly, all Windows dialogs have a Cancel button *on* the form.[/color]
>
> As I develop, a dialog is something completely different than a
> normal bound form. . . .[/color]
I was talking about dialogs. That's what I *said* I was talking
about.
The subject was DIALOGS.
Your recommendation of "no command buttons" allowed for no
exceptions.
[color=blue]
> . . . You must deal with it before you can go anywhere else. . . .[/color]
That's the definition of a dialog, and what I assumed anyone reading
my post would understand I was talking about.
[color=blue]
> . .. The choices you
> are forced to take are therefore appropriately on the form.[/color]
So, this is an exception to your rule, one that you didn't mention.
[color=blue]
> What users call a "Cancel" button, is actually an Undo button, and
> Access itself puts one of those on the toolbar, just like the
> other Office applications.[/color]
As I said above, I don't believe in using a CANCEL button on a bound
form. If I'm controlling the saving of data (something I would
rarely do on a bound form, since it's rather difficult), I'd perhaps
supply an UNDO or CLEAR button (or both). But it's something I just
don't do.
But your comments were not limited to CANCEL buttons. You said all
such buttons, including DELETE buttons, belong on the toolbar.
I still strenuously disagree with that.
And since we're creating our own applications, not using Access
itself, the Access defaults are not terribly relevant, unless you're
designing for a user population that regularly uses Access directly.
I have no such users, so they wouldn't know about buttons on
toolbars that perform operations on forms.
The problem here is one that goes back many years and reflects a
fuzziness of thinking in the design of database applications. Our
forms are not really documents (like a Word document), but they
aren't really dialogs, either. So, we have a compromise in the way
we present data, using forms that are something of a hybrid of
document and dialog. This leads to all sorts of problems.
Putting buttons in the toolbar and not on the form treats the form
as a document, putting them on the form treats the form as a dialog.
It's an uneasy compromise, one which leads to inconsistencies, but
one with which users are probably already familiar if they've used
any kind of data-driven application for long.
In general, I want user control over their editing to be as close to
the actual editing area as possible, so I put all command buttons on
the form itself. Indeed, I hardly ever define toolbars because it's
harder to indicate what they do. That is, toolbars us icons, and
icons are too opaque as indicators of what function the icon button
performs. For me, text command buttons are vastly superior, and
placing them on the form makes the application more obvious and
easier to learn.
I believe that most Access developers use this approach.
It's certainly the case that the untrained ones do.
That suggests to me that it's the more user-intuitive place for
command buttons.
--
David W. Fenton
http://www.dfenton.com/
usenet at dfenton dot com
http://www.dfenton.com/DFA/ 
