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

[isladogs]

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.

 

[DickyP]

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:

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

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!

 

[AHeyne]

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...

 

[isladogs]

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?

 

[isladogs]

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.

 

[DickyP]

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.

 

[isladogs]

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

 

[AHeyne]

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:

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

 

[isladogs]

@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.

 

[DickyP]

@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.

 

[NauticalGent]

Has anyone given thought to using a dialouge form with a standard/class module and passing the title and message?

 

[RonPaii]

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.

Another Input Box replacement

This is my version of an input box form and function to replace the built-in InputBox. Features RTF prompt with resizing to fit provided text. Typed return value (Text, RTF, Integer, Long, Double). Customizable button captions. 3rd button (Other). Direct fill of text box control on calling...

www.access-programmers.co.uk