Blocking users from changing records

[John S. Ford, MD]

I've written an application in Access 97 and have been trying to bulletproof
it. Part of an entry form has users entering information and I don't want
him to be able to change records in mid-entry.

I've taken some precautions to prevent this including coding my own
navigation buttons (and disabling them at appropriate times) and writing a
keyboard manager to prevent users from using short-cut keys to navigate.
(Changing records in mid-entry could be disastrous).

Despite this, my 2-year-old was doing some impromptu beta-testing and she
discovered that one could navigate through records using the mousewheel.

Any ideas on how to programmatically disable record navigation with the
mousewheel? If possible, I'd like to only selectively disable it at certain
times and re-enable it during non-data-entry procedures but either would be
acceptable.

John

 

[Ken Snell [MVP]]

See Stephen Lebans' website www.lebans.com

He has a MouseWheelHook.zip program that will do just what you seek.

 

[PC Datasheet]

You can do everything you are doing much simpler!

In the form's BeforeUpdate event, check all the controls to be sure they all
contain data. If not, set Cancel = True and the user will not be able to
save the partially filled record.

 

[Albert D. Kallal]

You got some good comments here already.

My solution is rather simple:

All my forms have allow additions set to no

All my forms have the cycle property set to current record.

All my main edit forms have NO navigation buttons

All my main forms are launched by a "prompt" form that is used to allows the
user to search and find the record. So, these search forms comes BEFORE the
main form. When the search results are displayed, then the user can then
click on the desired record (the "hit" list displayed in the search form),
and the launch the main edit form. Since that main edit form has only ONE
record, then mouse wheel, etc is of no consequence, since no navigation is
possible.

And, note that if a forms allow additions is set to "no", then you can
launch the form with ONE NEW record as follows:

docmd.OpenForm "frmCustomer",,,,acFormAdd

Thus, the above command actually overrides the "allow additions" setting,
but only for ONE record. (this, I don't have a bunch of code to deal with
allow additions etc.).

Further, most users are vary lazy..and tend to open up a forms and start
adding...without FIRST SEARCHING for existing records. A good design will
"encourage" users to FIRST search for a record...and THEN if they don't find
the record..they can whack the add new record button. So, having a searching
for presented BEFORE the main edit form encourages users to search for
existing records..and THEN if not found..a add button can be hit.

So, we get a friendly UI, don't have to code a bunch of stuff for
"accidental" additions, and don't have to worry about mouse wheel etc, since
all records are bound to ONE record. About the only disadvanges here is that
you can't add more then one record after another, but have to "close" the
main form. On the other hand, users tend to like the concept of "closure.
You ad the record..you close the form (and the data is saved). The user is
done ONE task..and feels good. Further, since the form is closed, then the
data is saved, then if the computer freezes up etc, the record is saved. (I
have clients running for years...and NOT ONE corruption has occlude. I don't
know if my doings of search->edit->close is response for this lack of
corruptions...but it seems too. Anyway, once a user has "finished" with the
one customer, then the user can go for coffee, or start the next "cycle" to
find a customer...or add a customer. As mentioned, 99% of applications
requite that the user FIRST search for an existing customer.

I have some screen shots of this "cycle" in process here:

http://www.attcanada.net/~kallal.msn/Search/index.html

 

[John S. Ford, MD]

Dear Ken,

I'm not a "Windows" guy but I tried that program. I copied the dll file and
placed it in the same folder as my application program. I created a new
module and cut and pasted Stephen Leban's code into it. I then added the
MouseWheelOff and MouseWheelOn code to the form's OnOpen event and OnClose
events as described.

Well I have NO idea how it works but it seems to do the trick. Is there
anything else I need to know about this code? Will it cause problems
elsewhere in my program?

John

 

[Ken Snell [MVP]]

Not to my knowledge. I currently use Stephen's dll setup in a commercialized
database with great success.

--

Ken Snell
<MS ACCESS MVP>

Dear Ken,

I'm not a "Windows" guy but I tried that program. I copied the dll file and
placed it in the same folder as my application program. I created a new
module and cut and pasted Stephen Leban's code into it. I then added the
MouseWheelOff and MouseWheelOn code to the form's OnOpen event and OnClose
events as described.

Well I have NO idea how it works but it seems to do the trick. Is there
anything else I need to know about this code? Will it cause problems
elsewhere in my program?

John

 

[John S. Ford, MD]

Great,

That's all I need to know!

John

 

[Guest]

searching for 'disable mouse wheel' in this forum yields several 'hits'
referencing lebans' code which i too have tried. before implementing it 'for
real', i copied the sample northwind.mdb file into a new folder along with
lebans' mdb file and accompanying dll file i downloaded from his website. to
make a long story short, although i've gotten it to work w/o very much effort
on my part, it does not seem to work in the 'categories' subform for some
reason although it DOES work on the 'categories' main form. so, does this
mean that it will not disable (what i call a nested) subform w/in a main form

 

[Stephen Lebans]

Ted a couple of things:

1) Take a moment to read the Posting FAQ here:
http://www.mvps.org/access/netiquette.htm
Your current post is within an existing thread over a month old.

2) Please do not EMail me directly with questions. As my SIG line states
"Please respond only to the Newsgroups so everyone can benefit".

3). The MouseHook solution purposely allows Subforms to continue to be
scrolled via the MouseWheel. This was the behaviour requested by the
majority of early users of the MouseHook. I will add the capability to
turn off the MouseWheel for Subforms in the next release.

--

HTH
Stephen Lebans
http://www.lebans.com
Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.

 

[Guest]

stephen,

1st of all, i'd just like to say that i wasn't aware of the deadline factor
in your mention.

2nd and lastly, a big thanks for taking time to clarify the fact that a) it
ain't broken and b) it'll get better soon (do you have a projected d.o.r)

best wishes,

ted