Move through records with self made buttons only

[Sietske]

I'm currently busy with the following:

I have made the navigation buttons on my forms invisible, and added my own
buttons on the form instead. Future users (without any knowledge of access)
can scroll between forms with these buttons.

The problem I'm facing now:

I can still navigate between records without using my buttons, using the
scroll wheel on the mouse, as well as the tab-button on my keyboard. This can
be distracting for future users of the form.

My question:

How do I make sure that navigating between records is ONLY possible using my
self made buttons?

 

[Douglas J. Steele]

Assuming you're talking Access 2003 or earlier, see what Stephen Lebans has
at http://www.lebans.com/mousewheelonoff.htm

 

[Sietske]

Hi Doug,

I already found that code before I asked my question, but I hoped there was
another way to exclude all possible ways of moving through records, instead
of just excluding one way. Nevertheless: thanks for trying to help me out!


By the way: Your answer raised another question. If I implement the
mousewheeloff-code, and people will use my database on a computer with the
latest Access software: what will happen then? And in case it's unwanted:
what do I have to do about that?

Thanks in advance!
Sietske

 

[Linq Adams via AccessMonster.com]

"but I hoped there was another way to exclude all possible ways of moving
through records,"

What other "possible ways" are you talking about? You said you've removed the
native Access navigation buttons. The only other method I'm aware of is by
coming to the end of controls on one record and hittting <Enter>depending on
how your form is set up. If this is a problem, from inside Form Design View,
goto Properties - Other and change the Cycle Property from All Records to
Current Record.

"If I implement the mousewheeloff-code, and people will use my database on a
computer with the latest Access software: what will happen then? "

There are literally thousands and thousands of apps out there using Lebans
mousewheel hack, and I've not seen a single post documenting a problem with
this.The bottom line is, if you want to prevent this behavior, you really
have to use Lebans code. I've seen a bunch of people try to develop their own
workaround without success.

Good Luck!

Linq

--
There's ALWAYS more than one way to skin a cat!

Answers/posts based on Access 2000/2003

Message posted via AccessMonster.com

 

[Dale Fye]

In addition to the MouseWheel code, you should change the forms Cycle
property (Other tab) to Current Record. This will prevent the user from
being able to navigate to the next record using the Tab or Enter key when
they are on the last control on a form.

There is another way to accomplish this, but it involves a lot more coding.
Rather than having your form bound to your entire recordset, you could have
it bound to a query that only returns a single record at a time. To do this,
you declare a recordset that is private within your entire form. You
populate this recordset in the forms Open Event with a SQL string that looks
something like:

SELECT [PKField] FROM yourTable ORDER BY [SomeSortField]

Now, you use this recordset to determine which record you are on, and
control the appearance of your navigation controls. When the user clicks a
navigation control, you move withing this recordset, and use the PK value to
populate hidden control on the form. Then, immediately after populating that
control, you requery your form.

It is a little more complicated, but it also returns a much smaller
recordset and in my experience is just as reliable.

HTH
Dale

 

[Rick Brandt]

"but I hoped there was another way to exclude all possible ways of
moving through records,"

What other "possible ways" are you talking about? You said you've
removed the native Access navigation buttons. The only other method
I'm aware of is by coming to the end of controls on one record and
hittting <Enter>depending on how your form is set up. [snip]

All of these can take you to a different record...

PageUp
PageDown
Apply a filter
Remove a filter
Apply a sort order
Remove a sort order
The Edit - go to record menu item
(probably others)

....which makes total customized control over the navigation on a bound form
fairly complicated to pull off.

The easiest way to achieve that in my opinion is to present the user with a form
that is bound to a data source containing exactly one record. Then a custom
method for displaying exacly one *different* record can be provided and in some
cases this can be made to simulate navigating fairly closely.

What I have done on a few occassions was to have a subform containing navigation
buttons. In its Open event I open a RecordSet that contains just the primary
key field of the table being used by the parent form. The buttons on the
subform run code in their click event to change to a new PK value and then
change the data source of the parent form to display the one record matching the
new PK value. Since the parent form is bound to a record source containing only
one record there is no built in way to navigate anywhere else (particularly if
AllowAdditions is disabled).

The subform can have transparent borders and can also include the typical
"Record x of y" information so to the user the form behaves just as if it were
bound to a multi-record data source.