If you don't know what a Ribbon control is: [this] is the best tutorial I've yet come across - concise and informative. Also the best tool to build ribbon markup files (unless you really like editing XML). Knowledge of COM is required to understand the code - it's just a bunch of pointer shuffling and reference counting.

[This will only work on Vista or greater Windows versions and 64-bit.]

We start with the minimal code needed to produce a Ribbon control. UICC is needed from the SDK to process the Ribbon XML.


Changes:

2013.04.10 - less buggier
2013.04.11 - added a bunch of controls to show-off the defaults

The example looks good. Talking of the internals: I like your custom 'import' macro that may save time when you have to type a list of imported functions. What a pity I can't compile it in my OS.

What hinders compilation? UICC will work without the rest of the SDK. Build process is just: UICC, RC, FASM. I use a bunch of resource tools: ResHacker, Resourcer, ResEdit (mostly, but it crashes on some things). Usually, I just save the RES file from one of these editors.

Best thing about the ribbon is how it separates UI design from programming the internal software. Even with this barebones example, a very complex UI can be created by just adding BMPs and editing the XML -- there are some advanced controls which will need a couple more interfaces.

A more comprehensive template will follow...

I use neither UICC nor RC, so it seems that to compile this example I should install those tools?

Compiling Ribbon Markup
ResEdit

Yeap, those tools are required. Or, just install:
Windows Software Development Kit (SDK)
The complete installation of the Windows SDK requires 10 megabytes (MB) to 1 gigabytes (GB) hard disk space for installation, depending on the features selected.


Alternately, we could maybe RE the BML file format.

OK, I take a look at it and will probably install SDK. However it would be far more interesting if this example was in pure FASM (I mean if there wasn't a need to use all those "prefabricates" produced by external tools).

Of course, I agree. Downloading a few 100MB for 3MB's is kind of silly. I like to have the latest header files for sanity checks, anyhow. The BML file appears to be almost like a resource file within a resource file. I'm sure it can be reverse engineered in time - then we could use macros instead of XML.

Until then, here is a nice preview tool for the XML (requires SDK and LINK.exe):
http://archive.msdn.microsoft.com/PreviewRibbon/Release/ProjectReleases.aspx?ReleaseId=3412

Another one:
https://sites.google.com/site/huyvantan/start/my-programs/ribbonmarkupcreator

Only need uicc.exe and uiccdll.dll - they work stand alone.
ResEdit can be run in batch mode with a commandline:
e.g. "ResEdit.exe -convert .\Res\main.rc .\main.res"

ResEdit doesn't work because the strings in the output from UICC need to be null terminated (RC /n). That error took way too long to resolve. I've also been having trouble converting to 32-bit BMP files which are valid according to windows. PNGs can be used in Windows 8, but require more memory at run-time.

Added a bunch of controls to the ribbon XML: button groups, check, spinner, color/font pickers, tab context, and app menu. Also, show how to reference commands by Id instead of Name (even though it's called Name). Just taking advantage of the defaults - haven't added any graphics for the buttons.

At this point, I think there are error due to dialog processing. So, I'm going to switch to using a regular window. Documentation on the native ribbon control is kind of flaky or confused with the other two ribbon APIs from MS.

So, far the best design tool: http://www.bilsen.com/windowsribbon/index.shtml
(Which includes UICC, and correctly converts PNG/BMP to 32-bit BMP format.)

The above has become an example of what not to do.

I've moved this over to github.
https://github.com/bitRAKE/rib-rub

Using a window as the parent control, have contex control working, and state preservation across execution. Everything appears to be solid. No command handlers, yet.

Next up, are most recent file list (MRU), and then I'll do the drop-downs and galleries. My current thinking is that I can avoid using all the COM type translations if I track state changes as they happen.

For example, user checks a box - command gets sent - handler sets a bit in application space. The other approach is to query Ribbon properties every time a value is needed. Which required conversion of native types into COM variant types and back. Not that this strange dance is unavoidable - just trying to lessen the bulkiness of the COM interface.

I'm doing a similar thing with the command handlers, where I partition the Id space to eliminate having multiple handlers - there is never a need for more than one. We will have to see how it works out in the long run - could even collapse and merge interfaces to a more extreme degree.

The demo application I have in mind is just one that displays the message passing between the GUI and parent application. We are getting there - just very slowly...

crashed when I clicked the font- drop-down list.

I wouldn't use anything in this thread. Ribbon in a dialog is buggy.

Here you go.

Ha. I'm not executing that on my PC.

Don't have time to even run it on VirtualBox... Plus has weird name that suggests something....

I'm too smart for clicks

Hi bitRAKE,

How difficult would it be to make this run on 32-bit Windows?

It would be easier to rewrite the whole thing. The calling convention is intertwined with the COM conventions - making the code virtually un-reuseable. There was some conscious consideration initially to have that kind of flexibility. In practice greater abstractions would be needed.

Like using PTR to abstract out DD/DQ, and PTR? for RD/RQ. GUIDs are the same and error codes. Yet, anything else is rather instruction specific. Since I haven't used the 'comcall' macro it would be completely different.