Climbing/Descending menu options

[Thomas Kroljic]

All,
I have a database application that uses the default Switchboard (form)
menu system. From one of the menu options I open a form that displays a list
of customers. The user can double click on the record indicator and go
directly to another form that allow the user to edit the specific customer.
Once the user is done editing the customer record they currently click on a
close button that closes the detail form and brings them back to the
customer listing form. On the Customer listing form is a button that allow
the user to close this form and return to the menu system (switchboard). As
the user progresses down the chain of menu options and forms, they close
each form (level) and return to the previous.

My question is this: If the user selects a menu option that goes to a form
that list all the customers, and then they double click on the record
indicator to go to another form to edit the selected customer, is it
possible to have a command button on this form (the detail form) that when
the user clicks on it, it closes the current form and jumps to another form
that the user would normally reached with different menu options then the
options they selected to get to the customer form?

Normally, the user selects option and moves down various levels. Then they
return climbing back up to the very top level. I want to know if its OK to
jump across levels and return back to the top level via a different route.

Hope this make sense.

Thank you,
Thomas j. Kroljic

 

[Allen Browne]

Thomas, there nothing wrong with what you are suggesting. It is a question
of style, and also a question about what will best suit the people who will
use your database.

If you have casual users who use the program rarely, and need you to hold
their hand and walk them through a very specific set of steps (like the
Wizards in Access), then it might be best to stick with the highly
structured approach of one-step-at-a-time, following the
work-down-from-the-top-and-back-up approach.

If you build databases for people who will use it every day, IME they prefer
the flexible approach where you let them go-anywhere, anytime, providing
multiple paths. If they missed a step (such as adding an item to a lookup
table), they can just double-click the combo, and you pop up the list, they
endter the item, close the form, you requery your combo for them so the new
entry is there, and on they go. Personally, I find this kind of approach
much more fun to create, and I always enjoy discovering the paths the users
end up taking to handle their data. Quite often they are handling things
well outside of what I imagined when I design the app, and it's a buzz to
see the creative options they have taken.

The double-click-to-drill-down is really the core of that flexible approach,
so my suggestion is: Go for it, if you think your users will be able to
handle the flexibility.

Suggestions if you take this approach.

1. Document it! Explain to the users that there are not a set of procedures
they have to follow, and why you are giving them this flexibility. Then give
them a set of procedures to get them started so they are not too overwhelmed
by the freedom you are giving them.

2. Explicitly save. Because you are (potentially) leaving lots of things
open at the one time, particularly in a multi-user environment you don't
want too many dirty forms all open at once, so save the record where you
can. (Obviously that does not apply to the example above, where the person
needs the new lookup value in the combo before they can save that record.)

3. Requery combos. If there are potentially lots of forms open, with lots of
combos on those forms, and you let the user handle anything anywhere, the
dependency question arises, i.e. How do you keep those forms and their
combos up to date? That's complicated by the fact that when you are
programming one form, you don't know which other forms may have dependencies
on it. What I do is to have every form call a generic procedure in its
AfterUpdate and AfterDelConfirm events. After all forms are in place and I
know which depends on what, I then fill in the details of the generic
procedure wiht a huge Select Case structure that receives the calling form's
name and Requeries any other forms/combos/listboxes that depend on it, if
they are open. Although this monster procedure is many screens long, it's
the only way to handle all dependencies after all forms are in place.

4. Keep something open. Because users can open and close anything at any
time, they might find themselves with nothing left open. I therefore use the
Close event of every form and report to call another generic procedure that
checks if there are any other forms or reports open and visible. If not, it
opens your switchboard form again.

Hope that's useful.

 

[Thomas Kroljic]

Allen,
Thank you very much for the detail info. I do appreciate it. I didn't
expect such a long reply but it was very informative and helpful.
I feel more comfortable now knowing that I can jump from one module
(business process) to another instead of climbing back up to the main menu
and then down into another section of the application.

Thank you,
Thomas j. Kroljic
Philadelphia, Pa