joyfullservice / msaccess-vcs-addin

Synchronize your Access Forms, Macros, Modules, Queries, Reports, and more with a version control system.
Other
215 stars 40 forks source link

VCS 4.0.34 Data Macros not exported when using Export Selected from the ribbon on a table #492

Open arpm-awv opened 8 months ago

arpm-awv commented 8 months ago

Using VCS 4.0.34 If I select a table that I have just updated the data macro (After Update in this case), then use the Export Selected button on the Version Control ribbon, the data macro is not exported.

Opening the add-in and running Export All Source does export the data macro.

joyfullservice commented 8 months ago

Great question! Right now, it just exports the primary component type that was selected. You can see the mapping for this in the following function:

'---------------------------------------------------------------------------------------
' Procedure : GetClassFromObject
' Author    : Adam Waller
' Date      : 2/22/2023
' Purpose   : Returns a database component class from a database object. (Used when
'           : exporting a single object.)
'           : Note that not all component types are supported.
'---------------------------------------------------------------------------------------
'
Public Function GetClassFromObject(objItem As AccessObject) As IDbComponent

    Dim cItem As IDbComponent

    ' Map to correct component class
    Select Case objItem.Type
        Case acForm:    Set cItem = New clsDbForm
        Case acMacro:   Set cItem = New clsDbMacro
        Case acModule:  Set cItem = New clsDbModule
        Case acQuery:   Set cItem = New clsDbQuery
        Case acReport:  Set cItem = New clsDbReport
        Case acTable:   Set cItem = New clsDbTableDef
        Case Else
            ' Not currently supported
    End Select

    ' Set database item and return class instance
    If Not cItem Is Nothing Then
        Set cItem.DbObject = objItem
        Set GetClassFromObject = cItem
    End If

End Function

However, as you encountered here, there are some underlying component types that also come from the same parent object. For example, a table exports the TableDef object definition, but it could also involve table data, table data macros, hidden attribute, or document properties.

To support this use case, we would need to refactor this function to return a collection of component classes, and then iterate through each of the classes during the export. That would provide a more comprehensive export when selecting a single component.

For what it's worth, in my personal development practices, I hardly ever export a single object. With fast save turned on (exporting only changed items), it takes less than a second to scan for changes and export any changed objects. I just click the button to Export Source Files and then I review the changes in GitHub Desktop. This lets me easily select what I want included or excluded from the next commit.

I am interested in hearing more about the cases where you find it helpful to export a single object.

arpm-awv commented 8 months ago

It isn't the time that it takes, it's the noise. If I modified a single object, I only need to export that object. If I export changed items (even with fast save turned on) I end up with a large commit containing unrelated objects.

After modifying this table data macro, and finding that exporting a single object didn't export the macro, I exported changed items. This resulted in a commit with dozens of unrelated objects included.

joyfullservice commented 8 months ago

Thanks, that is some helpful context. Where do you typically see the noise? There are three main areas where I encounter unrelated "changes":

You can also play with the options in the sanitize levels to see if that helps reduce unwanted noise.

Just to be clear, there is nothing wrong with exporting individual objects as you are doing. I am just wanting to make sure there is not a way to easily resolve the underlying noise issue to help streamline your process. 😄

arpm-awv commented 8 months ago

This particular case was complicated by a VCS upgrade as you noted. This was a backend database that I rarely have to modify. I see it more often on front ends, which is how I came to be in the habit of using it. I can't account for the reason in most cases.

arpm-awv commented 8 months ago

image

For some reason I'm seeing a lot of this kind of noise. It randomly changes the case of some of my variable names. Not sure if it happened when I built or when I exported.

joyfullservice commented 8 months ago

For some reason I'm seeing a lot of this kind of noise. It randomly changes the case of some of my variable names. Not sure if it happened when I built or when I exported.

This is a common issue with the VBA IDE if you are using naming conventions other than PascalCase. Mike Wolfe has a great article on this. It is also mentioned in the FAQ page for this add-in.

Personally, I use the more traditional naming conventions and PascalCase, and virtually never run into this issue. (Other than times when I find myself inconsistent, like using strSQL in one place, and strSql in another place. 😄

hecon5 commented 1 month ago

@joyfullservice @arpm-awv is this still an issue / desired feature? If not, can you close it?

arpm-awv commented 1 month ago

I'm still on 4.0.34. To avoid the issue, I've been doing complete exports and living with the noise.

The extra commits are sometimes changing a variable to uppercase, sometimes to lower. But there are other changes too, width of a column, filter/sort settings, hidden properties... image

I don't know if the issue has been fixed.

joyfullservice commented 1 month ago

Case changes are a known limitation of the VBA IDE, not specifically related to this add-in. Mike Wolfe's blog post mentioned above explains some tips on how to work with this.

Changes like column widths, filter/sort settings are legitimate changes to objects and are rightly reflected as such in the source code. If there is something specific that is creating "noise" that shouldn't be, we can open a separate issue for that.

In regards to the original issue of exporting potentially related component types, I don't mind leaving this out there as a low-priority enhancement idea, but I am not sure it would be used enough to justify investing a lot of time into it.