Keep Access Application Minimized (1 Viewer)

Juolupuki

Registered User.
Local time
Today, 21:11
Joined
Jan 3, 2018
Messages
31
Hi,

Just for curiosity.

Is it possible to keep Main Access app window minimized and run just forms?.

Have found code with "Function GetSystemMenu Lib “user32″", but option don't work, not fully understand why though.

Also found that you can choose "Tabbed Documents", deselect "Display Documents Tabs" in Options --> Current Database and on open form event put code lines
Code:
Private Sub Form_Open(Cancel As Integer)

    DoCmd.RunCommand acCmdAppMinimize
    DoCmd.ShowToolbar "Ribbon", acToolbarNo
    
End Sub

but problem with this is that when its minimized and you click on application icon in Taskbar it maximizes.

Any thoughts?

Thanks
 

theDBguy

I’m here to help
Staff member
Local time
Today, 13:11
Joined
Oct 29, 2018
Messages
13,748
Hi. There is an API code to hide the Access shell available somewhere but I never really bothered using it because of all the extra efforts involved.
 

Juolupuki

Registered User.
Local time
Today, 21:11
Joined
Jan 3, 2018
Messages
31
Hi. There is an API code to hide the Access shell available somewhere but I never really bothered using it because of all the extra efforts involved.

Yep there is just the line not work :/

Code:
Private Declare Function apiShowWindow Lib "user32" _
Alias "ShowWindow" (ByVal hWnd As Long, _
ByVal nCmdShow As Long) As Long


Full code...

Code:
Global Const SW_HIDE = 0
Global Const SW_SHOWNORMAL = 1
Global Const SW_SHOWMINIMIZED = 2
Global Const SW_SHOWMAXIMIZED = 3

Private Declare Function apiShowWindow Lib "user32" _
Alias "ShowWindow" (ByVal hWnd As Long, _
ByVal nCmdShow As Long) As Long

Function fSetAccessWindow(nCmdShow As Long)

Dim loX As Long
Dim loForm As Form
On Error Resume Next
Set loForm = Screen.ActiveForm

If Err <> 0 Then
    loX = apiShowWindow(hWndAccessApp, nCmdShow)
    Err.Clear
End If

If nCmdShow = SW_SHOWMINIMIZED And loForm.Modal = True Then
    MsgBox "Cannot minimize Access with " _
    & (loForm.Caption + " ") _
    & "form on screen"
ElseIf nCmdShow = SW_HIDE And loForm.PopUp <> True Then
    MsgBox "Cannot hide Access with " _
    & (loForm.Caption + " ") _
    & "form on screen"
Else
    loX = apiShowWindow(hWndAccessApp, nCmdShow)
End If
fSetAccessWindow = (loX <> 0)

End Function
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 15:11
Joined
Feb 28, 2001
Messages
18,746
The problem is partly Windows and partly Access.

When you open an application in Windows, you open a window and attach it as the primary display/interaction area. If you minimize the window, the app is still running. But the moment it needs an interaction (like a button click or typing into a text box) you must have a Window that can bring that active thing into focus. Because, after all, Windows is all about GRAPHIC (i.e. visual) interactions. Minimized window = no graphics.

