Chris, the behaviour you describe applies to forms that are both modal and
popup.
Would it be appropriate to use a form with Modal set to Yes, but Popup set
to No? This lets the user get to toolbars, minimize the Acess, etc, but not
switch to another form.
The next suggestion may not be appropriate for your situation, but I often
see developers trying to maintain tight control over program flow just
because they do not thing event-driven. It is possible to create an Access
application that allows the user to go almost anywhere, almost any time.
Yes, it does take some extra effort to achieve that, and particular to
handle the concurrency issues, but the result is a truly amazingly flexible
application.
This kind of design is inappropriate where the database user is typically a
novice who needs you to hold their hand and is lost without a wizard-like
interface to walk them through a set of procedures. However, if a client is
paying you to develop an application for them, they will be using it every
day, and the rigid, procedural interface soon becomes tiresome. My
experience is that the totally flexible, go-anywhere-anytime,
do-anything-in-any-order interface is much better, and is worth the effort
it takes to develop it.
So, what we do is to call a generic procedure in the AfterUpdate and
AfterDelConfirm events of all bound forms. During most of the development
cycle, this proc is just a stub. Once all forms and reports are in place,
this proc becomes a large Select Case structure that responds to each form's
updates, and handles the concurrency issues on each form that could be
affected if is is loaed (e.g. by requerying combos). Although this approach
breaks the general ideal of creating many small procedures instead of one
large one, it lets you develop the app piecemeal and sort out the
concurrencies once you have all the dependencies in place, and it
facilitates maintenance if other things are added later: there is only one
place to look to check for any new/affected interactions.
--
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.
"Chris" <ch**********@h otmail.com> wrote in message
news:f0******** *************** ***@posting.goo gle.com...
Modal forms are great for locking the user out of non focused forms
allowing tight control over program flow, but they have one side
effect which user find very irritating i.e. Access cannot be
minimized.
Perhaps I should be satisfied with the routine I have written which
disables controls on a form before the popup form is opened but a
background form full of disabled controls can look damned ugly in
certain circumstances:-
Function EnableFrm (onoff As Boolean, frm as form)
Dim ctrl As Control
For Each ctrl In frm.Controls
On Error Resume Next
ctrl.Enabled = onoff
Next ctrl
End Function
Other than putting a desktop shortcut in the taskbar does anyone have
any alternative suggestions to this conundrum.
Many Thanks
Chris
