Combo box, command button placement questions

[Kevin]

A couple of easy questions here hopefully. I've been working on two
different database projects which make use of multiple
forms.

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?

2. If in the footer, how do you add them to the tab order?

3. I open all forms with allow{additions,deletions,edits} turned off. I
want to be able to add a combo box to one form which will allow the user
to select a record from the combo box. I've added the combo box with no
problem, but the user can only select a record if allowedits is on. Is
there a way to allow this, yet still retain data protection by not
allowing edits?

Thanks,

Kevin

[Allen Browne]

Answers in-line.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"Kevin" <wi******@hotmail.com> wrote in message
news:pa***************************@hotmail.com...

A couple of easy questions here hopefully. I've been working on two
different database projects which make use of multiple
forms.

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.

A command button on the form for Cancel is very frustrating. The events of
the control where the user is making an entry fire before Access moves the
focus to the command button and its events fire. That means the Cancel
button cannot solve problems such as:
- a partial date e.g. 1/12/
- a value that was backspaced out in a required field.
- a combo value that is not in the list
and so on. In general, a Cancel button on the form causes more problems that
it solves.

A Save button on the form is superfluous. Access saves automatically, and
you don't want to slow users down by having them click a superfluous button
every record.

A Delete button has the same problems as an Undo.

An Lock/Unlock button does make sense if the record is locked for editing.

If you choose to use command buttons anyway, it is a question of style what
section you place them in.
2. If in the footer, how do you add them to the tab order?
Place a small unbound text box in the Detail section of the form, as the
last one in the tab order. In its GotFocus event, SetFocus to the first
command button in the Form Footer section.
3. I open all forms with allow{additions,deletions,edits} turned off. I
want to be able to add a combo box to one form which will allow the user
to select a record from the combo box. I've added the combo box with no
problem, but the user can only select a record if allowedits is on. Is
there a way to allow this, yet still retain data protection by not
allowing edits?

That's right. If the form's AllowEdits is set to No, even the unbound
contorls are unusable. To avoid this, you need to set the Locked property of
each bound controls instead of the AllowEdits of the form.

To do that check out this article:
Locking bound controls on a form and subforms
at:
http://allenbrowne.com/ser-56.html
The article contains code that loops through all bound controls on the form,
and toggles their Locked property. If it finds a subform on the form, the
code calls itself recursively, so that subforms are also locked/unlocked to
any depth. If there is a control you do not want to unlock, you can name it
in the exception list. (If you don't want to lock subforms, that means you
can name them in the exception list.)

BTW, if you set AllowAdditions to No, you get another problem. If the form
is filtered so that it has no records, the Detail section goes completely
blank, and even the unbound contorls in the Form Header or Form Footer are
likely to play up as described here:
http://allenbrowne.com/bug-06.html
To avoid that issue, you might like to leave AllowAdditions as Yes, but
cancel the form's BeforeInsert event if the user tries to add a record while
the form is not in your edit state.

[Kevin]

On Sat, 14 Jan 2006 12:52:57 +0800, Allen Browne wrote:

Answers in-line.

"Kevin" <wi******@hotmail.com> wrote in message
news:pa***************************@hotmail.com...

A couple of easy questions here hopefully. I've been working on two
different database projects which make use of multiple
forms.

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.

Heh, I agree. However for novice users I could see this becoming a
problem. If there's not a big "go" button, they tend to get lost. ;)

A command button on the form for Cancel is very frustrating. The events
of the control where the user is making an entry fire before Access
moves the focus to the command button and its events fire. That means
the Cancel button cannot solve problems such as: - a partial date e.g.
1/12/
- a value that was backspaced out in a required field. - a combo value
that is not in the list and so on. In general, a Cancel button on the
form causes more problems that it solves.
Good information, thanks.

A Save button on the form is superfluous. Access saves automatically,
and you don't want to slow users down by having them click a superfluous
button every record.

True, my save buttons are usually a coded method to Allow{Edits,
Deletions, Additions}. They don't really "save", but rather lock
everything back up and present the user with other options.
A Delete button has the same problems as an Undo.

An Lock/Unlock button does make sense if the record is locked for
editing.

Again, that's really what my buttons do. The delete button enabled
edits/deletions, calls EditMenu 8 and 6, and then locks things back up.

If you choose to use command buttons anyway, it is a question of style
what section you place them in.

2. If in the footer, how do you add them to the tab order?
Place a small unbound text box in the Detail section of the form, as the
last one in the tab order. In its GotFocus event, SetFocus to the first
command button in the Form Footer section.

Nice solution!

3. I open all forms with allow{additions,deletions,edits} turned off. I
want to be able to add a combo box to one form which will allow the
user to select a record from the combo box. I've added the combo box
with no problem, but the user can only select a record if allowedits is
on. Is there a way to allow this, yet still retain data protection by
not allowing edits?

