Re: Button list control

"Hans-Peter Diettrich" <DrDiettrich@xxxxxxxxxxx> wrote in message
news:40ii32F1aefjsU1@xxxxxxxxxxxxxxxxx
> Maarten Wiltink schrieb:
[...]
> the Enter key works on the *focused* button, ...

Actually, that's Space. (Excuse me, my soapbox just inserted itself
under my feet. Nothing I, or you, can help.) Enter works on the
*default* button in the active dialog. A button will become the
default button temporarily if it is focused, but other controls,
as long as they don't catch Enter themselves, will allow Enter to
be forwarded to the default button.

I cringe every time I see people type a username and password, then
reach for the mouse to click "OK".


[...]
> As every class can implement specialized behaviour, under an inherited
> method or event name (OnClick...), I consider every control or form as
> something special, acting in the context of a program framework. If
> your applications allow for general actions, regardless of context,
> then you can put all that functionality into the main menu. But there
> can exist other cases, where a command (or action) has to act in a
> more specific context.

That is not precisely how I meant the word "command". Action would indeed
be a synonym, and TActions are a very good implementation of them in
the VCL. Especially so since Actions are independent, since they _can_
be hooked up to controls, including menu items, and keyboard shortcuts,
but they can also be left floating, accessible only to other code as
little named blocks of functionality. Blocks with state. Most commands
have certain prerequisites, often that the selection is of a certain
form, and may be disabled some of the time.

So in my mind, a command or action is not so much coupled to a certain
context, but to a certain state of the application. Otherwise, it
remains in existence but is simply disabled.

While it's always tempting to start there, controls are really not the
basis of an application. Controls are the basis of a user interface.
They allow for the exchange of data with the application (input and/or
display), for the activation of actions, and (parasitically, almost)
for manipulating the user interface itself.

At the basis of the application are its actions, and the data they
work on. Separate those, and the user interface, and you have reinvented
MVC. Obviously therefore, it must be a good idea.

I remain worried about the concepts of "focus" and "selection". The
actions react to them, while they are attributes of the user interface.
This seems to me the wrong way around. Perhaps the granularity of
actions _is_ wrong, and they should have explicit parameters instead
of looking to the user interface, or the application's active context,
for them.


>> And the main menu, as I see it, is there to serve as an index of all
>> available commands.
>
> Then the main menu also must reflect all the different contexts in the
> program, and only the submenus of currently active contexts can be
> enabled.

That is in fact precisely what happens in my applications.

For instance, I currently have an application that deals with
"transactions" - think of them as email messages with requests to do
things. Transactions are between actors, and have a state. Several
views are available in the application.

The File menu is renamed Transaction and contains a submenu Action
where items (commands) such as Refuse, Delegate, and Accept are located.
The Action submenu is enabled only when a transaction is selected (in
any view). The individual items on it are enabled only when a transaction
is selected on which the active user has the right to take that action -
only the person who has promised to do something can delegate it to
someone else.

There is also a menu item Transaction/Print which is enabled only when
a printable view is active.


> An interesting idea, indeed.

It came about naturally for me. Perhaps I need to rethink my opinion of
the meaning of "application state", which is the usual term I use for
where actions look to determine their current availability. Your word
"context" might indicate a partitioning of the single global application
state, where actions should only be examining the selections in a single
context, where the active context is determined for example by the focus,
and actions applicable only in any other context can immediately disable
themselves.


>> How else will you find out all the commands, and
>> the keyboard shortcuts? Read the manual?
>
> Manuals seem to be something for old fashioned people, today you often
> must be happy with a lousy online help, that's not worth that name. In
> so far I understand your idea of a self explaining "global" main menu.

Well, that's progress, isn't it? (-: Gone are the days of inch-thick
manuals with crappy binding, replaced by a self-explanatory main menu
and hopefully not too crappy context-sensitive on-line help. Of dumb
terminals with smart people in front of them - because only they could
remember the seventy-eight different functions keys that caused all the
different screens to come up.

As a side note, I call it a main menu so as not to have to call it the
window menu. I don't want it to be confused with the Window menu on
any main menu. But an application can have several windows (contexts?),
each with their own main menu.


>> And treating the main menu like a context menu is wrong. There are
>> already context menus.
>
> Sorry, I cannot understand this, or did I misunderstand what you said
> before?

A main menu should as a rule not make items _invisible_, so as to offer
only a context-sensitive selection. Items should at most be disabled.
There are occasions where this rule can be broken, but not to the extent
that Office 12 is apparently about to.

Is this a soapbox I see beneath me? Thank you, you've been a great
audience. Now I have to go and think more about these things, as I am
no longer as sure about them all as I was.

Groetjes,
Maarten Wiltink


.