Unexplained Exit of Access

[NeoPa]

I have form which handles Shift-Esc by calling a close of the form (See line #6 below).

Private Sub Form_KeyDown(KeyCode As Integer, Shift As Integer)
    If (Shift And acShiftMask) <> acShiftMask Then Exit Sub
    On Error Resume Next
    Select Case KeyCode
    Case vbKeyEscape
        Call DoCmd.Close
    Case vbKeyUp
        Call DoCmd.GoToRecord(Record:=acPrevious)
    Case vbKeyDown
        Call DoCmd.GoToRecord(Record:=acNext)
    End Select
End Sub

Although identical code works fine from my cmdExit button, whenever this executes (from within the KeyDown event procedure) it causes the application (Access) to exit completely.

I'd be interested to hear of anything that can throw any light on the matter.

Running Access 2000 on Windows 2000 Server.

[missinglinq]

Don't know what to tell you, Ade, it works as advertised for me! I can only duplicate the behavior by putting DoCmd.Quit in the form's Form_Close event.

Sorry!

Linq ;0)>

[FishVal]

Hi, Adrian.

It is really weird. I have only a couple of guesses.

• did you try to explicitely pass form name as argument to DoCmd.Close method?
• is there any code in OnClose event handler?
• in step mode, does Access crash immediately after executing DoCmd.Close?
• what will happen if you disable error trapping?

Regards,
Fish

[ADezii]

