Access Europe User Group - Wed 7 Jan: Spot the Difference – A new style MsgBox for Access (Neil Sargent) (4 Viewers)

[Jason Lee Hayes]

Hi Jason
Just tested this.
It works well when the message form has no object behind it. However I got some odd 'ghosting' effects when I moved the form over another form or the nav pane or partly off screen to the left. Not looked into the reasons as yet.

For anyone else wanting to try this code without overwriting the original, rename the existing clsFormWindow and then import the code into a new blank class module with that name.

Hi Colin,

Yes, I had another quick look and I can also see the brief flashing/ghosting effect on movement that you identified. I’ll dig into this when I get a chance.

Interestingly, on my PC the original message actually shows with rounded edges. It shouldn’t be too difficult to apply that styling to the form as well so it more closely mimics the original, though I’m not sure whether the rounded edges are unique to my setup. I’ll explore that too.


This is what my original MS Access message box looks like（Round Edges）

If you recall i sent you a small module that creates round edges many years ago now on a form（Useful before it was built in）
Below is what i see within the MsgBox Demo （Square Edges） however back form has round edges which is only identifiable on form move.

Also, on my pc had to adjust the top right Close X position ever so slightly to the left to prevent the bleed - wondering if anyone else experienced that or just me:

Fixed:

 

[isladogs]

Hi Jason
The new style messages have rounded corners in Win 11 as do all forms including Neil's custom form replicating the Access version.
In Win 10, both have square corners.
From memory, I think Neil deliberately left it so that Windows would automatically update the appearance according to version.

I also see the slight overlap bleed on one of my machines

Although in my opinion, the replication is very good, due to time constraints, there are a few minor issues and unfinished features.
For example, the replicant form

• doesn't adjust the font size when text scaling is increased in Windows Ease of Access display options
• doesn't update its appearance when using the Access dark grey or black themes

 

[isladogs]

I've just published an article describing different ways of customizing the Access message box as outlined in post #11

Customize the Access Message Box

This article describes various ways of customising the Access message boxes without code using Windows Ease of Access settings. In addition, it provides links to a variety of alternative message box functions that provide additional functionality.

www.isladogs.co.uk

The article includes details about three ways of changing Windows Ease of Access settings to adjust font size, apply colour filters and/or high contrast 'themes'. It also provides links to various alternative message boxes, all of which provide additional functionality.

Hopefully, something for everyone.

 

[NeilSargent]

I disagree, Colin. While it is true you can write a MsgBox replacement, that is a far cry from having ALL messages having consistent features. Like @DaveMD I have been annoyed that for example ODBC error dialogs do not allow you to copy the text using Ctrl+C, while other messages (including VBA.MsgBox) *do* allow that.
Replacing ALL messages by a consistent interface is VERY hard.

Well blow me down with a feather!
I didn't realise that the standard VBA message box allows you to copy the text with Ctrl-C. It beeps, suggesting an error, but it does indeed copy the text to the clipboard.
Thank you for the tip!

 

[isladogs]

@Jason Lee Hayes

@NeilSargent tried to reply to you earlier but, as a new member, his post was rejected as possible spam.
This was probably as it included a link from your own post?
Anyway, below is his response in full together with a test database which I haven't yet looked at

Jason,
You are seeing the rounded corners because you are on Windows 11 and this is a standard Win 11 effect.

I did a LOT of work on rounded corners so don't assume it will be easy. I didn't include it in my presentation because it was a work-in-progress that I couldn't complete in time.

The rounding is done by Desktop Window Manager (DWM) which is the part of Windows that manages the presentation of the Windows "chrome" (the border and the look and feel). It is this which applies the shadow to the border. Whether or not it rounds corners depends on a lot of factors, including whether the system is configured to round them and whether the graphics hardware is capable of rounding them. I found that the they do not get rounded on my Windows 11 VM (which put me at a great disadvantage when working on it). They also don't necessarily get rounded over Remote Desktop (a second barrier, since that is how you run the VM!). Like the shadow, the rounded corners depend on the Win 11 Aero effects and are the first thing to be sacrificed for bandwidth.

Colin's rounded corners code for borderless forms allows us to round the corners of the borderless form. If we change the red border from a Rectangle control to a CommandButton, we can round the corners of our border around our borderless form. We also need to round the top right corner of our Close button too by selecting a shape with just the top-right corner rounded (which may explain why this apparently odd shape variant exists).

