Manipulating top level menus

[David]

The application I am modifying uses a complex set of
global API functions to manipulate the top level menus -
which are customized for this application.

Is this a normal Access practice? I dont want to spend any
time messing with this as I dont understand it. I would
like to get rid of the whole thing and prevent use of
those menus entirely.

I am talking about the 'File', 'Edit' etc. options and
associated drop-downs at the top of the screen.

 

[Albert D. Kallal]

The standard approach to custom menus is simply to build your own, as
customizing the built in ones is a bad idea (they don't copy when you move
it to another pc).

I not aware of any "general" approach that developers use that calls a
windows api for this.

There is a rich command bars system in ms-access, and the menu structures
can be built with no code (you use drag and drop). You of course can set
each button/menu choice to call your own custom code, but the crating of
those menus is generally created with the mouse.

Here is a chapter from a a97 book on menus. While the code examples are a
bit old now, it does give you a run down:
http://www.microsoft.com/accessdev/articles/bapp97/toc.htm

Also, I would not dump the use of menus, as virtually every application you
install, or purchase does have menu bars. Menus are a REAL time saver for
new users of your application, since all windows appcltions have them. I
would not overlook the power, and the ease of use that well done menu bars
give to applications. The very reason for much of windows popularity is
menus. It would be a shame to dump the use of them.

For some sample screen shots, and as to "why" you should use menus
ms-access, read the following of mine:

http://www.attcanada.net/~kallal.msn/Articles/UseAbility/UserFriendly.htm

 

[David]

Unfortunately, I simply don't have time to implement menus.
This is a big and complex system and to implement menus
would require hundreds of hours of extra work. And there
is no time allowance in my schedule for training.
If they are so important, how come there is no information
in any Access book on creating menus?
Creating the menus would be trivial but knowing when to
enable and disable options would be exceedingly complex.

 

[David]

Some good advice and tips there but who has the time to do
all that? Manager's just dont understand and they control
how long they expect tasks to take. Consequently, all of
us developers cut corners.
I'd love to spend 2 or 3 weeks producing a beautiful
intuitive menu system but it will never happen.

 

[Albert D. Kallal]

Unfortunately, I simply don't have time to implement menus.
This is a big and complex system and to implement menus
would require hundreds of hours of extra work.

Well, the problem is that I would bet that many of the forms now have
buttons that launch, and do things now. The time it takes to build/add/use a
menu system is no longer then what it takes to add a button to the bottom of
a form. The problem is that after 6, or 7 or 8 options, then the bottom of
the form becomes a real mess. As mentioned, it takes no longer to add a
button to menu bar via drag and drop then it does to add a button to a form.
The problem you have is not one of time to make, or add a menu system, the
problem is that a menu system was NOT made as the application was built.

So, just like you don't build the whole application AND THEN start placing
buttons on the forms to do things, the same applies here:

You add menu bars and buttons AS THE application is being made.

So, you are probably correct that adding nice menu system to your existing
application will take some time. On the other hand, it does not take much
time to move the buttons from the form to a menu for THAT particular form.
Further, when one starts writing menu code, often you take a MUCH MORE
re-useable coding approach. Thus, often the SAME menu bar can be used for
many forms. Now, you are actually saving programmer time, as many forms
actually get MORE features for a given amount of developer time. If done
right, you save the effort of having to add a whole bunch of buttons to each
form each time (many times, a menu bar is re-useable). So, in fact, if you
HAD used a menu system, you may well have saved valuable developer time, got
a nice menu system, and had a final product that is more user friendly, and
more windows like. Further, re-using the same menu bar for forms also
reduces the training time for your users, and makes your application easer
to learn.

So, less developer time, a more consistent interface for each form (less
training), and a more standard windows product for less money sounds good to
me!

If they are so important, how come there is no information
in any Access book on creating menus?

Gee, as far as I know, most ms-access books have a chapter on menus. The
free on-line a97 book link I posted has such a chapter. Looking at my
bookshelf, the Visual Basic for Applications a97 book (sams) also has a good
BIG chapter on menus. So, the very first two books I looked
at have very rich chapters on menus in ms-access.

Creating the menus would be trivial but knowing when to
enable and disable options would be exceedingly complex.

I actually agree with the above. So, the solution is to make a menu bar for
each form. That way, when the form loads, the menu bar the user sees is JUST
for that form. For the many forms that don't need a menu bar, they will use
the "main" menu bar that has the standard Edit, Help etc. I usually make a
standard menu bar for ALL forms that don't have their own. (fact is,
ms-access works that way now, and all your forms no doubt show the main menu
bar now! So, if you make just ONE main menu bar, then you instantly hide all
of the ms-access interface. You can specify this menu bar in the start-up,
and
ALL forms will use this menu bar. Hence, this is really kind of your
original question: hide the ms-access interface with little, or no code.

Creating you own main menu bar will solve this problem.

I have a medium sized application with 160 forms, and a LOT use some custom
menu bar. However, I did not use ONE LINE of code to enable/disable the menu
options. I mean, if you place a button on a form to print a invoice, then
likely that button code has to check if there is a invoice number before
printing. If you are not writing a whole bunch of code to disable buttons on
your forms now, then why bother to write code to disable those same buttons
when they are moved up to a menu bar? There is no reason at all to disable
menu buttons UNLESS YOU NOW disable command buttons on a form.

I think your confusion lies in the fact that you don't realize that each
form should and can have its own menu bar. If you just remove/move the
current buttons from each form to a menu bar, then that is all you really
need here.

Further, if each of the forms only have a few buttons on the button, then
again I would tend to agree that the effort of moving those buttons to a
menu bar is NOT worth it. However, if often people ask how to improve the
"look" of their application. Often people are wondering why some appcltions
look so good, or so "windows" like, and others don't. You will usually find
that the windows application has NO buttons on the form.

Take a look at the following screen shot of a access application:

http://www.bid2win.com/product/images/lgEstimate-Detail.gif

The above looks good because you don't see a whole bunch of big square
buttons at the bottom of the form. The above looks good, and yet it is just
a ms-access screen.

So, I don't write code to disable command buttons on my forms either. It is
probably a nice touch..but as you mention not worth the extra coding time.
So, I would still consider using menus, as they make the application better
looking, and generally can reduce training time. When done right, they also
can reduce development time for the programmers.