BK wrote:
Converting a rather large solution from 2003 to 2005. All the errors
are worked out, but I'm trying to clean up the warnings as best I can.
The good news is that the application and it's supporting assemblies
are all working now.
Hurray!
The followins snippet is from a base form class I use in the
application. Pretty typical stuff, when a data entry form is closing
and if the user is editing data, I want to allow them to save their
work. Here is part of the code:
Dim Result As New DialogResult
The New is unnecessary here.
Result = MessageBox.Show ("Save Work?", "Close Form",
MessageBoxButto ns.YesNoCancel, MessageBoxIcon. Question,
MessageBoxDefau ltButton.Button 1)
If Result = DialogResult.Ye s Then
Me.Save()
End If
Hovering over the DialogResult.Ye s portion of the snippet, I am
"greeted" with the following warning:
Access of shared member, constant member, enum member or nested type
through an instance; qualifying expression will not be evaluated.
I *think* I understand the warning
Could you explain it to someone who didn't understand it at all? Go on,
try it :)
, but I don't understand how to
resolve it.
Do you not get the little Error Correction Options supertooltip (or
whatever they are called)? I do when I paste your code.
It runs just fine, but I won't feel right until I correct
the warning.
An excellent attitude.
What should I change?
Well, as I said I get the supertooltip thing that suggests changing
DialogResult.Ye s to Windows.Forms.D ialogResult.Yes , which works. Now
for the explanation (most of which you will already know):
Shared members of classes (eg the Yes member of DialogResult)
conceptually 'belong' to the class itself (DialogResult), not to any
particular instance (eg Result here). So, for example, if you referred
to Result.No (which you will note doesn't make much sense,
semantically) you would get the same 'No' item; and what's more, even
if you had a *function call* that returned an instance of DialogResult,
and you referred to *its* .No, the function call _would not_ be made.
Deeply artifical example:
Private Function SideEffects() As DialogResult
MsgBox("omg")
Return Windows.Forms.D ialogResult.Yes
End Function
Private Sub Button1_Click(B yVal sender As System.Object, _
ByVal e As System.EventArg s) Handles Button1.Click
If SideEffects().N o = Windows.Forms.D ialogResult.Yes Then
Msgbox("aha")
End If
End Sub
Clicking Button1 produces *no* messageboxes, not even the one in
SideEffects. Because .No is a Shared member, the compiler knows that
*whatever* DialogResult SideEffects returns, the expression
'SideEffects(). No' will always have the same value - so it doesn't even
bother calling SideEffects(). *This* is what the compiler is warning
you about.
But hang on.
Your code:
If Result = DialogResult.Ye s Then
isn't making this mistake! You are comparing an instance variable to a
value expressed as <classname>.<me mber>, which is correct, so why the
warning? Well, the clue comes if you put the cursor in this word
DialogResult and Shift+F2. You will be taken into the Object Browser
at:
Public Property DialogResult() As System.Windows. Forms.DialogRes ult
Member of: System.Windows. Forms.Form
Summary:
Gets or sets the dialog result for the form.
Aha. In the code for a WinForm, just saying 'DialogResult' means not
the *class* of that name, but the *property* of that name, because it's
'closer' syntactically. And the *property* of that name is an
*instance*, so you are referencing a Shared member through an instance
variable, see above etc etc.
Really, I'd say it's slightly quirky of MS to have this property which
has the same name as the class - although these are separate
namespaces, so it's allowed, it's still slightly odd to see
Public Property DialogResult() As System.Windows. Forms.DialogRes ult
But hey, it's their Framework.
As to the fix, and why it works? Easy to see now. By spelling out that
we mean the *class* System.Windows. Forms.DialogRes ult, rather than the
*property* DialogResult, the compiler is satisfied, and the warning
goes away.
--
Larry Lard
Replies to group please
