The discussion recently about a "menu" component made me think about
how I'd go about making one. What would I want in such a component
anyway? And when I thought about it, I thought it worth having a
discussion here to gather opinion, because I don't think it is
straightforward.

A menu in a Delpgi desktop application is a Row of labels that have
drop down items. Everyone knows what that is. Advanced menu systems
have a Toolbar link too, and Actions make them easier to control.

But what is a menu on a web page? It occasionally is a long line of
items. But more commonly it is a "hamburger icon" with a drop down list.

And how much design time UI do you want? How much is sensible, and how
much actually needed.

My initial design then, goes as follows:

The component set consists of a TMenuPanel, a TMenuButton, and a
TMenuItem.

TMenuPanel is the visual container that you can customise to make your
menu look how you want. It contains nothing itself other than being the
"end caps" for TMenuButton. You can put in a single TMenuButton, or a
lot of them if you want a full menu bar. I guess you could have an
event handler here for common child menu handling.

TMenuItem is the visual container that you can customise to make your
menu items look how you want. It doesn't do a lot itself as it is
mainly managed by the TMenuButton.

TMenuButton is the component that does the real work. Visually, it may
have an icon and or text label. When you click on it, a panel
containing TMenuItems stretches down (or up?) to display the
TMenuItems. Click on a menu item and the menu disappears and an event
is fired to tell you which. Click away from the menu and the drop down
disappears.

Now the bit I think that will be most controversial. I'd define the
menu content as a simple string list. It would look like:
1=File open
2=File close
14=File save
16=Export>20=To file|21=To PDF|22=To JSON
30=Send email

The numbers are the event number that will come back to the event to
tell you which was pressed. The text is what is displayed. If the text
contains a > character, then it defines a sub-menu, of similar
OR-separated items.

I think this is a sensible thing as it is easy to define at design time
and in code. And I think that code is going to be a common place for it
to be updated. Why not have it as a TStringList that can be built up
from a list of names and then assigned?

Anyway, that's how I'd do it on the thinking I've done so far. What did
I forget? What would make it better?

Matthew Jones wrote:

> My initial design then, goes as follows:
>
> The component set consists of a TMenuPanel, a TMenuButton, and a
> TMenuItem.

I'm surprised no one saw fit to blast my design - no one really
interested in a menu component?

"Matthew Jones" wrote:

> My initial design then, goes as follows:
>
> The component set consists of a TMenuPanel, a TMenuButton, and a
> TMenuItem.

That sounds like a reasonable approach.

AFAIC, using the VCL model for the object hierarchy makes sense to me.  After all, why reinvent the wheel?

As far as the implementation goes, there are many JavaScript menu implementations out there and some use CSS (although I'm still unclear how CSS plays a role and/or can be leveraged in EWB 2).  So I imagine someone more familiar with JavaScript might be able to offer more constructive feedback.

> Now the bit I think that will be most controversial. I'd define the
> menu content as a simple string list.

This could make it easy to dynamically create menus, however I would prefer not to be locked into a specific format, since this could easily be done yourself just like in the VCL (e.g., http://stackoverflow.com/questions/2345381/delphi-dynamic-menu-items).  A fluent interface could also be implemented on top of that if desired.

Of course, the menu would also have to be responsive depending upon the device resolution, so that it could be displayed as a "hamburger icon" with a drop down list, like you mentioned.  But I wouldn't want that to be the default display mode.

Doug