That's right. If the form's AllowEdits is set to No, even the unbound
contorls are unusable. To avoid this, you need to set the Locked
property of each bound controls instead of the AllowEdits of the form.

That's what I was experimenting with today. But that causes other
problems like re-assigning the current record with whatever you select in
the combo box. :\
To do that check out this article:
Locking bound controls on a form and subforms
at:
http://allenbrowne.com/ser-56.html
The article contains code that loops through all bound controls on the
form, and toggles their Locked property. If it finds a subform on the
form, the code calls itself recursively, so that subforms are also
locked/unlocked to any depth. If there is a control you do not want to
unlock, you can name it in the exception list. (If you don't want to
lock subforms, that means you can name them in the exception list.)

BTW, if you set AllowAdditions to No, you get another problem. If the
form is filtered so that it has no records, the Detail section goes
completely blank, and even the unbound contorls in the Form Header or
Form Footer are likely to play up as described here:
http://allenbrowne.com/bug-06.html
To avoid that issue, you might like to leave AllowAdditions as Yes, but
cancel the form's BeforeInsert event if the user tries to add a record
while the form is not in your edit state.

Thanks for the link, I'll check out the pages!

Aloha,

Kevin

[Allen Browne]

Hey, I did assume this was an unbound combo, purely for the purpose of
selecting the record to navigate to.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"Kevin" <wi******@hotmail.com> wrote in message
news:pa****************************@hotmail.com...

... If the form's AllowEdits is set to No, even the unbound
contorls are unusable. To avoid this, you need to set the Locked
property of each bound controls instead of the AllowEdits of the form.

That's what I was experimenting with today. But that causes other
problems like re-assigning the current record with whatever you select in
the combo box. :\

[Kevin]

On Sat, 14 Jan 2006 17:33:45 +0800, Allen Browne wrote:

Hey, I did assume this was an unbound combo, purely for the purpose of
selecting the record to navigate to.

Well, it has to be set to the particular field value, so are you saying
use a query instead of binding it to a table value? Or how else would I
have it unbound?

[Rick Brandt]

Kevin wrote:

On Sat, 14 Jan 2006 17:33:45 +0800, Allen Browne wrote:

Hey, I did assume this was an unbound combo, purely for the purpose
of selecting the record to navigate to.

Well, it has to be set to the particular field value, so are you
saying use a query instead of binding it to a table value? Or how
else would I have it unbound?

ComboBoxes are typically used either as a means to enter data in a field (bound)
or to navigate to a record (unbound). You can't use one to do both things at
the same time.

When you open the form to Record one and a bound ComboBox has a particular value
in it then changing the ComboBox selection is altering the first record. If
your intended use was to move to another record then this would obviously be
incorrect.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[David W. Fenton]

"Allen Browne" <Al*********@SeeSig.Invalid> wrote in
news:43***********************@per-qv1-newsreader-01.iinet.net.au:

"Kevin" <wi******@hotmail.com> wrote in message
news:pa***************************@hotmail.com...

A couple of easy questions here hopefully. I've been working on
two
different database projects which make use of multiple
forms.

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.

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.

Secondly, all Windows dialogs have a Cancel button *on* the form.

Puttin it anywhere else will be confusing. Personally, I can't think
of a single instance of a CANCEL button in a toolbar. Well,
actually, I can think of one, and the reason I remember it is
because it'annoys the hell out of me every time I encounter it, and
that's in the PRINT PREVIEW in MS Office programs. Fortunately, the
ESCAPE key is mapped to it, so I just hit ESCAPE.
A command button on the form for Cancel is very frustrating. The
events of the control where the user is making an entry fire
before Access moves the focus to the command button and its events
fire. That means the Cancel button cannot solve problems such as:
- a partial date e.g. 1/12/
- a value that was backspaced out in a required field.
- a combo value that is not in the list
and so on. In general, a Cancel button on the form causes more
problems that it solves.
These problems would easily solved with a flag that the events of
those controls could check before executing their code. This flag
would be set in the Cancel buttons OnClick event.

However, let me note: I've never done it, and I have never even once
put a cancel button on a toolbar, but always on forms.

And I've never encountered any such problems.

Ever.

In 10 years of full-time Access programming.
A Save button on the form is superfluous. Access saves
automatically, and you don't want to slow users down by having
them click a superfluous button every record.
Many things in user interface design are, strictly speaking,
superfluous in that they duplicate functionality found elsewhere.

