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

I remember reading somewhere that if you name your message box function MsgBox, it will be used instead of the built-in function. The reason is that VBA modules are search before built-in.

That is correct. It was mentioned in the Access Europe meeting led by Neil Sargent on Wed 7 Jan and is also covered in the articles linked in my last reply.

The same applies to any built-in function - it can be 'overwritten' by your own custom function as Access will always use the custom function by default.

For this to work successfully on existing code, the custom function must have the same arguments of the built-in version and in the same order.
Hence also my comments in point 1 of post #39 of this lengthy thread.
 
Glad I could help.

However, there are a couple of important things you need to be aware of:

1. The optional arguments for the FormattedMsgBox function are in the same order as the standard VBA MsgBox function:
Code:
Public Function FormattedMsgBox(Prompt As String, Optional Buttons As VbMsgBoxStyle = vbOKOnly, _
 Optional Title As String = vbNullString, Optional HelpFile As String = "", Optional Context As Long = 0) As VbMsgBoxResult

However, the arguments for the Wixhook.WizMsBox function are in a different order
Code:
Function WizMsgBox(bstrText As String, bstrCaption As String, wStyle As Long, idHelpID As Long, bstrHelpFileName As String) As Long

Unless you take this into account, all your previous 900+ WixMsgBox messages will not work as you expect after conversion .....
As you might imagine blind panic immediately set in: I had always used the WizMsgBox as though it had the arguments in the MsgBox order and it worked.

Then I did some archaeology in my ancient documentation (2004) and found my own function I which was using - WHMBox - had them in 'proper' order. I had written it when I first discovered WizHook and followed the recommendation of the author's article.

Phew!
 
Last edited:
2. I found out yesterday that the FormattedMsgBox can now produce both styles of message box
The old style with the bold first line is created if you omit the optional HelpFile & Context arguments.
Very interesting, Colin!
I wish the Access team would sort this out and document it accordingly.
Because at the moment, no one knows exactly how long each 'technology' will be supported...
 
As you might imagine blind panic immediately set in: I had always used the WizMsgBox as though it had the arguments in the MsgBox order and it worked.

Then I did some archaeology in my ancient documentation (2004) and found my own function I which was using - WHMBox - had them in 'proper' order. I had written it when I first discovered WizHook and followed the recommendation of the author's article.

Phew!

Phew indeed!
It was for that exact reason that my own wrapper function for the WizMsgBox (MsgBoxW) has all the arguments in the same order as the standard VBA MsgBox.
As you want the ‘old style’ messages, have you also confirmed that none of your message boxes include the HelpFile and Context arguments?
 
Very interesting, Colin!
I wish the Access team would sort this out and document it accordingly.
Because at the moment, no one knows exactly how long each 'technology' will be supported...

Yes I agree but I can’t see them doing so after all this time. Nevertheless it’s something I’m planning to raise with other MVPs and the Access team once I’ve completed the second article.
 
Phew indeed!
It was for that exact reason that my own wrapper function for the WizMsgBox (MsgBoxW) has all the arguments in the same order as the standard VBA MsgBox.
As you want the ‘old style’ messages, have you also confirmed that none of your message boxes include the HelpFile and Context arguments?
Have never needed to use Helpfile and Context (thankfully), but thanks for the warning.
 
I've only rarely used them with my FormattedMsgBox which is why I hadn't previously spotted the difference in behaviour when these were used.
Neil & I have been exchanging emails for several days about the various permutations of Eval, FormattedMsgBox & WizMsgBox and I hope to cover all of these issues in my series of articles.

The next challenge may be to achieve similar results in other Office apps such as Excel, Word
 
I did some more testing regarding the maximum text length, the wrapping of long lines without spaces, unicode and Ctrl-C support.

Maybe it will be interesting/helpful for your article Colin.

VBA Msgbox:
- Displays max. 1023 characters
- Wraps long lines, not containing blanks or similar
- Supports no unicode characters
- Supports Ctrl-C

Eval Msgbox:
- Displays more than 4000 characters (I stopped testing because I always had to scroll the MessageBox :-) )
- Doesn't wraps long lines, not containing blanks or similar
- Supports unicode characters
- No Ctrl-C

