How do disable Close (X) button in Access

[Rania01]

Dear All
I would like to know how to either disable or remove the close button from the title bar in Access if this is even possible.

Thanks

 

[arnelgp]

#If Win64 Then
    
    Private Declare PtrSafe Function GetSystemMenu Lib "user32" _
            (ByVal hwnd As LongPtr, ByVal bRevert As Long) As LongPtr
    
    Private Declare PtrSafe Function EnableMenuItem Lib "user32" _
            (ByVal hMenu As LongPtr, ByVal wIDEnableItem As Long, ByVal wEnable As Long) As Long
#Else
    Private Declare Function GetSystemMenu Lib "user32" _
                                           (ByVal hwnd As Long, ByVal wRevert As Long) As Long
    Private Declare Function EnableMenuItem Lib "user32" _
                                            (ByVal hMenu As Long, ByVal wIDEnableItem As Long, ByVal wEnable As Long) As Long
#End If
Public Function AccessCloseButtonEnabled(pfEnabled As Boolean) As Boolean
' Comments: Control the Access close button.
'           Disabling it forces the user to exit within the application
' Params  : pfEnabled       TRUE enables the close button, FALSE disabled it
' Owner   : Copyright (c) 2008-2011 from FMS, Inc.
' Source  : Total Visual SourceBook
' Usage   : Permission granted to subscribers of the FMS Newsletter

    On Error Resume Next

    Const clngMF_ByCommand As Long = &H0&
    Const clngMF_Grayed As Long = &H1&
    Const clngSC_Close As Long = &HF060&
#If Win64 Then
    Dim lngWindow As LongPtr
    Dim lngMenu As LongPtr
#Else
    Dim lngWindow As Long
    Dim lngMenu As Long
#End If
    Dim lngFlags As Long

    lngWindow = Application.hWndAccessApp
    lngMenu = GetSystemMenu(lngWindow, 0)
    If pfEnabled Then
        lngFlags = clngMF_ByCommand And Not clngMF_Grayed
    Else
        lngFlags = clngMF_ByCommand Or clngMF_Grayed
    End If
    Call EnableMenuItem(lngMenu, clngSC_Close, lngFlags)
    AccessCloseButtonEnabled = True
End Function

run in Autoexec to disable X button.

RunCode
=AccessCloseButtonEnabled(False)

 

[Pat Hartman]

There are better solutions than to refuse to close the database. The user has the ultimate say regardless of what you do since he controls the power button as well as cntl-alt-dlet

 

[isladogs]

I've only just noticed this thread
See my Remove Title Bar Buttons example app. It is the final example in the Related Applications provided on this page

Control Application Interface

This article discusses how the Access application interface can be controlled including hiding the navigation pane, ribbon or the entire application interface. Some methods can help make a database more secure. The example app opens with a form 'floating independently' on the desktop. Various...

www.isladogs.co.uk

 

[Pat Hartman]

As I said, there are better solutions. You really don't want the user to resort to cntl-alt-del or reboot to have to close your database. If you remove the x, then make absolutely certain that the user always has a clean way to close and abandon his most recent update if necessary.

If you are attempting to do some final processing before the db closes, then the less draconian solution is to create a hidden start up form. This is the first form that opens. When it opens, it just opens your login form or menu. However, when it closes, you can add your final processing step to the close event of this form.

Since the user doesn't see this form, he can't close it. As the first form that was opened, it becomes the last form that is closed when Access is doing the closing as it would be because neither the user nor your code will close this form.

 

[isladogs]

@Pat Hartman
I realise this is now 3 months old but I missed your last reply at the time..

I think you may have missed the point here
There is absolutely no reason why users would need to resort to the 3 fingered salute or any other method to forcibly close the app.

Both @arnelgp's solution (from FMS) and mine are designed to ensure users can only close the app from a Quit button on one of the forms.
Arnel made that point in the FMS code and I make the same point in my linked article.
This idea is of course used where certain required actions need to be carried out before the app closes.

Your approach is also fine but I disagree that it is necessarily a better solution

 

[Pat Hartman]

Hi Colin,
It is not clear what the OP's intent is. He said he wants to prevent them from closing the app. This request is almost always due to flawed design rather than a desire for a clean interface.

As I reread it, it feels like there are exchanges that are missing. Perhaps there was a different thread active at the same time where the user said he wanted to prevent the close because he wanted the user to make entries on two forms and I thought I was replying to that one.

 

[mjdemaris]

The hidden form can be very useful if the OP needs to add functionality for updating the front end, forcing users to log out, etc. Using a custom 'Quit' button on a form can work with a hidden form as well.

Pat was not stating that a user would need to force close the app, just providing a solution that allows for a clean closure on the DB.

I have been using a hidden form since I started learning from you all here, and began employing my own custom 'Quit' buttons for forms and for the app as well. Sometimes you don't want a user, depending on the application of the front end, to be able to close the app - e.g. when it's supposed to stay open 24/7. We have one work station where this is the case, it is essentially a part search tool and some users have tended to experiment with what they can do on other's computers.

Anyway, that's my two cents. Cheers!

 

[The_Doc_Man]

There is absolutely no reason why users would need to resort to the 3 fingered salute or any other method to forcibly close the app.

True, except that they do it anyway.

 

[Isaac]

I often find it helpful to hide the access shell so that the user must use my 'Exit Database' button, this provides a certain appealing readability to the code that I then want to run whenever the database is closed, due to being behind the btnExitDatabase click event rather than mysteriously in a form's Unload or Close event....And has the added benefit of not firing when you're in dev mode and go from Form to Design view, which can complicate things exponentially and require jumping through more hoops to avoid, like implementing a Dev and Prod mode.

Why want to know? It can be helpful to know who is currently in the database (for broadcast messages, general communication, or announcing emergency downtime), analyzing app utilization, etc. There also might be any number of things you'd want to do when the user exits - like unlinking tables that were linked on the fly, un-mapping a drive that was mapped on the fly, the list goes on, updating tables or combos etc.

Personally, I have never had situations where users Kill the database (Task Manager, etc) as long as I give them an Exit Database button that always works, unless they experienced some major problem with the database.
Even then, it is possible to record when the database was closed by getting a little more creative:

1) when the db is opened, Create and Execute a vbscript that loops indefinitely, attempting in vain to delete the access Locking file
2) when the script is finally able to delete the Locking file, that means the database is no longer actually open - even if Killed by user
3) at this point you can execute (ADO, DAO, automating Access.exe, etc) anything needed to accurately reflect who is or isn't in the db or anything else needed.

One of my uses of VBScript has fallen in this category - having to do things outside Access for whatever reason - especially "just before" it's opened, or "just after" it's closed.