However this does not help us to decide whether or not we should round the corners. We need to detect if Windows 11 is rounding them and only round ours if it is.

We can detect from the Windows style if DWN corner rounding is configured. But this only is a "request to round" and I can find no way of using the API to determine whether or not the platform we are on (bare PC, VM, RDP) is actually performing the corner rounding operation.

The problem is that if we round the corners on our borderless form but Windows is not actually rounding them on our shadow form, the white corners of the shadow form will still show.

My idea is to use GetPixel() to actually check the color of the bottom left and bottom right corners of the shadow form and see if they match the form's background color. If they match then the form is not being rounded, but if they do not match then the corner is being shaded (grey/transparent) to round the corners.

I found that GetPixel only works after the form is loaded and displayed and has "stabilised". Our available events only allow a timer event to be used for this (a technique I loathe, because it is not deterministic). But we are opening our shadow form and waiting 200 ms to open the parent form, so we can use this delay to allow things to settle with the shadow form and sample the corners before opening the parent. The parent form will need to provide a method for us round its corners (by changing the shape of its CommandButton border) for us to can call after the detection.

One further consideration is how much the corners are being rounded by Windows. This appears to be DPI dependent, but I have limited my work so far to use a fixed rounding radius.

I created a separate test database to do this work, which I attach. You are welcome to try to complete the pixel sampling. Remember, you need to do the sampling some time after Form_Load you have to wait for the form to have been drawn before you can sample it.

 

[isladogs]

Well blow me down with a feather!
I didn't realise that the standard VBA message box allows you to copy the text with Ctrl-C. It beeps, suggesting an error, but it does indeed copy the text to the clipboard.
Thank you for the tip!

@tvanstiphout
I didn't realise it worked either. Thanks from me also
for info, it doesn't work with the built-in new style messages created by Access itself!

 

[Jason Lee Hayes]

@Jason Lee Hayes

@NeilSargent tried to reply to you earlier but, as a new member, his post was rejected as possible spam.
This was probably as it included a link from your own post?
Anyway, below is his response in full together with a test database which I haven't yet looked at

@Jason Lee Hayes

@NeilSargent tried to reply to you earlier but, as a new member, his post was rejected as possible spam.
This was probably as it included a link from your own post?
Anyway, below is his response in full together with a test database which I haven't yet looked at

Using GetPixel() is an excellent idea, i cannot think of any other method that would work without complication. Could easily adopt the following code to sample 3x3 minimum or maybe 5x5 or 7x7 for robust detection which should reduce false negatives. There will be no minimal impact or UI response even higher reads. A fixed rounding radius i think is a nicety not a necessary IMO but will have a look at this.

'===========================================
'   Rounded Corner Detection (Windows 11+)
'   Uses pixel sampling to determine whether
'   the OS is actually rendering rounded corners.
'===========================================

Option Compare Database
Option Explicit

'--- Win32 API ---
Private Declare PtrSafe Function GetWindowDC Lib "user32" ( _
    ByVal hWnd As LongPtr) As LongPtr

Private Declare PtrSafe Function ReleaseDC Lib "user32" ( _
    ByVal hWnd As LongPtr, _
    ByVal hDC As LongPtr) As Long

Private Declare PtrSafe Function GetPixel Lib "gdi32" ( _
    ByVal hDC As LongPtr, _
    ByVal x As Long, _
    ByVal y As Long) As Long

Private Declare PtrSafe Function GetClientRect Lib "user32" ( _
    ByVal hWnd As LongPtr, _
    lpRect As RECT) As Long

Private Type RECT
    Left As Long
    Top As Long
    Right As Long
    Bottom As Long
End Type

'===========================================
'   Public Function
'===========================================
Public Function IsRoundedCornersActive(hWnd As LongPtr, _
                                       Optional BackgroundColor As Long = vbWhite) As Boolean
    Dim rc As RECT
    Dim hDC As LongPtr
    Dim pixel As Long

    ' Get client rectangle (pixel coordinates)
    If GetClientRect(hWnd, rc) = 0 Then Exit Function

    ' Acquire device context
    hDC = GetWindowDC(hWnd)
    If hDC = 0 Then Exit Function

    ' Sample bottom-right corner pixel
    pixel = GetPixel(hDC, rc.Right - 1, rc.Bottom - 1)

    ' Release DC
    Call ReleaseDC(hWnd, hDC)

    ' Compare pixel to expected background color
    ' If they match → no rounding (square corner)
    ' If they differ → rounding is active
    IsRoundedCornersActive = (pixel <> BackgroundColor)
