search

rubberduck-vba / Rubberduck

Every programmer needs a rubberduck. COM add-in for the VBA & VB6 IDE (VBE).
https://rubberduckvba.com
GNU General Public License v3.0
1.92k stars 302 forks source link

Access specific code to Import/Export forms for SC #3360

Open daFreeMan opened 7 years ago

daFreeMan commented 7 years ago

For Access, Application.SaveToText and Application.LoadFromText should be added to the Source Control code to export and import all user forms.

bclothier commented 7 years ago

Be aware that there are elements contained that are not necessarily desirable for SC. This is off the top of my mind, so don't take it as gospel; some research needed:

1) Version which can limit whether it will be imported or not 2) Checksum which seems like a good thing but IIRC, may be changed without changing anything else and possibly block import 3) NameMap this is from the ~AutoCorrupt~ AutoCorrect feature and is not really needed in SC.

I'm sure there's few more but the point is that it might be desirable to be able to sanitize some of the elements that don't fit SC paradigm terribly well.

ThunderFrame commented 7 years ago

What if we treat the Access format as an intermediary format - but instead of stripping out or tolerating the undesirable base64 encoded binary blobs, we instead convert that format to a more source-control-friendly format, where the blobs are saved as binary files, and they're referenced by an RD-defined text-only format?

If the blob is a picture, the picture could be saved as a BMP/EMF/GIF/etc, and source control tools like GitHub could show the differences.

We could use a common text-only format (along with referenced binary objects) for Access forms/reports, but also for deserialized UserForms. It would require that RD be installed to do the conversion/serialization/deserialization between the VBE and SC.

retailcoder commented 7 years ago

@ThunderFrame would we not want that separation of resources for .frx as well then?

ThunderFrame commented 7 years ago

@retailcoder yeah, that's why I'm suggesting a common format. If a userform has a background image, then we should deserialize the FRX into text, and refer to the BMP/EMF/GIG as a resource.

bclothier commented 7 years ago

FWIW - if they are embedding image in an Access object, that's an inspection for not using the shared gallery.

That said I like the image of storing the BLOBs separately to support better diff. That would help in the cases where we can't even diff (e.g. the PtrDev stuff) without necessarily polluting the commits just because they have different printers.

daFreeMan commented 5 years ago

Since we're not doing SC anymore, should this be closed as "N/A"?

Vogel612 commented 5 years ago

@daFreeMan We're not doing integrated SC, but that doesn't mean we don't want to implement features that help our users to do non-integrated SC

Imh0t3b commented 5 years ago

@Vogel612 I just thought about to create that issue,. as I tried the export and noticed there is only vba code. Can you estimate difficullty and needed effort?

If we implement this we create an option for Access to replace the whole export with Application.SaveAsText?

Vogel612 commented 5 years ago

Sorry, that's definitely not my area of expertise. Pinging @bclothier for opinions.

bclothier commented 5 years ago

I suppose it can be here to the IHostApplication interface. We do have some special cases for Access as you can see here. But keep in mind that this has to be abstracted away for all hosts. Example can be seen here. This is to ensure we do not pollute codebase with special edge cases over all the places, even if its needed by only one. Obviously that costs something.

That said, a PR on this would be welcome as long it conforms for all hosts.