Yes, that's exactly the way to do it. I haven't seen Jonathon's post, but
presumably he was referring to the danger of using declarations like

Public XYZ as whatever

because other modules can change the value any way they like. But the code
you have creates Cancel as a read-only property, which -- in this case,
anyway -- is what you want. For completeness, you might want to set mCancel
= FALSE in the form's Activate event, in case the form gets shown again,
rather than unloaded. (A principle of object-oriented coding is that an
object is not responsible for its own destruction.)

Public properties in UserForms or Class modules are fine. They (along with
public methods) are the means by which the form or class communicated with
the rest of your project.

If you declare a variable with the Public keyword on a UserForm or Class, it
acts as a read-write public property of that form or class. If you later
decide that you want to add some processing when the variable is set or read
from outside, it is easy enough to convert it into a Property Let/Get pair,
and the interface of the form or class to the outside world appears entirely
unchanged.

There are those who argue that it is better to start with a Property Let/Get
pair from the outset. I'm inclined that way in my own coding style, but I
accept that it is a matter of style, and need for this is dependent on the
complexity of the project you work on.

I was discussing in the General group yesterday the pitfalls of putting a
Public variable into an ordinary Module. They behave rather differently from
Public variables in classes or forms.

Greg Maxey was telling us:
Greg Maxey nous racontait que :

I understand the principle of the Get/Let pair for creating read-only or
Read/Write properties.

But, in such simple cases (i.e. Was the form's Cancel button used or not?),
is it "dangerous" to use simply:

Option Explicit
Public mCancel As Boolean
Private Sub cmdCancel_Click()
mCancel = True
Me.Hide
End Sub
Private Sub cmdOK_Click()
mCancel = False
Me.Hide
End Sub

Sub MagicFormDiscussion()
Dim myFrm As oUserForm
Set myFrm = New oUserForm
myFrm.Show
If myFrm.mCancel Then
 MsgBox "Form was canceled"
Else
 MsgBox "Form exited normally"
End If
MsgBox "Form complete"
Unload myFrm
Set myFrm = Nothing
End Sub

The calling Sub will not change the value of mCancel (although it could)
just because it makes no sense to do that.
Or, for the sake of completeness and total security, is it recommended to
always use a Get statement instead?
I mean, I know we could write something like:

Sub MagicFormDiscussion()
Dim myFrm As oUserForm
Set myFrm = New oUserForm
myFrm.Show

myFrm.mCancel = True

If myFrm.mCancel Then
   MsgBox "Form was canceled"
Else
   MsgBox "Form exited normally"
End If
MsgBox "Form complete"
Unload myFrm
Set myFrm = Nothing

End Sub

But why would we?

I should have suggested that you read help on 'vbModal'. If you show the
form with Modal = true, execution in the calling function stops and waits
while the form is active (ie until it is hidden or unloaded); if modal is
false, execution continues immediately. Which you obviously don't want in
your case, because you'd be trying to read the form properties before the
user has had a chance to set them.