Custom Ribbon Screentips Are Unprofessional in Access 2007

[Sky]

I have been converting an application to use the new ribbons in Access 2007.

When you create any custom button to perform an action using ribbon XML, you
can specify a screentip that is displayed when the mouse cursor hovers over
the button. This is great. But at the bottom of the screentip, Access also
displays an additional prompt "Press F1 for more help", as below:

MyScreenTip
-------------
MyAppTitle
Press F1 for more help.

In the above, MyScreenTip is the button's assigned screenTip value, and
MyAppTitle is take from CurrentDb.Properties("AppTitle"). Even if no
screenTip assigned at all, the remainder is still displayed when hovering
the mouse.

Worse yet, if you make a custom ribbon and assign it to the Ribbon Name
property of a form, your custom screentip is displayed along with the
literal form name (not the form caption). For example:

MyScreenTip
-------------
frmAccount
Press F1 for more help.

In the above, MyScreenTip is the button's assigned screenTip value, and
"frmAccount" is the actual name of a form that uses the ribbon. Typically
the user does not recognize this form name (unless we rename all our forms
just to provide better screen tips).

I can capture the F1 key using AutoKeys and display my own help, but I
cannot determine any context from the ribbon to display help related to what
the user is pointing at with the mouse. So Microsoft has put us in a very
unprofessional position with regards to help for the ribbon, automatically
telling the user to press F1, but not giving us a chance to respond
appropriately. (Microsoft's own built-in controls may also display an F1
key, but then you get help that is directly related to the specific
control.)

The display of the literal form name without any control by the developer is
also unprofessional. (In my case, I use "frm" as a prefix.) And even with
the main application ribbons, who wants to see the application title
repeated over and over on every control in the main ribbon?

I cannot see any way to alter the additional "Press F1 for more help" that
is added to the screentip. A search online indicates that others have the
same problem, and that it is a deliberate feature not a bug:
http://www.accessribbon.de/en/index.php?FAQ:10
http://blogs.msdn.com/andreww/archive/2008/04/02/vsto-loader-and-runtime-compnents.aspx
http://www.add-in-express.com/forum/read.php?FID=1&TID=4307
http://www.utteraccess.com/forums/showflat.php?Cat=&Number=1423902&Main=1423145
http://social.msdn.microsoft.com/Forums/en-US/vsto/thread/fd820223-f947-4c10-a3df-902e98c596ab/

I don't know this is Microsoft's goal, but it makes every custom ribbon look
unprofessional.

Right now my only option is to display a large, generic help file that
contains information about ALL ribbon buttons, which the user can try to
search and find explanations (good luck with that).

Any suggestions?

- Steve

 

[Albert D. Kallal]

Right now my only option is to display a large, generic help file that
contains information about ALL ribbon buttons, which the user can try to
search and find explanations (good luck with that).

Any suggestions?

Well, you could certainly tie the f1 help to the particular screen that has
the focus. So, you setup your autokeys macoro to to run a public function
called MyHelp.

In a standard code module, you could then go:

Public Function MyHelp()

Dim frm As Form

Set frm = Screen.ActiveForm

MsgBox "global help, form = " & frm.name
MsgBox "ribbon for this form = " & frm.RibbonName


End Function

I suppose you could even have a function in each form called frmHelp, then
the above code would be:

Dim frm As Form

Set frm = Screen.ActiveForm

frm.frmHelp()

The above would then run the public function you have defined in that form.

I am not aware how to grab the actual context id of the button from that
ribbon, but the above would give you the current form the user is on, and
also the name of the current ribbon they are using.

The above does allow you to give help on a form by form and also a ribbon by
ribbon name bases.

Keep in mind that most of my ribbons tend to call vba code directly in the
given form that has the **FOCUS**. This focus concept is important because
if you specify a ribbon button to call a public function, the form with the
focus is where access looks first for that function. If the function is NOT
found, then the function name in a standard public module well be run. This
results in two very nifty things:

1) One ribbon can be used for many different forms, since the public
functions are called in the forms code.

2) You might have 15 forms, but only 3 of them need a special "custom
delete" code. You simply build a global public function in a standard
module, and it will be run for all 12 forms, but for the 3 special cases,
you place a public function in the forms code module..and THAT ONE will be
run when the ribbon button is clicked on. In fact most of my forms have a
public function called Mydelete, and thus that's is what I have my delete
button call from a custom menu (or now custom ribbon).

Unfortunately the above focus "trick" does not work for autokeys macros, but
as my code shows, you can still pick up the name of the active form and that
gives you both the form name and the ribbon you specified for that form.

 

