RibbonName property not exported for Forms or Reports (for ribbons loaded via LoadCustomUI only?)

[mwolfe02]

This is a "bug" in Access.

If you assign a custom RibbonName to a form or report object, that property does not get saved to text when the object is exported.

Since it does not get saved to the exported text file, it does not get imported when building from source.

Hence, any application with custom contextual (i.e., form- or report-specific) ribbons cannot reliably be managed with the VCS add-in since the export/import cycle will fail to faithfully recreate those affected objects.

While this appears to be a "bug" in Access, the SaveAsText method is not documented. Which means it's not officially supported. Which means we can't expect Microsoft to fix it.

---

IMPORTANT NOTE: I am using the LoadCustomUI() method rather than the USysRibbons table to load runtime-generated ribbon XML at application startup. It's possible that Access is looking for the ribbon name in the USysRibbons table before including it in the export. If that's the case, others may have trouble reproducing this issue. If the issue is the way I'm building and populating my custom ribbons, then I can write custom AfterExport and AfterBuild procedures to handle the situation.

Is this an issue for others or is it because of how I'm building my custom ribbons?

[joyfullservice]

I don't personally have experience with loading form ribbons through LoadCustomUI(), but I am curious about this issue from the context of the add-in supporting the export and build of custom ribbons.

When you load a custom ribbon through code, is the ribbon persisted on the form between database restarts? Does it persist through a compact and repair? How about if you import the form into another database, does the custom ribbon come with it? (Perhaps testing with and without the USysRibbons table in the source and destination databases. If a USysRibbons table exists in the database, (even if it's not used by this form) does that make a difference in the export?

There are a few ways that we could potentially handle this, but it would be helpful to verify the behavior of Access in these various scenarios. If this is a run-time property we can test, we could potentially create a temporary USysRibbons table during the export process, or we could store this data in form.json like we do the print settings. Another approach could be to save the ribbon as form.xml or form.ribbon.xml and load it back in through LoadCustomUI() during build.

[mwolfe02]

The ribbon XML string is generated at application startup and loaded via LoadCustomUI(). That all works fine.

The issue I'm seeing is that when I do a SaveAsText() on a form with the RibbonName property set, that setting does not get exported to the text file. I have not yet tested whether that setting never gets exported or if Access is choosing not to export the setting because there is no corresponding entry in the USysRibbons table (similar to how Access will clear the [Event Procedure] setting if there is no corresponding code in the code behind when you save a form object).

You can hold off on doing anything with this until I get a chance to test that behavior (probably won't be for at least a few days).

[mwolfe02]

I went ahead and created an entry in the USysRibbons table to use the more conventional approach to creating and using ribbons. The SaveAsText() method still does not include the RibbonName as part of the export.

Seems like the most straightforward approach would be to include the RibbonName as part of the form or report's associated .json file and then manually set the property on import if it exists in the .json.

That should also be the easiest approach to generalize if we come across additional form or report properties that are not included in the SaveAsText() or LoadFromText() procedures.

[joyfullservice]

I agree. Including this property in the *.json file would be a logical place for this. I will just need to adjust some things on the code side to expand the purpose of the `*.json file to more than just print settings and ensure that it is created and removed appropriately.