[AccessD] A diff program for Access?

[Rocky Smolin]

Arthur:

I have the old mdbdiff program which works on mdb files and works well on
tables but does not do code.  I  can send it to you if you like.

I really miss Fisher's Find and Replace. That program was a gem. I used it
a lot back in the day and could have used it this year looking for
occurrences of something across all objects. But, he's gone and my copy of
F&R stopped working.

Finding subs and functions never called is easy - just do a global find in
the VBA editor of the sub or function name.  If it doesn't appear anywhere,
delete it.

I agree with you about passing parameters to a called form versus grabbing
the needed value from an open form. So now I use code:

    DoCmd.OpenForm "frmActivityComments", , , , , , Me.fldMAID

where fldMAID is a Marketing Activity, and form frmActivityComments is a
table of comments associated with the marketing activity.

in frmActivityComments the open event has the lines:

    Me.Filter = "fldMAID = " & Val(Me.OpenArgs)
    Me.FilterOn = True

to set a filter in the called form.

Or to find a specific record:

    If Not IsNull(Me.OpenArgs) Then
        Me.RecordsetClone.FindFirst "fldDiscussionLeaderID = " &
Val(Me.OpenArgs)
        Me.Bookmark = Me.RecordsetClone.Bookmark
    End If

I began using this approach when I found that a form in my app could be
called from more than one place. So instead of using the IsOpen function to
find out which form it was, I instituted a polocy of always passing the
parameter of the record or the filter from the calling form.

r
On Fri, Nov 12, 2021 at 6:27 AM Arthur Fuller <fuller.artful at gmail.com>
wrote:

> I don't suppose there exists such a thing, but who knows, there may be. I
> want to determine the differences down to every level between App A and App
> B. Is there a tool that can do that, or am I forced to walk hand by hand
> through  hundreds of modules, forms, queries and reports.
> This app has grown gargantuan over the years, and this is a very bad thing.
>
> Perhaps the first thing I need to do is identify all the "dead code" -- old
> subs and functions never called in the current implementation
>
> Next, I want to employ a technique I learned from Jim Dettman: forget the
> behemoth app model and instead create Microservices that do one thing, such
> as deliver a report. On occasion, this is not trivial: Access seduces you
> into thinking that reference to some open form are cool. I most
> emphatically disagree. If a Report needs parameters, then pass them, or
> alternatively refer to the return values of Static Functions.
> I think that I may be going against the stream here. So be it. I like to
> use the Access Wizards to create the basic code, but immeiately after that
> I separate the generated code for the button from the button itself,
> creating a new sub or function and changing the btton code to cal that Sub
> or Function. as a result, al the form/button-clicks are reduced to one line
> of code, not dependent upon the form whose buutton invokes a local event.
> NOT my way of coding. I choose to ship everything possible away frrom the
> form and refereences to its avlaue, and eventually all the code away from
> the form into a module that I can call from anywhere, given expected
> parameters.
>
> --
> Arthur
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> https://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>