End Function

Dim isRounded As Boolean
isRounded = IsRoundedCornersActive(Me.hWnd, RGB(255, 255, 255))

If isRounded Then
    Debug.Print "Rounded corners are active"
Else
    Debug.Print "Square corners (no rounding)"
End If

 

[Jason Lee Hayes]

Using GetPixel() is an excellent idea, i cannot think of any other method that would work without complication. Could easily adopt the following code to sample 3x3 minimum or maybe 5x5 or 7x7 for robust detection which should reduce false negatives. There will be no minimal impact or UI response even higher reads. A fixed rounding radius i think is a nicety not a necessary IMO but will have a look at this.

'===========================================
'   Rounded Corner Detection (Windows 11+)
'   Uses pixel sampling to determine whether
'   the OS is actually rendering rounded corners.
'===========================================

Option Compare Database
Option Explicit

'--- Win32 API ---
Private Declare PtrSafe Function GetWindowDC Lib "user32" ( _
    ByVal hWnd As LongPtr) As LongPtr

Private Declare PtrSafe Function ReleaseDC Lib "user32" ( _
    ByVal hWnd As LongPtr, _
    ByVal hDC As LongPtr) As Long

Private Declare PtrSafe Function GetPixel Lib "gdi32" ( _
    ByVal hDC As LongPtr, _
    ByVal x As Long, _
    ByVal y As Long) As Long

Private Declare PtrSafe Function GetClientRect Lib "user32" ( _
    ByVal hWnd As LongPtr, _
    lpRect As RECT) As Long

Private Type RECT
    Left As Long
    Top As Long
    Right As Long
    Bottom As Long
End Type

'===========================================
'   Public Function
'===========================================
Public Function IsRoundedCornersActive(hWnd As LongPtr, _
                                       Optional BackgroundColor As Long = vbWhite) As Boolean
    Dim rc As RECT
    Dim hDC As LongPtr
    Dim pixel As Long

    ' Get client rectangle (pixel coordinates)
    If GetClientRect(hWnd, rc) = 0 Then Exit Function

    ' Acquire device context
    hDC = GetWindowDC(hWnd)
    If hDC = 0 Then Exit Function

    ' Sample bottom-right corner pixel
    pixel = GetPixel(hDC, rc.Right - 1, rc.Bottom - 1)

    ' Release DC
    Call ReleaseDC(hWnd, hDC)

    ' Compare pixel to expected background color
    ' If they match → no rounding (square corner)
    ' If they differ → rounding is active
    IsRoundedCornersActive = (pixel <> BackgroundColor)
End Function

Dim isRounded As Boolean
isRounded = IsRoundedCornersActive(Me.hWnd, RGB(255, 255, 255))

If isRounded Then
    Debug.Print "Rounded corners are active"
Else
    Debug.Print "Square corners (no rounding)"
End If

Looking at Win11 on curve it uses a fixed physical radius of about 8 pixels
The formula likely be logical radius x DPI 96 DPI （100% Scaling）
144 DPI 150% & 192 DPI 200%

Could build a DWM aware adjuster that matches the OS's current theme to be more precise maybe...

 

[DickyP]

Back to the change of style there is one truly important fault with the new style message box. It stops the WizHook variant working properly.

I like many coders use this as it replicate(s/d) the original Access Message box where separating the text of the message with the @ sign divided it into a heading in bold (much like the new heading), followed by two other sections used for the message and the instructions.

MS never did explain why they removed this feature.

The title was exactly that not what it has become: part of the message. MS have forgotten the rules of English where titles and headings are NOT part of the content and you should be able to remove them and still read the document.

 

[isladogs]

@DickyP
That's interesting and unexpected!
I realise your comment was intended to be critical but you have discovered something that as far as I am concerned is helpful.
The output of the Wizhook variant of the MsgBox used to have a bold first line but is now the new style message box

You gain the red title but you lose the bold text in the first line

I'll let Neil know about this. It would have saved him a lot of work if he had known!

However, you have always been able to create the bold first line effect using the Eval function. I call this the FormattedMsgBox
It still works exactly as it has always done

Anyone who is unclear about either of these approaches, please see my articles:

Wizhook

A detailed reference guide to the hidden, undocumented but very useful Access WizHook object and its members

isladogs.co.uk

Formatted Message Box