This is where Access has a finger in the pie. All of the stuff you create in Access is normally part of a CHILD window, not an independent window. (It's all part of the app window you created when you launched Access.) So you can't easily expand the child if the parent is not expanded. I.e. in a graphic interface, if you can't see it, you can't interact with it, parent OR child.

The behavior you describe is normal (default) Windows behavior (not necessarily Access-originated). There are ways to override this, but what I described is the default behavior of any app that has child windows.

The approach that many of us will use (not all of us by any means) is that we limit the visibility of the design-window infrastructure by putting up some sort of opening form that covers up everything. This particular window does sizing control on its own, and don't forget that forms have usable events for size changes in case the user tries to drag the window size to change it.

We put command buttons on this form so that you can open up forms or reports from it like a control panel. Then when you open something, we use the Windows option to "Bring to Front" so that the new thing is on top and you work in that window. When you are done, you close that item and the window dissolves, sending you back to the control panel form again.

So my question is, do you really want to hide access itself or were you just trying to keep people from diddling? Because you CAN make the control panel completely fill the Access window, hide the ribbon, and control other features to make it look like Access isn't there but your app IS there. In a graphic environment, if Access is hidden by something on top of it, it could easily become "out of sight, out of mind." So what was your real goal? Answer that and you will have a better idea of where to go from here.
 

theDBguy

I’m here to help
Staff member
Local time
Today, 13:11
Joined
Oct 29, 2018
Messages
13,748

isladogs

CID VIP
Local time
Today, 21:11
Joined
Jan 14, 2017
Messages
14,266
It's easy for you because you're smarter than me.

Haha. Going to disagree with you about that statement as well :D
Seriously though there aren't any major quirks involved.
 

Juolupuki

Registered User.
Local time
Today, 21:11
Joined
Jan 3, 2018
Messages
31
The problem is partly Windows and partly Access.

When you open an application in Windows, you open a window and attach it as the primary display/interaction area. If you minimize the window, the app is still running. But the moment it needs an interaction (like a button click or typing into a text box) you must have a Window that can bring that active thing into focus. Because, after all, Windows is all about GRAPHIC (i.e. visual) interactions. Minimized window = no graphics.

This is where Access has a finger in the pie. All of the stuff you create in Access is normally part of a CHILD window, not an independent window. (It's all part of the app window you created when you launched Access.) So you can't easily expand the child if the parent is not expanded. I.e. in a graphic interface, if you can't see it, you can't interact with it, parent OR child.

The behavior you describe is normal (default) Windows behavior (not necessarily Access-originated). There are ways to override this, but what I described is the default behavior of any app that has child windows.

The approach that many of us will use (not all of us by any means) is that we limit the visibility of the design-window infrastructure by putting up some sort of opening form that covers up everything. This particular window does sizing control on its own, and don't forget that forms have usable events for size changes in case the user tries to drag the window size to change it.

We put command buttons on this form so that you can open up forms or reports from it like a control panel. Then when you open something, we use the Windows option to "Bring to Front" so that the new thing is on top and you work in that window. When you are done, you close that item and the window dissolves, sending you back to the control panel form again.

So my question is, do you really want to hide access itself or were you just trying to keep people from diddling? Because you CAN make the control panel completely fill the Access window, hide the ribbon, and control other features to make it look like Access isn't there but your app IS there. In a graphic environment, if Access is hidden by something on top of it, it could easily become "out of sight, out of mind." So what was your real goal? Answer that and you will have a better idea of where to go from here.

Thanks for the explaining it.

I have originally hided the main app screen with form which maximized as a background for my DB and then loads on top login screen or other forms. All forms set as Pop Up and modal, so user cant do anything else just interact with forms.

The reasons why i would like to change the look is that the DB background is covering everything on screen (even the toolbar) and some users don't know that to access anything else behind it needs to press Windows button, also the actual DB would look a bit more nicely :). As well I'm
trying to keep people from diddling?
basically all in one.
 

Juolupuki

Registered User.
Local time
Today, 21:11
Joined
Jan 3, 2018
Messages
31
Have a look at my example app https://www.access-programmers.co.uk/forums/showthread.php?t=293584
It uses code similar to what you've shown.

On this occasion I'm going to disagree with the DBG as its easy to use

Thank a lot that. That's nice peace of code :).

Unfortunately it acts exactly as with what i have achieved, if you press on application in toolbar it will maximize.

I guess that's what The_Dog_Man talk about, windows and other applications interacts.
 

isladogs

CID VIP
Local time
Today, 21:11
Joined
Jan 14, 2017
Messages
14,266
Thank a lot that. That's nice peace of code :).

Unfortunately it acts exactly as with what i have achieved, if you press on application in toolbar it will maximize.

I guess that's what The_Dog_Man talk about, windows and other applications interacts.

I have a newer version that fixes that. I’ve only tested it in 32-bit Access so far.
Can post this evening UK time when I’m back home
 

Juolupuki

Registered User.
Local time
Today, 21:11
Joined
Jan 3, 2018
Messages
31
I have a newer version that fixes that. I’ve only tested it in 32-bit Access so far.
Can post this evening UK time when I’m back home

That's great, but I'm afraid 32-bit will not work for me all machines are on 64 :/.
 

isladogs

CID VIP
Local time
Today, 21:11
Joined
Jan 14, 2017
Messages
14,266
I'll test it in 64-bit later today and let you know
 

theDBguy

I’m here to help
Staff member
Local time
Today, 13:11
Joined
Oct 29, 2018
Messages
13,748
That's great, but I'm afraid 32-bit will not work for me all machines are on 64 :/.
Hi. Just asking for some clarification here... Are you saying all machines are using 64-bit version of Access? Or, are you just saying all machines have a 64-bit version of Windows? Thanks!
 

isladogs

CID VIP
Local time
Today, 21:11
Joined
Jan 14, 2017
Messages
14,266
Good news. I've just successfully tested the updated version of my app in 64-bit Access and have uploaded it to sample databases:
https://www.access-programmers.co.uk/forums/showpost.php?p=1631476&postcount=14

The new version fixes a long standing issue that has been requested several times.
It has been tested in both 32-bit and 64-bit Access
Previously if the app was open but another window had focus, clicking the taskbar icon would restore the application window
That no longer occurs.

Hopefully that has fixed the issue you had
 

arnelgp

error reading drive A:
Local time
Tomorrow, 05:11
Joined
May 7, 2009
Messages
11,171
only 1 comment, when you hide the app window and click to unhide it the ribbon is gone also the nav pane.
 

isladogs

CID VIP
Local time
Today, 21:11
Joined
Jan 14, 2017
Messages
14,266
in the example app there are separate buttons to restore the application window, navigation pane and ribbon individually.
However, the new code does seem to be interfering with the ribbon being restored. That did work previously and I'll look into it again.
In a production app, that's unlikely to be an issue as users wouldn't be allowed to toggle any of those items
 

Users who are viewing this thread

Top Bottom