This option (on by default) will save the VBA code from forms and reports as a related .cls file. (Still under development.) #378

Also removed the "Strip out Publish Option" from the options form. I have never heard of a case where this needs to be changed, and it frees up space for the new option we are adding without cluttering the form.

This logic will be shared when exporting code modules from forms and reports.

Refactored parsing the key from the performance item so that we are not dependent upon a unique delimiter. The timing value is always a number, so we can be confident that the first pipe character is the delimiter. The text after that can be anything, including pipe characters. #450

(minor change)

In some cases sanitizing a source file actually creates two distinct outputs. A layout file and a code file. Rather than making the sanitize function more complicated with byref outputs and non-obvious side effects, I am taking the approach of a more explicit object-oriented route where the code is easier to understand and maintain. (And also allows for future enhancements such as SQL extraction for query definition files.)

Updating the existing code to use the new class.

Export is now splitting the VBA from Form and Report objects to separate files with a .cls extension. Moving on to the code that will stitch these files back together before import.

This better reflects the expanded role of the class.

Ensure that the ribbon is active when installing or activating the add-in. See #451

For existing projects in git repositories, form and report layouts should not be automatically split from the VBA code classes. There is another process that will allow us to split the files while preserving history in both files, but this involves a couple commits and requires a clean branch. For existing projects, this is a manual upgrade (option changes). For new projects, it can happen by default.

This keeps the LoadComponentFromText function cleaner and easier to read.

This is used in several areas, and allows us to maintain the source file encoding determination in a single location.

Cleaning this up to avoid reading and writing the file additional times while merging content from different sources. (Print settings, VBA code)

For some (rare) situations, it is necessary to push the VBA code directly using VBE to preserve certain extended characters that may be corrupted in a regular round-trip export/import cycle.

Uncovered these while testing.

replace VBA commands:
format with format$
trim with trim$

Describes the process in a little more detail.

…e/msaccess-vcs-addin into SplitLayoutFromVBA

Used for special processing when certain options change.

Adds a link and some code automation to split forms and reports in existing projects to layout and class files.

Git.Installed sounds better than Git.GitInstalled, and will almost always be called in the context of the git class.

From @hecon5:

Bump version minor number because it's not clear that the index will allow round trip from prior types in all cases; it worked on my machine, but that may not always be the case.

The date types for the index are handled natively by modJsonConverter and should import/export correctly regardless of user's date / time zone or date encoding on machines.

See #354

Avoids the use of RegEx when it is not necessary to parse a standard date format. #354

#354

Refactored a number of locations to use the new syntax for On Error Resume Next, and added code to clear expected errors.

Also added an informational message box when the split is complete.

Separates the VBA code from the layout definition in the source files. (Applying to testing database now, will apply to main project soon.)

I am using the minor version number to represent releases from the main branch, and the build number to continuously increment during the development cycle.