Design Dilemma - ContinuousForms and Buttons.

[ApexData]

In my database, I uniformly handle records on a Record by Record basis,
in a single form that contains New/Edit/Del buttons. Because I'm
dealing with records one at a time, I can easily manage my button
operations. The user enters the system in ViewOnlyMode, if EditButton
is pressed, the fields turn yellow, and Me.AllowEdits becomes true, and
the user edits. This is followed by a Save/Undo/Quit button, that does
the obvious, and the user is returned to ViewMode.
I also have security built into the system and turn buttons On or OFF
based on user rights.

Now, a few future forms need to be built as Continuous Forms, and will
desirably arrange multiple records on the screen. In order to maintain
the continuity and "feel" of my system, I need to use buttons. This
presents a problem because the buttons typically manage Individual
Records, and the continuous record concept becomes a nightmare to
manage MultipleRecords with my traditional buttons.

Any design suggestions for managing Continuous Forms, that would fit in
logically with my original design button concept would be greatly
appreciated. Also, any design sample or example links would also be
helpful. This project is 50% complete.

ThankYou
Greg

[Allen Browne]

Place your buttons in the Form Footer section.

Even with a Continuous Form, there is a current record. If you choose to
show the record selector, it points to the current record. Your buttons will
be enabled/disabled or whatever based on the values in the current record.

--
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.

<Ap******@gmail.comwrote in message
news:11**********************@a3g2000cwd.googlegro ups.com...

In my database, I uniformly handle records on a Record by Record basis,
in a single form that contains New/Edit/Del buttons. Because I'm
dealing with records one at a time, I can easily manage my button
operations. The user enters the system in ViewOnlyMode, if EditButton
is pressed, the fields turn yellow, and Me.AllowEdits becomes true, and
the user edits. This is followed by a Save/Undo/Quit button, that does
the obvious, and the user is returned to ViewMode.
I also have security built into the system and turn buttons On or OFF
based on user rights.

Now, a few future forms need to be built as Continuous Forms, and will
desirably arrange multiple records on the screen. In order to maintain
the continuity and "feel" of my system, I need to use buttons. This
presents a problem because the buttons typically manage Individual
Records, and the continuous record concept becomes a nightmare to
manage MultipleRecords with my traditional buttons.

Any design suggestions for managing Continuous Forms, that would fit in
logically with my original design button concept would be greatly
appreciated. Also, any design sample or example links would also be
helpful. This project is 50% complete.

ThankYou
Greg

[Rick Brandt]

Ap******@gmail.com wrote:

In my database, I uniformly handle records on a Record by Record
basis, in a single form that contains New/Edit/Del buttons. Because
I'm dealing with records one at a time, I can easily manage my button
operations. The user enters the system in ViewOnlyMode, if EditButton
is pressed, the fields turn yellow, and Me.AllowEdits becomes true,
and the user edits. This is followed by a Save/Undo/Quit button,
that does the obvious, and the user is returned to ViewMode.
I also have security built into the system and turn buttons On or OFF
based on user rights.

Now, a few future forms need to be built as Continuous Forms, and will
desirably arrange multiple records on the screen. In order to
maintain the continuity and "feel" of my system, I need to use
buttons. This presents a problem because the buttons typically
manage Individual Records, and the continuous record concept becomes
a nightmare to manage MultipleRecords with my traditional buttons.

Any design suggestions for managing Continuous Forms, that would fit
in logically with my original design button concept would be greatly
appreciated. Also, any design sample or example links would also be
helpful. This project is 50% complete.

Based on how your other forms work I would make the continuous form read
only and have an [Edit] button per record. Pressing that would open a
dialog form that allowed editing that one record. That form could have your
Save/Undo/Quit buttons on it.

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com

[Marshall Barton]

Ap******@gmail.com wrote:

>In my database, I uniformly handle records on a Record by Record basis,
in a single form that contains New/Edit/Del buttons. Because I'm
dealing with records one at a time, I can easily manage my button
operations. The user enters the system in ViewOnlyMode, if EditButton
is pressed, the fields turn yellow, and Me.AllowEdits becomes true, and
the user edits. This is followed by a Save/Undo/Quit button, that does
the obvious, and the user is returned to ViewMode.
I also have security built into the system and turn buttons On or OFF
based on user rights.