This function allows bold text in a standard message box as well as standard features such as message box icons and more than one button. It uses the Eval function to format the first part of the code in BOLD text

isladogs.co.uk

 

[NeilSargent]

@DickyP

I don't believe that is correct. The @ delimiters do not separate the the message into title and a two line message. They separate it into a bold line and two normal weight lines.

The Title is a separate parameter as it has always been in VBA.MsgBox, Eval("MsgBox()") and Windows API MessageBox()

The purpose of the format is to provide emphasis to the first line, not to separate it as a title. This is still the case with Access's new format, except that the emphasis is done by separating the first section out as a Heading (not a Title), instead of using bold text. So I don't really see a conflict with the rules of English by any of the four distinct dialog methods,

Besides, the new MsgBox supports the "Bold Line 1@Line 2@Line 3" format directly. So there is no need for the WizHook, since there is native support for the fetaure.

Kr
Neil

 

[DickyP]

@DickyP

I don't believe that is correct. The @ delimiters do not separate the the message into title and a two line message. They separate it into a bold line and two normal weight lines.

The Title is a separate parameter as it has always been in VBA.MsgBox, Eval("MsgBox()") and Windows API MessageBox()

The purpose of the format is to provide emphasis to the first line, not to separate it as a title. This is still the case with Access's new format, except that the emphasis is done by separating the first section out as a Heading (not a Title), instead of using bold text. So I don't really see a conflict with the rules of English by any of the four distinct dialog methods,

Besides, the new MsgBox supports the "Bold Line 1@Line 2@Line 3" format directly. So there is no need for the WizHook, since there is native support for the fetaure.

Kr
Neil

Two minor points - I described the bold line as a heading. Secondly, of course it doesn't go against the rules of eEnglish: I should have said it encourages users to go against them.

 

[Jason Lee Hayes]

@DickyP
That's interesting and unexpected!
I realise your comment was intended to be critical but you have discovered something that as far as I am concerned is helpful.
The output of the Wizhook variant of the MsgBox used to have a bold first line but is now the new style message box

You gain the red title but you lose the bold text in the first line

View attachment 122906

I'll let Neil know about this. It would have saved him a lot of work if he had known!

However, you have always been able to create the bold first line effect using the Eval function. I call this the FormattedMsgBox
It still works exactly as it has always done

View attachment 122904

Anyone who is unclear about either of these approaches, please see my articles:

Wizhook

A detailed reference guide to the hidden, undocumented but very useful Access WizHook object and its members

isladogs.co.uk

Formatted Message Box

This function allows bold text in a standard message box as well as standard features such as message box icons and more than one button. It uses the Eval function to format the first part of the code in BOLD text

isladogs.co.uk

@DickyP
That's interesting and unexpected!
I realise your comment was intended to be critical but you have discovered something that as far as I am concerned is helpful.
The output of the Wizhook variant of the MsgBox used to have a bold first line but is now the new style message box

You gain the red title but you lose the bold text in the first line

View attachment 122906

I'll let Neil know about this. It would have saved him a lot of work if he had known!

However, you have always been able to create the bold first line effect using the Eval function. I call this the FormattedMsgBox
It still works exactly as it has always done

View attachment 122904

Anyone who is unclear about either of these approaches, please see my articles:

Wizhook

A detailed reference guide to the hidden, undocumented but very useful Access WizHook object and its members

isladogs.co.uk

Formatted Message Box

This function allows bold text in a standard message box as well as standard features such as message box icons and more than one button. It uses the Eval function to format the first part of the code in BOLD text

isladogs.co.uk

Just read your piece on WizHook — great write‑up. I had no idea it could do all that. I’ve heard it mentioned a few times, but never really looked into it until now.

 

[isladogs]

Wizhook is an amazing object which has been available since Access 97 and is, at least in part, used by Access wizards.
It has over 70 functions but remains completely undocumented.
Most of its functionality has been deduced over the past 25 years but even now there are a few functions that nobody has ever worked out.

The surprise to me was that it was still being updated - in this case it was the WizMsgBox function being updated for the new style messages.
Perhaps other features have changed since I wrote my article?

As far as I can tell, the WizMsgBox behaves exactly like the new style message box because that's exactly what it is.

However, there are a few features that Neil provided that the WizMsgBox doesn't have. For example:

• Copy to clipboard
• Vertical scrollbar
• Right aligned text

OTOH, the WizMsgBox appearance changes in line with Office theme colours and supports text scaling.
I'm still investigating it.