[Sky]

as my code shows, you can still pick up the name of the active form and
that
....

you can still pick up the name of the active form and that gives you both
the form name and the ribbon you specified for that form.

Yes, I can easily determine the active form name and the ribbon name, and I
can provide generic help for the ribbon. And I understand the basics of
ribbons and callbacks that you have described, including the use of
TabSetFormReportExtensibility to bring the correct ribbon forward on a form.
But a ribbon can easily have 20 or 30 controls, especially with menus, and
that is the problem.

You did not address the real question: if the user does not actually click
on a button, but instead hovers over the screentip and presses F1 as
instructed by Microsoft, I cannot display context-sensitive help because I
can determine what button it was. All I can do is display generic help for
all 20 or 30 options on the ribbon, which is really non-responsive and
simply confuses the user. Do your users find that acceptable?

(I would certainly criticize Microsoft if they did something like that, but
of course they certainly do not do that. Instead they provide specific
context-sensitive help for their controls that display "Press F1 for more
help", and for controls that do not need help beyond the screentip they skip
the "Press F1 for more help" completely. All I'm asking is for we developers
to be able to do the same.)

And why display the form name in a screentip, such as "frmAccount"? I can
see no way to avoid this other than actually renaming forms in order to get
user-readable screentips. Otherwise you have to explain to a user what
"frmAccount" means. Do you rename your forms, or do you tell the user about
internal software naming conventions?

- Steve

 

[Albert D. Kallal]

You did not address the real question: if the user does not actually click
on a button, but instead hovers over the screentip and presses F1 as
instructed by Microsoft, I cannot display context-sensitive help because I
can determine what button it was.

Ah, yes, I did agree that the above is a problem, but did not realize that
is your "main" problem here.

All I can do is display generic help for all 20 or 30 options on the
ribbon, which is really non-responsive and simply confuses the user. Do
your users find that acceptable?

Right, but how often do you have 30 buttons on a ribbon? In most cases, I
don't have a lot of buttons on that ribbon. Perhaps around a max of 8-12. Of
course those 8-12 buttons will have also some of the built in groups/buttons
tacked on (I not counting those). Perhaps you post a picture of this ribbon
with so many controls on it, since I think a re-design might be in order.

So, yes, for about 99% of my cases a simple help screen is more then
acceptable for my users. After all, I only going to have to outline the 5-10
options and a simple HTML help file is MORE then adequate in that case.

Heck, a good deal of the built in ribbons that we use in design mode have
about 30 buttons for us developers. I would be hard pressed to come up with
a ribbon that has 30 custom controls, let alone 20. And, judging by the
number of posts in this newsgroup, it not been a HUGE end of the world
problem here.

Now, having said all the above I 100% agree we ABSOLUTE need a means to
determine the context of what's been hit in that menu. I not really looked
very hard for a solution to this since as I mentioned, it not been a real
big problem for me.

And why display the form name in a screentip, such as "frmAccount"? I can
see no way to avoid this other than actually renaming forms in order to
get user-readable screentips.

Yes, I would prefer they used the "caption" text from the form. And even
better would be to allow us to remove that f1 text part of the ribbon
altogether. Of course, this is only the 1st edition of the ribbon, and it is
simply missing some things we need.

We can only hope some of these shortcomings are addressed in the next
version.

 

[Sky]

Right, but how often do you have 30 buttons on a ribbon? In most cases, I
don't have a lot of buttons on that ribbon. Perhaps around a max of 8-12.

My database provides input to a complex simulation model, and displays all
outputs from that model. So the main ribbon includes a number of menu
choices to display/edit a large number of the inputs and outputs. These are
organized in different tabs and groups, with menus and split buttons. And I
do include many of the built-in controls.

Even the basic Microsoft "Home" ribbon has 138 elements (including all
dropdown options and menus), according to the documented list of tab sets
and controls from Microsoft. And that count does not include the other tabs
such as Create, Import/Export, etc. The entire built-in "Core" ribbon, with
all tabs, contains 301 elements!

In a simple split button or menu with submenus, EVERY single customized item
in the tree gets the treatment of "Press F1 for more help", along with
obscure form names. So it all adds up very quickly. Perhaps we are counting
differently.

Yes, I would prefer they used the "caption" text from the form. And even
better would be to allow us to remove that f1 text part of the ribbon
altogether. Of course, this is only the 1st edition of the ribbon, and it
is simply missing some things we need.

We can only hope some of these shortcomings are addressed in the next
version.

Agreed.

- Steve