A
Andrew Gabb
OK, further to my questions earlier, I've done some testing. If you
want a copy of the DB or have anything to suggest, to advance the
problem or the solution, email me. Otherwise this posting may be
useful for others with the same problem. This was done in Access XP
- but I had the same problems in 2k.
The situation is that I'm using a form to display a 'pick list' so
that the user can select an item for further processing. Because
this selection is part of a relatively complex process, I have to
wait for the selection before proceeding. The pick list is sourced
from a table.
In my testing I call the pick list form Form2 from buttons on Form1.
Form2 is modal.
A. Dialog Button
================
For this test, Form2 is called with
DoCmd.OpenForm "Form2", , , , , acDialog
Problems:
Ctrl-F won't bring up Find and Replace dialog.
Normal record navigation keys (PgUp, PgDn, Ctrl-Home) don't work.
B. Modal Button
================
For this test, Form2 is called with
DoCmd.OpenForm "Form2"
but after opening the form, we wait till it closes using
While Not FinF
DoEvents
Wend
(The API Sleep function works no better than DoEvents.)
Problems:
Ctrl-F brings up Find and Replace dialog, but mouse won't work on
dialog (eg can't cancel by clicking Cancel key).
C. Continue Button
==================
For this test, Form2 is called with
DoCmd.OpenForm "Form2"
and there is no waiting.
Problems:
This works OK, but is very nasty to code in my application - see below.
Suggestions and workarounds
===========================
I've had several suggestions on how to solve these problems - thank
you - but as so often happens, they were not full solutions. One
problem I had is that my clients really want standard navigation
keys and all-field searches on these dialogs.
Simulate the Navigation keys
----------------------------
Simple for one or two keys but there are more such keys than you'd
think, simulating the exact functionality is difficult, and I have
several such forms. Not an option for me unfortunately.
Redesign to avoid A/B above
---------------------------
Unfortunately, selecting from these pick lists occurs relatively
deep in a number of complex processes (which if not completed are
aborted). Redesigning them would be a lot of work, and would also
screw up the logic of the design making it difficult to maintain the
app (particularly for error handling). I've done this in other apps,
where possible.
Make your own Find dialog
-------------------------
This is eventually what I did (see below), but both I and my clients
would prefer the standard Access dialog, which has more options.
Again, it's difficult to simulate exactly. It also bloody annoys me
that the standard dialog almost works, but not quite!
Those who suggest that most users don't need all-field searches if
the DB is designed correctly may be right, but not in this case.
There are about 10 fields in some tables where an all-field keyword
search is essential.
Use the datasheet view
----------------------
I'm not sure that this would work anyway, but it's not an option
because I need other buttons in the form header.
What I Did
==========
I eventually used a modal non-dialog form (B above) and put Find and
Find Again buttons in the pick form header which use FindRecord for
all-field searches. A bit messy but not too bad. (The header also
contains keywoard search and sorting controls.)
As I said above, if you have any suggestions please tell me. Also I
can send the test DB if you want to try it.
Andrew
want a copy of the DB or have anything to suggest, to advance the
problem or the solution, email me. Otherwise this posting may be
useful for others with the same problem. This was done in Access XP
- but I had the same problems in 2k.
The situation is that I'm using a form to display a 'pick list' so
that the user can select an item for further processing. Because
this selection is part of a relatively complex process, I have to
wait for the selection before proceeding. The pick list is sourced
from a table.
In my testing I call the pick list form Form2 from buttons on Form1.
Form2 is modal.
A. Dialog Button
================
For this test, Form2 is called with
DoCmd.OpenForm "Form2", , , , , acDialog
Problems:
Ctrl-F won't bring up Find and Replace dialog.
Normal record navigation keys (PgUp, PgDn, Ctrl-Home) don't work.
B. Modal Button
================
For this test, Form2 is called with
DoCmd.OpenForm "Form2"
but after opening the form, we wait till it closes using
While Not FinF
DoEvents
Wend
(The API Sleep function works no better than DoEvents.)
Problems:
Ctrl-F brings up Find and Replace dialog, but mouse won't work on
dialog (eg can't cancel by clicking Cancel key).
C. Continue Button
==================
For this test, Form2 is called with
DoCmd.OpenForm "Form2"
and there is no waiting.
Problems:
This works OK, but is very nasty to code in my application - see below.
Suggestions and workarounds
===========================
I've had several suggestions on how to solve these problems - thank
you - but as so often happens, they were not full solutions. One
problem I had is that my clients really want standard navigation
keys and all-field searches on these dialogs.
Simulate the Navigation keys
----------------------------
Simple for one or two keys but there are more such keys than you'd
think, simulating the exact functionality is difficult, and I have
several such forms. Not an option for me unfortunately.
Redesign to avoid A/B above
---------------------------
Unfortunately, selecting from these pick lists occurs relatively
deep in a number of complex processes (which if not completed are
aborted). Redesigning them would be a lot of work, and would also
screw up the logic of the design making it difficult to maintain the
app (particularly for error handling). I've done this in other apps,
where possible.
Make your own Find dialog
-------------------------
This is eventually what I did (see below), but both I and my clients
would prefer the standard Access dialog, which has more options.
Again, it's difficult to simulate exactly. It also bloody annoys me
that the standard dialog almost works, but not quite!
Those who suggest that most users don't need all-field searches if
the DB is designed correctly may be right, but not in this case.
There are about 10 fields in some tables where an all-field keyword
search is essential.
Use the datasheet view
----------------------
I'm not sure that this would work anyway, but it's not an option
because I need other buttons in the form header.
What I Did
==========
I eventually used a modal non-dialog form (B above) and put Find and
Find Again buttons in the pick form header which use FindRecord for
all-field searches. A bit messy but not too bad. (The header also
contains keywoard search and sorting controls.)
As I said above, if you have any suggestions please tell me. Also I
can send the test DB if you want to try it.
Andrew