A SAVE button is clear and easy to see and tells the user how to
save a record, which they won't know if they haven't studied the
Access documentation. It gives them security to know that the record
is saved, even if that is only a psychological issue. We are dealing
with people here, so their comfort levels with their applications is
relevant to providing a satisfactory user experience.
A Delete button has the same problems as an Undo.
What would those problems be?
An Lock/Unlock button does make sense if the record is locked for
editing.

If you choose to use command buttons anyway, it is a question of
style what section you place them in.
With all due respect, I think your advice is completely ridiculous.
I've never seen apps of any kind, Access or not, built the way you
recommend. You are calling for creating apps that depart from the
conventions of all the apps I can think of, which would likely lead
to user dissatisfaction, and make the apps harder to learn (though
only in the first few hours of use).

The problems that you adduce are actually quite easily solved (at
least the ones you chose to explain), so I really don't see any
justification at all to use such a user-unfriendly interface design.

2. If in the footer, how do you add them to the tab order?

Place a small unbound text box in the Detail section of the form,
as the last one in the tab order. In its GotFocus event, SetFocus
to the first command button in the Form Footer section.

Or, don't use footers.

The only reason to use footers is if you have a multipage form (a
footer keeps its contents in the same location regardless of which
page you are on), and since Access started incorporating a tab
control (in A97) there is no longer any justification for a
multipage form, in my opinion. Multipage forms are user-unfriendly
because the vertical location of controls becomes random. Location
of controls should always be constant, never shifting around, and
there is no way to do that in a multipage form without a massive
amount of extra coding.

So, the way to avoid the problem of independent tab order in footers
is to simply not use footers, unless an independent tab order for
some controls would be useful.

3. I open all forms with allow{additions,deletions,edits} turned
off. I want to be able to add a combo box to one form which will
allow the user to select a record from the combo box. I've added
the combo box with no problem, but the user can only select a
record if allowedits is on. Is there a way to allow this, yet
still retain data protection by not allowing edits?

That's right. If the form's AllowEdits is set to No, even the
unbound contorls are unusable. To avoid this, you need to set the
Locked property of each bound controls instead of the AllowEdits
of the form.

To do that check out this article:
Locking bound controls on a form and subforms
at:
http://allenbrowne.com/ser-56.html

I think this code would be made much more efficient if you used a
custom collection for locking/unlocking the controls. If you are
locking/unlocking the form repeatedly, the performance improvment
with a custom collection is actually quite noticeable to the user. I
was surprisde at this, myself, but found it to be quite true even on
forms that didn't have 100+ controls.
The article contains code that loops through all bound controls on
the form, and toggles their Locked property. If it finds a subform
on the form, the code calls itself recursively, so that subforms
are also locked/unlocked to any depth. . . .
Why would you not just disable the subform control and be don with
it?
. . . If there is a control you do not want to unlock, you can
name it in the exception list. (If you don't want to lock
subforms, that means you can name them in the exception list.)
I use Tag properties to indicate how I want controls to be handled
in this type of initialize routines.
BTW, if you set AllowAdditions to No, you get another problem. If
the form is filtered so that it has no records, the Detail section
goes completely blank, and even the unbound contorls in the Form
Header or Form Footer are likely to play up as described here:
http://allenbrowne.com/bug-06.html
To avoid that issue, you might like to leave AllowAdditions as
Yes, but cancel the form's BeforeInsert event if the user tries to
add a record while the form is not in your edit state.

I don't quite understand that recommendation. Why doesn't locking
the controls so that they are uneditable make it impossible to add
new records without clicking a command button to do so? If you have
the form navigation set to stay in the same record and trap for the
Page Down key, you could leave AllowAdditions on and not worry about
it.

Second, in your OnCurrent, if Me.NewRecord = True, you'd unlock the
appropriate controls.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[Kevin]

On Sat, 14 Jan 2006 19:38:27 +0000, Rick Brandt wrote:

Kevin wrote:

On Sat, 14 Jan 2006 17:33:45 +0800, Allen Browne wrote:

> Hey, I did assume this was an unbound combo, purely for the purpose of
> selecting the record to navigate to.

Well, it has to be set to the particular field value, so are you saying
use a query instead of binding it to a table value? Or how else would I
have it unbound?

ComboBoxes are typically used either as a means to enter data in a field
(bound) or to navigate to a record (unbound). You can't use one to do
both things at the same time.

OK, maybe I wasn't clear. I don't want to do both, I want to use it to
navigate records. Currently it's bound since I used the form wizard to
select the field. I'll have to do some poking around.

[Allen Browne]

It's dead easy to create another combo for navigation purposes.
Just make sure its Control Source property is No.

Or follow the steps in this article:
Using a Combo Box to Find Records
at:
http://allenbrowne.com/ser-03.html

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"Kevin" <wi******@hotmail.com> wrote in message
news:pa***************************@hotmail.com...

On Sat, 14 Jan 2006 19:38:27 +0000, Rick Brandt wrote:

