IDBE Ribbon Creator does not have a way enter OnAction for dropdowns for Access

Thanks, Ste5an!

Some follow-up questions:

A.)  Your wrote:
Thus you need to evaluate the value in your action handler, which must have the following signature:

Public Sub DropDownOnAction(control As IRibbonControl,selectedId As String, selectedIndex As Integer)
End Sub

Select allOpen in new window

Does this proc only need to be processed once or once for each pulldown SeletedID?

B.) GA is the startup icon for IDBE. When I open the application, after I select the database, it asks which ribbon? I assume it must read each table in USysRibbons  but I am unsure

C.) Regarding item #7, I plan to have the Developer selection password-protected so that I can get into the application without the custom ribbon and do whatever tasks that I may need to do. So, I want to be able to have the custom ribbon "disappear" or the standard ribbon somehow appear also - just for me. When I finish my work, the custom ribbon would reappear. I was thinking that a form could be presented after password checking with the "standard ribbon" define for the ribbon of that "developer's" form. Does the standard ribbon have a "name" or is it a system default? Otherwise, I might have to build a custom ribbon that has the features of the "Standard Ribbon" in the Options -> customize ribbon, since we can have multiple ribbons as you validated in #8.

D.) Re: #6, I want the company to be licensed since I am simply a temporary contractor and do not want IDBE to lose a sale because all applications change over time.

BTW, you are brilliant!

Thanks!

A) This is the handler. The code should be in the callbacks.txt. Every time you change the drop-down, that handler is called. It is called once per change. (Untested) In the case of a multiselect it should be only called once.

B) Don't have it at hands. But affair you can select an existing one, which is read from USysRibbons of the loaded database or it is the name for a new one.

C) General development strategy:
You work always on your development database.
For deployment, you copy that version and adjust it. Like making it an .accde. Here you also activate your ribbion as default ribbon.
In the case of a replacement ribbon, I would use two ribbons. The replacement ribbon and the same without replacement (aka development ribbion). The code and the callbacks are not affected by this. Remove the development ribbion in the deployed version.

Thanks Ste5an for the guidance.

I have been developing software for over 51 years. I keep 'versioning' each new elevation to production. I take the production version and move it to development, increment the version number in development, pass it to UAT for approval and then elevate the approved UAT version to production. I stopped keeping "old" development versions to start upgrades/enhancements/fixes because the "development" version may not necessarily be the version to reach production - especially when there are multiple developers.

Doing Access since 97, my humble opinion:

Sometimes you creating the production/test version of an Access database includes irreversible steps. Like creating an .accde.
Thus the true source is in the development version, from which your have created your test and production version.
Obviously you need a way to keep track of that. I use source control (SVN) for the binary.

In the case of multiple developers, how do you keep track of the current state of work? There should be one development master where all the changes are merged into.
This development master copy is the true actual version, when tagged that a test/production version was derived from.

I understand your point and it is well-taken. It is probably my terminology rather than a disagreement in approach. Just like "sandbox". <grin>

Each developer would take on a change to elevate to UAT and then to Prod. No concurrent coding. All consecutive. Sometimes these changes are months apart. The Prod version is then turned into an .accde and retained as an .accdb.

The particular version number is stored in a table in the data database and in a table in the program database. These table values appear in the "About" form and at the top of the main form. It has two text constants: "Data Version xx.xx.xx" and the other is "Program Version: xx.xx.xx". These table values are also reported in automated emails to the development team when errors are raised. The error reporting email reports the data and program versions, system variables, the error number, error description and the offending procedure.

The approach may not be perfect but it has worked for me.

Thanks for your concern and your counsel!
Lenny

Hi Ste5an,

Sorry to be a pest.

Where is callbacks.txt stored? Does the text file have to be resident in the same directory as the accdb?

You made a mention that a change to code need to be in callbacks.txt also. This is my first Access ribbon and I am worried that I can trash all of my design work in the prototype.

I was in RibbonXML.txt and started to make the changes that you had suggested but I chickened-out. <blush>

Could I impose upon you to have you change RibbonXML.txt and callbacks.txt to implement just one OnAction callback code so that I can mimic it for all of the data files and reports that are in the drop downs? The OnAction for AreaMaintenanceEngineer is a proc: Public Sub AreaMaintenanceEngineer_CF_Data()

Thanks, in advance, for your patience.

Lenny