WizMsgBox:
- Displays max. 2999 characters
- Wraps long lines, not containing blanks or similar
- Supports unicode characters
- No Ctrl-C

Api MessageBoxW (user32.dll):
- Displays more than 30000 characters
- Wraps long lines, not containing blanks or similar
- Supports unicode characters
- Supports Ctrl-C

Samples:
Code:
Msgbox String(1023,"-") & "X", 64, "Standard MsgBox"
MsgBox ChrW(&H2600) & " Line 1 @Line 2@ Line3", 64, "Standard MsgBox"

Eval "Msgbox(String(4099,""-"") & ""X"", 64, ""Eval MsgBox"")"
Eval "Msgbox(String(4099,""-"") & ""X"", 64, ""Eval MsgBox"", """", 0)"
Eval "MsgBox(""" & ChrW(&H2600) & " Line 1@Line2@Line3"", 64, ""Eval MsgBox"")"
Eval "MsgBox(""" & ChrW(&H2600) & " Line 1@Line2@Line3"", 64, ""Eval MsgBox"", """", 0)"

Access.WizHook.WizMsgBox String(2998,"-") & "X", "WizMsgBox", 64, 0, ""
Access.WizHook.WizMsgBox ChrW(&H2600) & " Line 1@Line2@Line3", "WizMsgBox", 64, 0, ""

Private Declare PtrSafe Function MessageBoxW Lib "user32.dll" (ByVal xHwnd As LongPtr, ByVal lpText As LongPtr, ByVal lpCaption As LongPtr, ByVal wType As Long) As Long
MessageBoxW Application.hWndAccessApp, StrPtr(StrPtr(String(30000, "-") & "X")), StrPtr("MsgBoxW"), 64
MessageBoxW Application.hWndAccessApp, StrPtr(ChrW(&H2600) & " Line 1 @Line 2@ Line3"), StrPtr("MsgBoxW"), 64
 
@AHeyne
Thanks for that very useful info. I had seen the original version of that in your response to Mike Wolfe's Wizhook article from 2022 https://nolongerset.com/wizmsg/

In fact, I used the same techniques to determine the maximum length of the message title (132 char) and prompt text (2999 char) in my own recent article: https://www.isladogs.co.uk/wizhook-new-style-msgbox/

Later, I will probably write an article summarising the differences between the different types of message and the above info will be very useful.

I had hoped that the MessageBoxW API would also result in the new style message box but that appears to not be the case.
 
@AHeyne
Thanks for that very useful info. I had seen the original version of that in your response to Mike Wolfe's Wizhook article from 2022 https://nolongerset.com/wizmsg/

In fact, I used the same techniques to determine the maximum length of the message title (132 char) and prompt text (2999 char) in my own recent article: https://www.isladogs.co.uk/wizhook-new-style-msgbox/

Later, I will probably write an article summarising the differences between the different types of message and the above info will be very useful.

I had hoped that the MessageBoxW API would also result in the new style message box but that appears to not be the case.
The new style message box might be acceptable if it still allowed the bolding of the first line of the message. This not being there alters the logic of messages for people who use the split message features abeit WizHook or FormattedMsgBox.

The logic of its use is (for people who used the feature):

Title: app or usage area - such as Transactions, report list etc. Scene setting.

Header line (bold). The action being carried out etc. such as 'Confirm deletion'

Middle line: Main text of message.

Last line: Instruction to continue such as 'Click [Yes] to continue, or [No] abandon.


The new massively intrusive title and no ability to bold the first line makes a nonsense of this. Indeed talking to former colleague, nobody ever used the title for anything except a general statement. The new message box overemphasis the trivial and loses the content 'in the weed'

And thank god nobody has destroyed the API message box.
 
Has anyone given thought to using a dialouge form with a standard/class module and passing the title and message?
 
Has anyone given thought to using a dialouge form with a standard/class module and passing the title and message?
I posted one in code repository. It configure it's self for MsgBox and InputBox based on how it's opened.

 
For info, I've now completed the second article in my series:

This also includes a comparison of the different features of the various message types in Access 365.
Thanks again to @AHeyne for the info provided in post #48 which I included as part of that comparison.
 
Last edited:
For info, I've now completed the second article in my series:

This also includes a comparison of the different features of the various message types in Access 365.
Thanks again to @AHeyne for the info provided in post #38 which I included as part of that comparison.
I think AHeyne's post is number #48, not #38.😉
 
Last edited:
.....next challenge may be to achieve similar results in other Office apps such as Excel, Word
One app being ruined is enough!

I re-iterate one of my posts above - 'if it ain't broke don't fix it'. The new MsgBox is proof of this. It wasn't broke but it was 'fixed' anyway nd now doesn't work - no bolded first line.
 
You've made that point several times already. That is your opinion and that's fine. However there is no benefit in repeating yourself.

Excel / Word etc already have the new style Office messages but they don't have Wizhook or Eval so, unlike Access, the built-in functionality can neither be replicated nor rolled back to the old style.

At the risk of both of us beating this horse to death, there were several reasons why the new style is an improvement for many people.
These include:
  • Support for themes
  • Support for ease of access settings - that is very important for many people with eyesight problems
  • Use of colour for the default button to make it more obvious visually
  • Use of larger text and colour in the title for the same reason
Its also true that not everyone liked the bold first line.
I know you disagree with all of that. Now perhaps we can move on
 
Of course we will move on: the decisions have been made. The points in your bulleted list are all laudable but don't explain a hugely intrusive title and removal of the title bar. And anyway the highlighted heading was always optional so dislike was catered for.
 
@isladogs: Since you touched on the topic of ‘timeout’ in your article:

In addition to the MessageBoxW API, there is a similar one with timeout:

Code:
Private Declare PtrSafe Function MessageBoxTimeoutW Lib "user32.dll" (ByVal xHwnd As LongPtr, ByVal lpText As LongPtr, ByVal lpCaption As LongPtr, ByVal wType As VbMsgBoxStyle, ByVal wlange As Long, ByVal dwTimeout As Long) As Long

Public Enum VbMsgBoxTimeoutResult
    TimedOut = 32000&
End Enum

Public Function MsgBoxTimeout(ByVal msgText As String, Optional ByVal msgButtons As VbMsgBoxStyle = vbOKOnly, Optional ByVal msgTitle As String = vbNullString, Optional ByVal msgTimeoutMilliseconds As Long = 0) As VbMsgBoxResult
    MsgBoxTimeout = MessageBoxTimeoutW(Application.hWndAccessApp, _
                                       StrPtr(msgText), StrPtr(msgTitle), _
                                       msgButtons, 0, msgTimeoutMilliseconds)
End Function

I assume you are already familiar with this API, but here are my notes on it anyway:
- Displays more than 30000 characters
- Wraps long lines, not containing blanks or similar
- Supports unicode characters
- Doesn't support bold line
- If parameter msgTimeoutMilliseconds < 1 then the message box will not close by itself
- There is one additional return value to the values of VbMsgBoxResult:
If the message box timed out it returns 32000 (VbMsgBoxTimeoutResult.TimedOut)
- Sample: MsgBoxTimeout ChrW(&H2600) & " Line 1 @Line 2@ Line3", vbInformation, "MsgBoxTimeout", 1000
 
Last edited:
@AHeyne
Thanks. Yes I am familiar with that API but your notes are very helpful. In particular, I wasn’t aware of the timeout value of 32000.

After a short break from this topic area, I am planning to write an article on adding timeouts to each of the message types already mentioned: VBA, WizMsgBox, FormattedMsgBox as well as the API you mentioned.

I hope the next Access Europe meeting on 4 Feb triggers a similar level of discussion
 
I'm delighted that Isladogs pointed me in the direction of FormattedMsgBox and despite its marginally different behaviour am happily now using it.

I am unable to find, however, any reference to how or why it works and what exactly Eval is doing in this case. Can enyone help?
 

Users who are viewing this thread

Back
Top Bottom