Now, a few future forms need to be built as Continuous Forms, and will
desirably arrange multiple records on the screen. In order to maintain
the continuity and "feel" of my system, I need to use buttons. This
presents a problem because the buttons typically manage Individual
Records, and the continuous record concept becomes a nightmare to
manage MultipleRecords with my traditional buttons.

Any design suggestions for managing Continuous Forms, that would fit in
logically with my original design button concept would be greatly
appreciated. Also, any design sample or example links would also be
helpful. This project is 50% complete.

I prefer to put the record operation buttons in the form
footer section.

To emphasize which record will be operated on, I use a
locked and disabled text box sized to fill the detail
section. Conditional Formatting is then used to set the
text box's BackColor.

--
Marsh

[ApexData]

I attempted to go the way Allen advised, but was frustrated because the
user could easily click on any record, and lose their way. I normally
set the field color to yellow, and had difficulty changing a single
record to yellow and keeping the user on that record. The whole concept
seemed to result in a confusing user interface.

I am now thinkin about a popup form to manage a single record with my
standard buttons.
Or, as Rick suggested with an edit box next to each record. How would
I put a button next to each record [Edit] [Del] ??? What about [New]
where would that go???

I don't understand Marshall's suggestion. Putting the buttons on
the bottom, and selecting a record and emphasizing the record to be
operated on is a good idea, but then what??? Back to the problem that
I was having with my original attempts.

Also, any design WebLinks (samples or examples) to feel it out???

[Ron2006]

Here are some other ideas to throw in the pot.

Have the allow edits on the subform as false.
click on the edit button (on bottom or top of main form) and use a
popup with a record source that only has the record you are physically
sitting on in the continuous form. Have your save etc buttons on that
popup form.

have an add button that either makes the subform an add-record form or
go to that previous popup with the add option set on the call.

OR

create a psuedo datasheet form (called "continuous form") - have all
the fields a set width but right next to each other. - then you can add
buttons.... difficulty is that they cannot change width of fields, nor,
I believe, sort the subform.

Ron

[Ron2006]

Continous forms can have buttons.... datasheet forms cannot.

Ron

[Jason Lepack]

Most of our applications that we use here are ASP.Net applications,
however, when the Developers are busy we typically design Access
databases and place them on the network. However, since they're
eventually going to go to ASP I design the forms to look like they
would on the web. I use continuous forms and on each line I have a
button that says "Edit". In that button I open the form and the link
criteria is the id from that record on the continuous form.

Cheers,
Jason Lepack

Ap******@gmail.com wrote:

I attempted to go the way Allen advised, but was frustrated because the
user could easily click on any record, and lose their way. I normally
set the field color to yellow, and had difficulty changing a single
record to yellow and keeping the user on that record. The whole concept
seemed to result in a confusing user interface.

I am now thinkin about a popup form to manage a single record with my
standard buttons.
Or, as Rick suggested with an edit box next to each record. How would
I put a button next to each record [Edit] [Del] ??? What about [New]
where would that go???

I don't understand Marshall's suggestion. Putting the buttons on
the bottom, and selecting a record and emphasizing the record to be
operated on is a good idea, but then what??? Back to the problem that
I was having with my original attempts.

Also, any design WebLinks (samples or examples) to feel it out???

[Marshall Barton]

Ap******@gmail.com wrote:

>I don't understand Marshall's suggestion. Putting the buttons on
the bottom, and selecting a record and emphasizing the record to be
operated on is a good idea, but then what???

You would use your buttons to unlock, etc. so users can edit
the highlighted record. The form's BeforeUpate event can
check if the "save" button initiated the action and cancel
the update if not.

I just don't see a need for a popup, unless the continuous
form is not displaying all the editable values. If you do
require a separate form, I would consider using a subform
positioned over the highlighted record as sort of a "zoom
box".

--
Marsh

[Darryl Kerkeslager]

This example may be of use. I use row highlighting on the continuous form
to indicate the current record. The 'buttons' on the continuous form are
hidden, and simply move the record on the main form.

http://www.kerkeslager.net/Darryl/Ac...Highlight.html

--
Darryl Kerkeslager
<Ap******@gmail.comwrote

I attempted to go the way Allen advised, but was frustrated because the
user could easily click on any record, and lose their way. I normally
set the field color to yellow, and had difficulty changing a single
record to yellow and keeping the user on that record.

[Lyle Fairfield]

Ap******@gmail.com wrote:

