WklRibbon

The ribbon designer of the WKL Forms Object Library: the ribbons of a database, its File view and its context menus, made from one list of commands and run without callback code of your own.

• Give an application its own ribbon

• How to: Show commands only in development
• How to: Control the ribbon from code
• How to: Use the ribbon's commands in a context menu
• How to: Assign context menus to forms, reports and controls
• How to: Take over a ribbon written by hand

+ File  + Home  + Reports ------------------------------------------------------------+
|       | +---------+ # Open only    +--------+                                      |  1
|       | |Customers| # Export v     | Report | v                                    |
|       | +---------+                +--------+                                      |
|       |         Data                     Print           Tools (DEV only)  2       |
+-------+----------------------------------------------------------------------------+
   3 File view: Modules › Customers, Orders, Sign Out     4 Context menu ctxCustomers

• One command, many places. A command has its label, image (an Office image or one of the database's image gallery), action and condition once; buttons, menu entries, tasks of the File view and context menu entries show it.
• Actions without code. Open a form, open a report in print preview, call a function of the application, or run a built-in command of Access by its idMso. The event Action comes first and can cancel.
• Conditions. Show an element only in a profile (DEV, TEST, PROD), only in an ACCDB, ACCDE or the runtime, or only when a function of the application returns True (roles, rights, states). Conditions decide what is shown, not what is allowed: a hidden command can still be reached through VBA, DAO or another front end. Protect data with the rights of the server.
• Context menus assigned in one place. The page Zuordnung decides which form, report, control or kind of control shows which context menu; after OK the menus are written into Shortcut Menu Bar, by the build tool as well. EnsureMenus makes the menus in a database without a ribbon of the model.
• Control from code. Visible, Enabled, Label and Pressed per command, Invalidate, ActivateTab, Execute.
• From text sources. The model is a JSON text the build tool builds from and exports again, byte for byte (ribbonModel in access-app.json).
• Like Access. Ribbons stay in USysRibbons and CustomRibbonID, form ribbons are named in the form's Ribbon Name property, context menus in Shortcut Menu Bar. ACCDE and runtime work.

The model is a model of the framework's core: commands, ribbons, the File view and context menus, with rules that hold before anything is written (unique names, no element where RibbonX does not allow it, no reference to a missing command) and the generation of RibbonXML and of the callback module. Saving writes the model into USysWklRibbon, every ribbon into USysRibbons, the application ribbon into CustomRibbonID and the callbacks into the module basWklRibbon, which you never edit. Every element asks its label, visibility and readiness through that module; the module passes the question to the runtime object WklRibbon, which evaluates the conditions and the values set by code. Context menus are command bars the runtime makes whenever a ribbon of the database loads, or when the application calls EnsureMenus. Their assignments are part of the model and are written into the forms and reports in design view, so an ACCDE made afterwards keeps them. Access applies a saved ribbon when the database opens.

• How to: Install the released package
• How to: Deploy an application with WKL controls to user PCs
• What the per-user registration writes

• The ribbon doesn't appear after saving

• API reference: WklRibbon
• access-app.json reference (ribbonModel)

None