Kevin wrote:

On Sat, 14 Jan 2006 17:33:45 +0800, Allen Browne wrote:

> Hey, I did assume this was an unbound combo, purely for the purpose of
> selecting the record to navigate to.

Well, it has to be set to the particular field value, so are you saying
use a query instead of binding it to a table value? Or how else would I
have it unbound?

ComboBoxes are typically used either as a means to enter data in a field
(bound) or to navigate to a record (unbound). You can't use one to do
both things at the same time.

OK, maybe I wasn't clear. I don't want to do both, I want to use it to
navigate records. Currently it's bound since I used the form wizard to
select the field. I'll have to do some poking around.

[Allen Browne]

David, as always, the opinion of a seasoned Access developer like yourself
is welcome, and is very helpful for the original poster to get different
opinions, representing different styles.

Responses to the first part of your reply in-line. Hopefully that's enough
to explain the mindset behind the recommendations.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"David W. Fenton" <XX*******@dfenton.com.invalid> wrote in message
news:Xn**********************************@127.0.0. 1...

"Allen Browne" <Al*********@SeeSig.Invalid> wrote in
news:43***********************@per-qv1-newsreader-01.iinet.net.au:

"Kevin" <wi******@hotmail.com> wrote in message
news:pa***************************@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.

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.

If you open bound forms in dialog mode, then your point is valid.
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.

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.
Secondly, all Windows dialogs have a Cancel button *on* the form.

As I develop, a dialog is something completely different than a normal bound
form. You must deal with it before you can go anywhere else. The choices you
are forced to take are therefore appropriately on the form.

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.

[David W. Fenton]

"Allen Browne" <Al*********@SeeSig.Invalid> wrote in
news:43***********************@per-qv1-newsreader-01.iinet.net.au:

"David W. Fenton" <XX*******@dfenton.com.invalid> wrote in message
news:Xn**********************************@127.0.0. 1...

"Allen Browne" <Al*********@SeeSig.Invalid> wrote in
news:43***********************@per-qv1-newsreader-01.iinet.net.au:

"Kevin" <wi******@hotmail.com> wrote in message
news:pa***************************@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.
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.

If you open bound forms in dialog mode, . . .

.. . . which I almost never do. . .
. . . then your point is valid. . . .
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.
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.
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.
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.
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*.

Secondly, all Windows dialogs have a Cancel button *on* the form.

As I develop, a dialog is something completely different than a
normal bound form. . . .

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.
. . . You must deal with it before you can go anywhere else. . . .
That's the definition of a dialog, and what I assumed anyone reading
my post would understand I was talking about.
. .. The choices you
are forced to take are therefore appropriately on the form.
So, this is an exception to your rule, one that you didn't mention.
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.

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/

[Tim Marshall]

David W. Fenton wrote:

I was talking about dialogs. That's what I *said* I was talking
about.

The subject was DIALOGS.

The OP sounds more like he's talking about a bound form, though he
doesn't specifically say.

Allen's points make sense to me in the context of what the user asked.
So do yours about dialogs. So I don't understand the fuss?
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "What's UP, Dittoooooo?" - Ditto

[David W. Fenton]

Tim Marshall <TI****@PurplePandaChasers.Moertherium> wrote in
news:dq**********@coranto.ucs.mun.ca:

David W. Fenton wrote:

I was talking about dialogs. That's what I *said* I was talking
about.

The subject was DIALOGS.

The OP sounds more like he's talking about a bound form, though he
doesn't specifically say.

Allen's points make sense to me in the context of what the user
asked. So do yours about dialogs. So I don't understand the fuss?

Allen didn't say his restrictions were limited to bound data editing
forms.

Even if that were the case, I still strongly disagree with his
recommendations. However, one key point is that I'd never put a
CANCEL button on a data editing form, because it is too nebulous in
what it means.

I have seen very few Access applications created by pros or amateurs
that follow the toolbar-based structure for record operations that
Allen recommends.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[Lyle Fairfield]

I agree with your general position in this thread. My forms almost
never have command buttons. I reserve access forms for data.
I use pop-up short cut menus. Last time I checked these are usable from
popup and/or modal forms.

[Lyle Fairfield]

"Lyle Fairfield" <ly***********@aim.com> wrote in
news:11*********************@g14g2000cwa.googlegro ups.com:

I agree with your general position in this thread. My forms almost
never have command buttons. I reserve access forms for data.
I use pop-up short cut menus. Last time I checked these are usable from
popup and/or modal forms.

Sometimes Google drive me nuts (on days that end with "y"). It's not so
clear in Google's screen organization to whom "your" refers.

so ...

I agree with your (your = Allen Browne's) general position in this thread.

--
Lyle Fairfield