In my database, I uniformly handle records on a Record by Record basis,
in a single form that contains New/Edit/Del buttons. Because I'm
dealing with records one at a time, I can easily manage my button
operations. The user enters the system in ViewOnlyMode, if EditButton
is pressed, the fields turn yellow, and Me.AllowEdits becomes true, and
the user edits. This is followed by a Save/Undo/Quit button, that does
the obvious, and the user is returned to ViewMode.
I also have security built into the system and turn buttons On or OFF
based on user rights.

Now, a few future forms need to be built as Continuous Forms, and will
desirably arrange multiple records on the screen. In order to maintain
the continuity and "feel" of my system, I need to use buttons. This
presents a problem because the buttons typically manage Individual
Records, and the continuous record concept becomes a nightmare to
manage MultipleRecords with my traditional buttons.

Any design suggestions for managing Continuous Forms, that would fit in
logically with my original design button concept would be greatly
appreciated. Also, any design sample or example links would also be
helpful. This project is 50% complete.

ThankYou
Greg

Thanks for the post. It and the other posts in the thread help me
understand why real programmers laugh at Access developers. As Access
provides a complete and never erring intuitive interface for record
navigation, what could be the possible rationale for wasting time,
effort and by extension, money on designing one's own?
This thread is ludicrous!

[Larry Linson]

"Lyle Fairfield" <ly***********@aim.comwrote

Thanks for the post. It and the other posts in the
thread help me understand why real programmers
laugh at Access developers. As Access provides a
complete and never erring intuitive interface for
record navigation, what could be the possible
rationale for wasting time, effort and by extension,
money on designing one's own?
This thread is ludicrous!

I think one of the most difficult things for many people to do is to realize
that when they move on to something new, that is isn't likely to be, nor
supposed to be "just the same as whatever they used to use." Some people do
go to great lengths to force the new something to match the old something,
just because that's what they are used to.

"Typical" or even "sad" may be even a better description than "ludicrous."

Larry

[David W. Fenton]

"Ap******@gmail.com" <Ap******@gmail.comwrote in
news:11**********************@a3g2000cwd.googlegro ups.com:

Now, a few future forms need to be built as Continuous Forms, and
will desirably arrange multiple records on the screen. In order
to maintain the continuity and "feel" of my system, I need to use
buttons. This presents a problem because the buttons typically
manage Individual Records, and the continuous record concept
becomes a nightmare to manage MultipleRecords with my traditional
buttons.

I never allow editing of records in continuous forms except in the
most limited circumstances (such as invoice items). The way I do it
is use the continuous form as a fancy listbox and populate a detail
subform based on the selected record. This might be doable with a
single form, putting the editable controls in the form header or
footer. The list is then used only to navigate and choose which
record you want to edit.

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

[ApexData]

Thankyou all for your responses. Larry & Lyle are probably on target
with their remarks, but since this is only my second development
project with Access, I have admittedly resorted to my old style of
development. I am learning, and am thankful for the advice, and may
someday adhere to the "intuitive" Access interface when I get
better. I have coded security issues that I need to address using the
Button (Visible/ NotVisible) concept and wasn't able to readily adapt
the "intuitive" interface to this portion of the project. Also, the
user's desire for New/Edit/Del buttons had to resemble another app
they have.

Back at the ranch, I have been working with the suggestion that
Marshall offered earlier and David just offered:

David W. Fenton

>I never allow editing of records in continuous forms except in the
most limited circumstances (such as invoice items). The way I do it
is use the continuous form as a fancy listbox and populate a detail
subform based on the selected record. This might be doable with a
single form, putting the editable controls in the form header or
footer. The list is then used only to navigate and choose which
record you want to edit.

I set a single continuous form to read only and am working to setup a
highlight bar to Emphasize the record in focus. I took a copy of the
fields from the Detail section and placed them above in the Header
along with the Add/Edit/Del buttons. These fields have the Visible =
False as default. The user can scroll thru the continuous form, point
to a select record, Press the Edit button, and then the Header fields
become visible, with a yellow background. A clone of the record in the
continuous form, is now ready to be edited. This fits my need and
seems to work as needed.

This is a good thread of concepts. And will surely benefit future
searchmen!

ThankYouAll

Greg

[ApexData]

Sorry I missed your post Darryl!
Your link, displays my choice to the T.

Thanks
Greg