Right-click menus and toolbars cause slowdown

[Petr Dane¹]

In an Access 2003 database, I have a fairly complicated form to which I
recently added a bunch of multi-level right-click menus. Fifteen, to be
exact, all from various comboboxes or textboxes. The data base suddenly
takes quite a long time to load. The form containing all these controls
still starts up reasonably, once Access is running, just the database itself
takes forever. It's not that large, barely over 30MB when repaired and
compressed.

I tried unhooking the RC menus from the controls - no improvement.

I then changed all the RC menus back to toolbars, which caused Access to
lock up for about ten minutes, with pretty high (55%) processor utilization.
Eventually, it came around, but still no improvement.

The next move was to turn off display of the newly visible toolbars, again
no help.

I finally actually removed the toolbars altogether, which again caused
Access to lock up for about ten minutes. It finally recovered and the load
time is now better, although it still seems somewhat pokey compared to how
it was before I started all this. I run it on several different machines
with varying capabilities, though, and this is just a subjective impression,
maybe not all that accurate.

Granted, some of these menus are pretty extensive, one in particular has
over a thousand options, down to three sub-levels.

Is this normal behavior? Getz, Litwin and Gilbert note that the CommandBar
object is not especially fast, but should the mere -presence- of these
objects have such a drastic effect on Access in general? The RC menus work
quite rapidly when they're being used - no noticeable delay before
displaying when right-clicking a control containing these menus, and the
code they call responds immediately.

Petr

 

[Albert D. Kallal]

I can't really say that increased numbers of custom menu bars has really
affected the load time or performance of my applications in a noticeable
way.

There is not really a lot of comments and historical comments in the
newsgroups that seems to come up with pointing this being some type of
problem. I'm not really convinced that increased numbers of menu bars is
a significant performance issue for applications.

What I would do is go Through the standard list of performance issues
that often arise for your front end application part.

There is a great list here:
http://www.granite.ab.ca/access/performancefaq.htm


Work your way through the above list , and keep in mind that track
auto name correct is somthing you might want to check. I
would also suggest that you consider doing de-compile. And further
I suggest that you always distribute a mde to your users.

You will notice in the above checklist that as a result of about ten years
of scanning and Receiving comments from the users in these newsgroups, you
don't see the issue of custom menu bars mentioned in that above list.

 

[Petr Danes]

Thank you, Albert. I am familiar with the list and have done all those
things, many repeatedly, especially the decompile and recompile, since I
work on this database quite a lot, and it occasionally corrupts, due to the
heavy forms editing. Nothing has helped, except to remove the toolbars
completely from the database.

You're right about there not being much mention of problems with this, but
that may well be because not many people use custom toolbars nearly as
heavily as does this one. They're rather a PIA to code, to be honest, and I
only developed these RC menus because they're an enormous help to the end
user.

I can't deliver an MDE to this user, since she needs the ability to
occasionally make her own queries when I am not immediately available, but
she is a very well behaved user and does not poke her fingers into things
that I have told her to not to.

Otherwise, this database has been in use for a good six or seven years, gone
through a great deal of development as the user's needs (and my Access
skills) have evolved and has always performed admirably. The only issue I've
ever had that I have been unable to fix is this speed with the toolbars. I
can't for certain say that the toolbars have caused the problem, but I have
a perfect correlation: toolbars installed, slow load; toolbars not
installed, fast load.

If you can think of anything else I might try, or places to research, I'd be
glad to hear about them.

Petr

 

[Howard Burgman]

Thank you, Albert. I am familiar with the list and have done all those
things, many repeatedly, especially the decompile and recompile, since I
work on this database quite a lot, and it occasionally corrupts, due to
the heavy forms editing. Nothing has helped, except to remove the toolbars
completely from the database.

You're right about there not being much mention of problems with this, but
that may well be because not many people use custom toolbars nearly as
heavily as does this one. They're rather a PIA to code, to be honest, and
I only developed these RC menus because they're an enormous help to the
end user.

I can't deliver an MDE to this user, since she needs the ability to
occasionally make her own queries when I am not immediately available, but
she is a very well behaved user and does not poke her fingers into things
that I have told her to not to.

Otherwise, this database has been in use for a good six or seven years,
gone through a great deal of development as the user's needs (and my
Access skills) have evolved and has always performed admirably. The only
issue I've ever had that I have been unable to fix is this speed with the
toolbars. I can't for certain say that the toolbars have caused the
problem, but I have a perfect correlation: toolbars installed, slow load;
toolbars not installed, fast load.

If you can think of anything else I might try, or places to research, I'd
be glad to hear about them.

Petr