FiveTech Support Forums

There are some old threads about ways to have accelerator keys for buttons on the button bars, but none are clean solutions.

The prompts do show an underscore, ie "&Add" shows up [u:23aolu4y]A[/u:23aolu4y]dd but there is no working accelerator.

So, for my wish list, it would be nice to see this activated in a future release.

Thanks.

Tim

Tim,

>There are some old threads about ways to have accelerator keys for buttons on the button bars, but none are clean solutions.

Windows standards are that you should have every function called by a button also on the menu. Since it is on the menu you can have an accelerator for the menu choice, and thus this appears (to the user) to also work for the button.

Menus are for novice users, buttons are for intermediate users, and accelerators are for advanced users. This is why every button function should also be on a menu.

James

OK ... but I don't have menus on all my dialogs ...
Maybe that is my bad, but they would be redundant ...

Tim,

>OK ... but I don't have menus on all my dialogs ...
>Maybe that is my bad, but they would be redundant ...

Oh, I see, you have buttonbars on dialogs. Most dialogs do not have buttonbars. Dialogs that do are generally for small seldom used utility programs and for these types of programs there are no advanced users--everyone is a novice since the program is seldom used.

You can provide accelerators using a trick. Add regular buttons (not buttonbar buttons) with accelerators to the dialog but make them hidden. The accelerators will still work even though the buttons are not visible. Make the invisible buttons call the same routines that the visible ones do.

I know this is not an ideal solution but it is a solution.

I don't know that I have ever seen dialog buttonbars with accelerators on any application. Have you?

James

James,

Its the old legacy thing, and trying to design to avoid errors.

My dialogs have buttons to handle various tasks, like adding records, deleting, saving, and subroutines. People often didn't read well, so this time I moved all the buttons to the top onto a button bar. Its easy because it is consistent ... they can always find the task options on any dialog because there is consistent placement. The result ... it works very well and people really like it.

Now for the problem. The regular buttons had accelerators. The button bar does not ! The guys that are keyboard oriented, and have been with me since the early DOS days ( early 80's ) like to do AMAP on the keyboard, so they liked the accelerators.

I did see your option, and I may try it, but that just seems to add a complication and more programming to track. I have to create some buttons, hide them, yet call them.

That is why I put a wish list item in for the accelerators on the button bar buttons. I figured maybe it wouldn't be such a big thing to add them !

BTW, creativity is when we can do something that hasn't been done before, so even if we haven't seen accelerators in the past on button bars ( and I think Ihave seen them ), it doesn't mean we can't create them.

Tim

Tim,

Yes, I understand the legacy issue, and I agree that creativity is a good thing.

However, if the Windows API doesn't provide for accelerators on buttonbars, then it may not be easy to implement. If you have never seen accelerators on a buttonbar, then API limitations may be why.

Creativity can be a good thing, but I see lots of creativity that doesn't really bring anything valuable to the party and users are now used to most windows standards. So, one needs a really good reason to violate the standard or users will not like it. Users would generally like to move from one app to another and have them all work the same way--sometimes even though it is not the best way or even a good way.

I am not passing judgement on what you are trying to do--you are the one best qualified to determine its merits in your situation. I am only pointing out some thoughts for consideration (for everyone).

Personally, I love to be creative--most programmers are creative types. Sometimes I find it hard to curb my creativity for the sake of uniformity. Hmm, make that "always" rather than "somtimes."

Regards,
James

Tim,
I changed many of my programs to ribbonbar. All is so much easier to handle.

Antonio is very hard working on accelerator keys for the ribbonbar and I think in a few weeks we will have it.

Now with OFFICE 2010 style all is so clean and very comfortable. I personally think that for many years this kind of navigation will be the standard.

Best regards,
Otto

Hello Uwe,
thanks to you I am using PIXELFORMA since some time.
In this ribbon I have still a mix of bmps 1616 and 3232.
Would you say 24*24 would be the right size?
Best regards,
Otto

Hello Otto,

32x32 looks good in relation to the Bar-height,
but because of many BMP's You are using, 24x24 might be the better Option.

Best regards
Uwe

James,

Microsoft Outook 2007. The Toolbars have accelerator keys. The button prompts have underscores ... use with an ALT key and they are active !

I seriously considered the Ribbon bar in this upgrade for my software but went with button bars because they are a bit less confusing ! The major comments since Microsoft released ribbon bar technology has been that it is confusing !

Tim

Tim,

>Microsoft Outook 2007. The Toolbars have accelerator keys. The button prompts have underscores ... use with an ALT key and they are active !

But it also has a menu, so the accelerators are probably for the menu even though they appear to be for the buttonbar. That was my first suggested solution.

James

Tim,

I looked into this a little more. I discovered that there is an accelerator table that is an object contained in the menu class. This table holds all the accelerator keys and the IDs of the menu items to trigger.

The issue is that only one accelerator table can be active at any one time, so if there is a menu accelerator table, then there cannot also be a buttonbar accelerator table too. If the buttonbar did have an accelerator table, then whichever object was substantiated last (the menu or the buttonbar) would have an active accelerator table and the other one would be inactive. So, this presents a problem when using both a menu and a buttonbar.

I think a better solution for the case when you are only using a buttonbar, might be to build your own accelerator table outside the buttonbar class. If you also have a menu (outside the dialog) then the menu accelerator table would have to be disabled while the dialog is active, then activated again when the dialog is closed. If you are using non-modal dialogs then you cannot do this because of the single active accelerator table issue.

Regards,
James

I seriously considered the Ribbon bar in this upgrade for my software but went with button bars because they are a bit less confusing ! The major comments since Microsoft released ribbon bar technology has been that it is confusing !