I have form which handles Shift-Esc by calling a close of the form (See line #6 below).

Private Sub Form_KeyDown(KeyCode As Integer, Shift As Integer)
    If (Shift And acShiftMask) <> acShiftMask Then Exit Sub
    On Error Resume Next
    Select Case KeyCode
    Case vbKeyEscape
        Call DoCmd.Close
    Case vbKeyUp
        Call DoCmd.GoToRecord(Record:=acPrevious)
    Case vbKeyDown
        Call DoCmd.GoToRecord(Record:=acNext)
    End Select
End Sub

Although identical code works fine from my cmdExit button, whenever this executes (from within the KeyDown event procedure) it causes the application (Access) to exit completely.

I'd be interested to hear of anything that can throw any light on the matter.

Running Access 2000 on Windows 2000 Server.

Hello NeoPa, like our esteemed colleague linq has stated - It works as advertised for me! I am leaning along the lines of our other esteemed colleague, FishVal in that although the code works as intended, the Unload(), Deactivate(), and Close() Events of the Form are obviously fired in that sequence. Anything in either one of those Events that cause cause an Exit from Access?

[ADezii]

I have form which handles Shift-Esc by calling a close of the form (See line #6 below).

Private Sub Form_KeyDown(KeyCode As Integer, Shift As Integer)
    If (Shift And acShiftMask) <> acShiftMask Then Exit Sub
    On Error Resume Next
    Select Case KeyCode
    Case vbKeyEscape
        Call DoCmd.Close
    Case vbKeyUp
        Call DoCmd.GoToRecord(Record:=acPrevious)
    Case vbKeyDown
        Call DoCmd.GoToRecord(Record:=acNext)
    End Select
End Sub

Although identical code works fine from my cmdExit button, whenever this executes (from within the KeyDown event procedure) it causes the application (Access) to exit completely.

I'd be interested to hear of anything that can throw any light on the matter.

Running Access 2000 on Windows 2000 Server.

Back again, NeoPa. Your gonna love this one. If your SHIFT+ESC sequence is off, namely if you press these Keys almost simultaneously, and it you have the Escape Property of a Command Button with a DoCmd.Quit in its Click() Event, you will exit Access and not just the Form. I know it's far fetched, but you must admit that it is a weird problem. (LOL).

[NeoPa]

Right, I'm a bit limited for time right now (at work) so I'll just say that I will reply in more detail later. I appreciate all of your attention though.

Opening and closing of forms in my database is captured by a generic Form class module. This may well be the root of the problem, but I will explore more later (and post my findings of course).

@ADezii
I don't have that but I do have a similar button that simply closes the form. As it's in "Continuous Forms" mode though, the Escape key is unable to trigger from this. It's actually what I'm trying to reproduce. As I say though, only to close the form.

PS. I'll post the current version of my whole module simply for reference, but the code has changed in the procedure we're talking about.

[NeoPa]

Reference Post:

Option Compare Database
Option Explicit
 
Private strJob As String
Private intOption As Integer
 
Private Sub Form_Open(Cancel As Integer)
    With Me
        strJob = ""
        If .Filter > "" Then strJob = Split(.Filter, "'")(1)
        .Caption = Replace(.Caption, "%J", strJob)
        .lblTitle.Caption = Replace(.lblTitle.Caption, "%J", strJob)
        .txtJob.DefaultValue = "'" & strJob & "'"
        Call SetDefaultStep
    End With
End Sub
 
Private Sub Form_KeyDown(KeyCode As Integer, Shift As Integer)
    If (Shift And acShiftMask) <> acShiftMask Then Exit Sub
    'In case record navigation goes beyond start/end of .Recordset
    On Error Resume Next
    Select Case KeyCode
    Case vbKeyEscape
        Call Me.cmdExit.SetFocus
    Case vbKeyUp
        Call DoCmd.GoToRecord(Record:=acPrevious)
    Case vbKeyDown
        Call DoCmd.GoToRecord(Record:=acNext)
    End Select
End Sub
 
Private Sub Form_AfterInsert()
    Call SetDefaultStep
End Sub
 
Private Sub SetDefaultStep()
    Me.txtStep.DefaultValue = Nz(DMax("[Step]", _
                                      "[tblJobTask]", _
                                      "[Job]='" & strJob & "'"), 0) + 1
End Sub
 
Private Sub cmdSwitch_Click()
    Dim blnOptionA As Boolean
 
    With Me
        blnOptionA = (Not .lblJob.Visible)
        .lblJob.Visible = blnOptionA
        .lblStep.Visible = blnOptionA
        .lblType.Visible = blnOptionA
        .lblTask.Visible = blnOptionA
        .lblMRFrom.Visible = Not blnOptionA
        .lblMRTo.Visible = Not blnOptionA
        .lblMsg.Visible = Not blnOptionA
        .txtJob.Visible = blnOptionA
        .txtStep.Visible = blnOptionA
        .txtType.Visible = blnOptionA
        .txtTask.Visible = blnOptionA
        .txtMRFrom.Visible = Not blnOptionA
        .txtMRTo.Visible = Not blnOptionA
        .txtMsg.Visible = Not blnOptionA
        If blnOptionA Then
            Call .txtStep.SetFocus
        Else
            Call .txtMsg.SetFocus
        End If
    End With
End Sub
 
Private Sub cmdDelete_Click()
    With Me
        If Not IsNull(.txtJob) Then
            'We allow for cancellation by operator
            On Error Resume Next
            Call DoCmd.RunCommand(acCmdDeleteRecord)
            On Error GoTo 0
            Call SetDefaultStep
        End If
        Call .txtStep.SetFocus
    End With
End Sub
 
Private Sub cmdExit_Click()
    Call DoCmd.Close
End Sub
 
Private Sub Form_Close()
    'Method must exist in order for container to handle event.
End Sub

[NeoPa]

...
@ADezii
I don't have that but I do have a similar button that simply closes the form. As it's in "Continuous Forms" mode though, the Escape key is unable to trigger from this. It's actually what I'm trying to reproduce. As I say though, only to close the form.
...

Not quite correct - I had to set the Cancel property to False on that button as it was triggering when I simply wanted to cancel an amendment. Normally my cmdExit buttons have it set to True.

[ADezii]

Hello NeoPa, there are a couple of conventions that you frequently use that I am a little confused on, and also curious about. I am specifically referring to the two items listed below. If you don't mind, can you please explain the logic:

1. Case 1==> ([use of (1)] ==> Split(.Filter, "'")(1)
2. Case 2 ==> [Replaceable Parameters]?
   

   .Caption = Replace(.Caption, "%J", strJob)
           .lblTitle.Caption = Replace(.lblTitle.Caption, "%J", strJob)

3. Thanks for bearing with me.

[NeoPa]

Update:
I tried adding the close in on the KeyUp event, but still had the same problem :(

[NeoPa]

Hello NeoPa, there are a couple of conventions that you frequently use that I am a little confused on, and also curious about. I am specifically referring to the two items listed below. If you don't mind, can you please explain the logic:

1. Case 1==> ([use of (1)] ==> Split(.Filter, "'")(1)
2. Case 2 ==> [Replaceable Parameters]?
   

   .Caption = Replace(.Caption, "%J", strJob)
           .lblTitle.Caption = Replace(.lblTitle.Caption, "%J", strJob)

3. Thanks for bearing with me.

Certainly, as far as I am able.

1. I think the line you're referring to is :
   

   If .Filter > "" Then strJob = Split(.Filter, "'")(1)

   The .Filter string would typically be something like :
   [Job]='PriceUpd'
   The Split() function returns an array (lowest element numbered 0) of string type variants where each of the characters in the string matching that supplied (') acts as a separator.
   In this case an array would be created :
   0 = "[Job]="
   1 = "PriceUpd"
   2 = ""
   As with any array (including an array returned by a function), appending an index in parentheses selects that individual element.
   So, Split(.Filter, "'")(1) == "PriceUpd"
2. When using strings with variable items in, I prefer to build it up in exactly that way. It makes it clearer to someone reading the code that there is a string required, and a part of it is variable (the %parameter bit) but that the main string is like a template and is unchanging. The data in both the .Caption and .lblTitle.Caption properties (See lines #11 to #12) is :
   tblJobTask (%J)
   So, from the earlier code - they are both set to :
   tblJobTask (PriceUpd)

NB. The code was not provided with any expectation that anyone would try to debug from that. It is purely and simply for reference purposes. If anyone had any questions about what else was there, it may be answered simply by checking through the code.

[Scott Price]

Not sure how this might be happening with your situation, but when using the .Close method, if the optional objecttype and objectname arguments are left blank, Access closes the active window.

Is it possible that the focus is being passed from the form to the database window in your setup, thus causing the active window to be the database, which then is closed?

As a simple test you could try adding the objecttype and objectname arguments to see if that changes the behavior.

Regards,
Scott

[ADezii]

Certainly, as far as I am able.

1. I think the line you're referring to is :
   

   If .Filter > "" Then strJob = Split(.Filter, "'")(1)

   The .Filter string would typically be something like :
   [Job]='PriceUpd'
   The Split() function returns an array (lowest element numbered 0) of string type variants where each of the characters in the string matching that supplied (') acts as a separator.
   In this case an array would be created :
   0 = "[Job]="
   1 = "PriceUpd"
   2 = ""
   As with any array (including an array returned by a function), appending an index in parentheses selects that individual element.
   So, Split(.Filter, "'")(1) == "PriceUpd"
2. When using strings with variable items in, I prefer to build it up in exactly that way. It makes it clearer to someone reading the code that there is a string required, and a part of it is variable (the %parameter bit) but that the main string is like a template and is unchanging. The data in both the .Caption and .lblTitle.Caption properties (See lines #11 to #12) is :
   tblJobTask (%J)
   So, from the earlier code - they are both set to :
   tblJobTask (PriceUpd)

NB. The code was not provided with any expectation that anyone would try to debug from that. It is purely and simply for reference purposes. If anyone had any questions about what else was there, it may be answered simply by checking through the code.

Curiosity satisfied, thanks NeoPa.

[NeoPa]

I'm afraid not Scott. This is definitely calling the close from within the form itself. The focus is in one of the bound controls when Shift-Esc is pressed.

As I only recently discovered (while working on this form) that I didn't need to include the ObjectType:=acForm and ObjectName:=Me.Name parameters if I was only interested in closing the current form, I have most of my code still with these parameters set. In this particular instance I did try both ways, for both the KeyDown event procedure and the cmdExit Click procedure.

It was worth checking, and I did. Unfortunately no joy there either.

[NeoPa]

Curiosity satisfied, thanks NeoPa.

Anytime ADezii.

Did you find the reasoning made sense to you?
Do they sound like techniques you may want to take up?

[NeoPa]

As an addendum to that, and only for anyone interested in such things, I actually find that I use the Replace() technique so much that I even wrote a function to handle multiple pairs of parameters for replacing.

I have to replace any posted code with multiple calls to Replace() so that it makes sense generally in the forums.

'MultiReplace replaces all occurrences of varParam in strMain with varReplace.
'Using VbBinaryCompare means that case is not ignored.
Public Function MultiReplace(ByRef strMain As String, _
                             ByVal varParam As Variant, _
                             ByVal varReplace As Variant, _
                             ParamArray avarArgs())
    Dim intIdx As Integer
 
    If (UBound(avarArgs) - LBound(avarArgs)) Mod 2 = 0 Then Stop
    MultiReplace = Replace(Expression:=strMain, _
                           Find:=Nz(varParam, ""), _
                           Replace:=Nz(varReplace, ""), _
                           Compare:=vbBinaryCompare)
    For intIdx = LBound(avarArgs) To UBound(avarArgs) Step 2
        MultiReplace = Replace(Expression:=MultiReplace, _
                               Find:=Nz(avarArgs(intIdx), ""), _
                               Replace:=Nz(avarArgs(intIdx + 1), ""), _
                               Compare:=vbBinaryCompare)
    Next intIdx
End Function

[ADezii]

Anytime ADezii.

Did you find the reasoning made sense to you?
Do they sound like techniques you may want to take up?

Did you find the reasoning made sense to you?

The reasoning made perfect sense to me, NeoPa

Do they sound like techniques you may want to take up?

I already made the change to single line Declarations, and eliminated all multi-line Statements, I guess anything is possible. (LOL).

[NeoPa]

LOL - I like it ADezii :)

But I just remembered I haven't even done Fish the courtesy of replying properly to his post :(

I will get to it immediately.

[NeoPa]

Hi, Adrian.

It is really weird. I have only a couple of guesses.

• did you try to explicitely pass form name as argument to DoCmd.Close method?
• is there any code in OnClose event handler?
• in step mode, does Access crash immediately after executing DoCmd.Close?
• what will happen if you disable error trapping?

Regards,
Fish

1. I did try that - it behaved in exactly the same way.
2. Good question - I do have a class that encapsulates forms and handles un-hiding the calling form when the called one is closed. In that sense code IS run on closure of the form.
3. Although I'm unable to test this now, I do know from running this after changes have been made to the design of the form, that the .Close method is in progress already (or even completed) as the Save Changes prompt comes up before the application disappears.
4. Error trapping has now been disabled and the problem still exists.