Option to export form files using a frm extension (and add a project-like file)

[mdell-seradex]

Can form files be exported using the more recognized "frm" file extension, instead of the "bas" extension?
I understand that they may not exactly fit the format for some applications, like VB6, but I don't think that matters, as extensions are often used for multiple things.

I was also thinking if there should be some sort of "project" file (like a vbp or vbproj/csproj file) that references the other files, but I have no idea what that would look like. Actually, it looks like it may already exist as "vcs-index.json", but the name doesn't really indicate that this is what it is. When I had a quick look at it, I was unsure if it clearly defines the folder structure, and includes all the files that are dynamically created (ones that are there for every db could be excluded), but it does seem to fit this concept. If you think this is worth some effort, it can be split to a new issue, perhaps as an option.

[hecon5]

I think you're looking for vcs-options.json, it has all the VCS build options set there. There's also vbe-project.json which contains information about the database file (specifically the VBA project in the database). Check out https://github.com/joyfullservice/msaccess-vcs-addin/wiki/Export-Import-File-Types for more details.

VCS-index.json is actually an index of files and their hash, and is largely used to identify changes in the database (or codebase) when building or exporting to significantly speed up the operations as the addin skips files and items which match the hash. Hashing is significantly faster (orders of magnitude so) over export/building. If you deleted it, it would change nothing, except take a bit longer on the next import/export, after which it'd be rebuilt.

Can form files be exported using the more recognized "frm" file extension, instead of the "bas" extension?

I've often thought that, too. It would make it more 'obvious', however, it comes with some downsides, especially if you have a significant code history. There's also the issue that to build a form (or report), there is potentially up to 3 files with different components: the .bas file contains the look / buttons/fields/objects in the form, the .cls contains the code behind the form (if you're using split form feature), and a .json file which contains print settings (mostly for reports, but can be part of forms as well). There's also the fact that RubberDuckVBA exports VB forms as .frm and it would confuse that quite a bit if someone did try to import a frm from this tool (or vice versa).

The other thing which should be considered is how much work it is to change the extension, as it's used quite extensively in the code (code inertia) vs utility.

TL/DR: I agree in principle, but I'm not sure if the utility of having the extension have a .frm extension outweighs the work it takes, and the downsides for long-term users.

[mdell-seradex]

I think you're looking for vcs-options.json

No. VCS-index.json is the correct file that I was thinking of as it has the list of files that were exported, similar to how traditional project type files (.vbp, .vbproj, .csproj) contain a list of files in the project. Technically traditional project files contain more than just a list of files. It also contains settings, like those that you mentioned in vcs-options.json and vbe-project.json. Note that I am not talking about the newer .csproj type (SDK style) where it assumes/guesses the files that are supposed to be included. I personally dislike most things that make assumptions.

downsides for long-term users

That is why I suggested having an option for this. Current users could keep the same way, and new users could choose to identify them as "frm" files.

There's also the fact that RubberDuckVBA exports VB forms as .frm ... try to import a frm from this

Yes, however VB6 saves Forms with the .frm extension. I suspect that if someone tried to import a VB6 form, that it also wouldn't work well. I don't really see that as an issue. Many applications have .cfg files, for instance, and they are not interchangable.

split form feature

I noticed this, and thought I saw an instance of this once, but it stopped working for me. I have now determined that this is ignored if Sanitize is Off.

[hecon5]

Yes, however VB6 saves Forms with the .frm extension.

Correct, which import correctly in the VBIDE in other than Access Office products.

I have now determined that this is ignored if Sanitize is Off.

Correct, the sanitize functions are part of the splitting process.

Out of curiosity: why are you not using sanitization? Even with the maximum sanitization level, it's almost a certainty the removed "code" is noise. With minimal sanitization only well - vetted noise is removed (aka: there's almost no chance what is exported won't build identically on import).

[mdell-seradex]

I am new to this and wasn't sure what sanitize would do. I figured that it was safer in my case to turn that off since I was using it to compare two versions of the same file where each should have minimal changes.

the sanitize functions are part of the splitting process

I was not aware. It seems like a bug because it is still enabled and checked when sanitize is turned off.

import correctly in the VBIDE in other than Access Office products

I am not sure that I understand what you mean. VB6 uses controls (built-in combobox, listbox, etc.) that are not available in Access. Also, based on my cursory review vs my memory, it appears that there are differences between your files and VB6 frm files.

[hecon5]

I figured that it was safer in my case to turn that off since I was using it to compare two versions of the same file where each should have minimal changes.

Totally get it! That's where I started, too. We've spent a lot of time validating that the sanitize functions do not remove code that has any actual effect on the round trip rebuild (aka: will the export, import build process build the same database). In fact, I don't use the maximum sanitize on some projects. Which is where the ask came in.

Especially if you're just comparing two files, I'd turn on (and up) sanitize, because the bulk of differences are going to be noise.

I was not aware. It seems like a bug because it is still enabled and checked when sanitize is turned off.

Hmmm, I didn't think of it that way. That's a good point and one we should address on the ux.

...what you mean

Basically exactly what you said, but you can use forms on Office products in Excel ("other than Access"). You are correct, there are differences:)

[mdell-seradex]

I think we are basically on the same track.

My thought was that using ".frm" was more natural, and the fact that this extension is used by other products is irrelevant, especially for anyone that chooses to export using that extension.
I do see now that when split mode is used, the form's code exports as cls files which I believe is the default when manually exporting.

Of course, these are just my ideas that may improve the use for some people. It is up to your team if you want to implement any of them.