AutoClose feature: do not close form automatically if started by button click

[josef-poetzl]

Do not close the form automatically if the export was started manually by clicking the button in main form.

Examples:

Start by button click in main form

1. User open Add-in (click on ribbon 'Open Add-in')
2. Click on button 'Export All Source' in form
3. Form should stay open

Start by ribbon control

1. User click on ribbon control 'Export Source Files'
2. Form should auto close if no errors

My code modification: https://github.com/josef-poetzl/msaccess-vcs-addin/commit/f087b0f5e03222ed7c8f7a512873e340828c24da

[hecon5]

Hmm, my initial thought was to copy @josef-poetzl code, but the form code is pretty dramatically different from what he's got.

The way the export from the ribbon is handled, the external objects click the buttons (clsVersionControl.RunExport initiates frmVCSMain.cmdExport_Click), which from my initial testing is indistinguishable from a direct button click.

Perhaps another way to handle this is to detect if the form was already open prior to RunExport being initiated and close the form only if it wasn't already open.

I took a stab at it, PR should be incoming soon.

[josef-poetzl]

Public FormOpenedExternally As Boolean ' Set True externally when opened by other entity.

I think intercepting the click on the button is simpler and easier to understand in the code.

but the form code is pretty dramatically different from what he's got.

You can do a cherry pick with shown commit.

Now prepared for main: https://github.com/josef-poetzl/msaccess-vcs-addin/tree/main-503 or for dev: https://github.com/josef-poetzl/msaccess-vcs-addin/tree/dev-503

clsVersionControl.RunExport initiates frmVCSMain.cmdExport_Click ... which from my initial testing is indistinguishable from a direct button click.

However, one could discuss whether it is good programming style to call an event handler. ;-)

[joyfullservice]

Do not close the form automatically if the export was started manually by clicking the button in main form.

This should be the current behavior in the latest dev builds... Here is my rationale behind it:

(A.) If I click the button on the ribbon to Export Source, I am looking for a one-click operation, with no additional actions or mouse clicks required to export the latest changes to source. If no errors were encountered, the form should auto-close and I can move on in my development work without breaking my concentration or mental flow.

(B.) If I Open Add-in first, then I am likely taking a bit more of a considered approach to the desired operation. Perhaps I am running the add-in for the first time, and I don't want it to disappear without warning before I have time to read and digest the output display. Or maybe the project is set to only export changed items, but I want to do a full export anyway. If I am using a second click to initiate the operation, then I probably won't mind a third click to close the form when I am finished.

@josef-poetzl - Is this not working for you after building off the dev branch? I think what you described in the first post on this issue is how it should be working... 😄

On the technical side, the ribbon button clicks are proxied to methods in the clsVersionControl class. (After trimming off the first three character prefix, the button name matches the method name in the VCS class.)

Opening the add-in simply opens the form.

'---------------------------------------------------------------------------------------
' Procedure : Show
' Author    : Adam Waller
' Date      : 1/13/2021
' Purpose   : Show the Version Control System main form
'---------------------------------------------------------------------------------------
'
Public Sub Show()
    DoCmd.OpenForm "frmVCSMain"
End Sub

Export Source Files opens a hidden instance, sets a few things, then clicks the button to export. Note that the auto-close is handled here in the VCS class, not at the form level. That's how we can have autoclose trigger for scenario (A.) but not scenario (B.).

'---------------------------------------------------------------------------------------
' Procedure : RunExport
' Author    : Adam Waller
' Date      : 4/1/2022
' Purpose   : Handle different kinds of exports based on filter
'---------------------------------------------------------------------------------------
'
Private Sub RunExport(Optional intFilter As eContainerFilter = ecfAllObjects, Optional objItem As AccessObject)
    DoCmd.OpenForm "frmVCSMain", , , , , acHidden
    With Form_frmVCSMain
        If objItem Is Nothing Then
            .intContainerFilter = intFilter
        Else
            Set .objSingleObject = objItem
        End If
        .Visible = True
        .cmdExport_Click
        If Log.ErrorLevel < eelError Then .AutoClose
    End With
End Sub

Hopefully this helps clear up some of the details on how this was intended to work...

[josef-poetzl]

A + B: That's exactly how I imagine it. :)

Is this not working for you after building off the dev branch? I think what you described in the first post on this issue is how it should be working... 😄

Good question :) Tested again: new build from source (explicity DEV :)) => form stay open when used Open Add-in. What did I test the other day ... maybe mixed up with main?

Sorry for the confusion. :)

You fixed it before I write the issue. :) :)

[hecon5]

I'd like to request this is re-opened. I found a few cases where the form does automatically close.

Reproduction steps:

1. Open AddIn.
2. (From ribbon) export source files. You can also run single object export, or whatever from the ribbon, too. It leads to same result.
3. Export runs.
4. Addin window closes.

It turns out that the way the form is referenced in the addin is the culprit; each module seems to load it separately. This led me to a red-herring approach when I tried this the first time and clsVersionControl.OpenVCSMainForm.

I think the "right" approach here is to have a form handler routine that manages the open methods and references. This allows us to ensure the "correct" flags are set regardless of the entry point; this also forces a single reference and if we need separate instances of the form open, we can handle that, too.

Regardless, the form still seems to close when you have it open and then run an action from the ribbon.

[joyfullservice]

@hecon5 - I think what you are describing here is actually a different issue. The example you gave is a case where a second operation is initiated before the first one has completed. This is not the way the add-in was designed to work, and could create all kinds of issues where one process hijacks another process mid-stream.

It is probably a good idea to check for any for any existing form instances before allowing a new ribbon command to execute, but again, this is a different scenario, and probably deserves its own dedicated issue. Thanks for pointing that out!