By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
426,222 Members | 1,129 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 426,222 IT Pros & Developers. It's quick & easy.

Modal Form & Minimizing Access

P: n/a
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
Nov 13 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
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**********@hotmail.com> wrote in message
news:f0**************************@posting.google.c om...
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

Nov 13 '05 #2

P: n/a
Allen,

Since the majority of our users are not technically minded a rigid
system has been decided on. Our existing system is an anywhere anytime
database and the implementation is rather confusing, although I must
say I do like Quickbooks way of doing things and if I were to follow
this path I would probably try to copy their model.

Modal forms follow maximized/restored state of the background form,
behavior I was trying to avoid. I guess if it comes to it I will just
have to knuckle down and redesign a whole lot of forms.

Thank you so much for your suggestions it has given me another angle
with which to view our front end design.
Nov 13 '05 #3

P: n/a
Allen
Since the majority of our users are not technically minded a rigid
system was decided on. Our existing system is an anywhere anytime
database and the implementation is rather confusing, although I must
say I do like Quickbooks way of doing things and if I were to follow
your suggested path I would probably try to copy their model.

Modal forms follow maximized/restored state of the background form,
behavior I wished to avoid. If it comes to it I will just have to
knuckle down and redesign a whole lot of forms.

Thank you so much for your suggestions it has given me another angle
with which to view our design.
Nov 13 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.