By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
425,884 Members | 949 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 425,884 IT Pros & Developers. It's quick & easy.

Why does this work?

P: n/a
This code (Visual Studio 2005) should generate a compilation warning to the
effect that I'm accessing a shared member through an instance variable (the
"color" variable):

Private Sub X(ByVal color As Color)
Me.BackColor = color.AliceBlue
End Sub

On *some* computers this produces the expected warning. On others it does
not. Any clue what setting is causing some computers to fail to complain?

TIA - Bob
Oct 22 '08 #1
Share this Question
Share on Google+
45 Replies


P: n/a
Vb.net is not case sensitive, so in general, having a variable called color
could be bad.

Change the parameter to colorparam and then the line to Me.BackColor =
colorparam.AliceBlue, and I bet you get the warning everywhere.

"Bob Altman" <rd*@nospam.nospamwrote in message
news:ur**************@TK2MSFTNGP06.phx.gbl...
This code (Visual Studio 2005) should generate a compilation warning to
the effect that I'm accessing a shared member through an instance variable
(the "color" variable):

Private Sub X(ByVal color As Color)
Me.BackColor = color.AliceBlue
End Sub

On *some* computers this produces the expected warning. On others it does
not. Any clue what setting is causing some computers to fail to complain?

TIA - Bob
Oct 22 '08 #2

P: n/a
'Instance variable accesses shared member' warning is configurable, so
it is set to Warning on some of those machines, and None on the others.
"Bob Altman" <rd*@nospam.nospamwrote in message
news:ur**************@TK2MSFTNGP06.phx.gbl...
This code (Visual Studio 2005) should generate a compilation warning to
the effect that I'm accessing a shared member through an instance variable
(the "color" variable):

Private Sub X(ByVal color As Color)
Me.BackColor = color.AliceBlue
End Sub

On *some* computers this produces the expected warning. On others it does
not. Any clue what setting is causing some computers to fail to complain?

TIA - Bob
Oct 22 '08 #3

P: n/a
Whether you get an error or warning or not is dependant on that particular
compiler settings (in the project's properties).

But, actually, you code is NOT accessing a shared member through an instance
variable.

An instance variable is one where you make an instance (implicitly or
explicitly) and assign a variable to it - - your code is not doing that, it
is associating a variable (color) to represent a static type. But, when you
write color.AliceBlue, the compiler doesn't see your capitalization of
color, it sees that you are attempting to access the members of a type
called "color" and since there is a type in the .NET framework called
"color", the compiler knows you are using the shared members of the color
type and not your color parameter name.

In C#, this code would be no problem since it is a case-sensitive language,
but in VB it can make your code tough to troubleshoot. As the other reply
said, when naming variables do more than change the case.

-Scott
"Bob Altman" <rd*@nospam.nospamwrote in message
news:ur**************@TK2MSFTNGP06.phx.gbl...
This code (Visual Studio 2005) should generate a compilation warning to
the effect that I'm accessing a shared member through an instance variable
(the "color" variable):

Private Sub X(ByVal color As Color)
Me.BackColor = color.AliceBlue
End Sub

On *some* computers this produces the expected warning. On others it does
not. Any clue what setting is causing some computers to fail to complain?

TIA - Bob

Oct 22 '08 #4

P: n/a
The code IS accessing a shared member through an instance variable. The
compiler will always make the access through the class or structure name
instead of evaluating the expression. The warning exists because the syntax
is legal, but the compiler action may be unexpected.

"Scott M." <s-***@nospam.nospamwrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...
Whether you get an error or warning or not is dependant on that particular
compiler settings (in the project's properties).

But, actually, you code is NOT accessing a shared member through an
instance variable.
Oct 22 '08 #5

P: n/a
That much is obvious. The question is: Where is that configuration setting
hidden?

"James Hahn" <jh***@yahoo.comwrote in message
news:eI****************@TK2MSFTNGP05.phx.gbl...
'Instance variable accesses shared member' warning is configurable,
so it is set to Warning on some of those machines, and None on the others.
"Bob Altman" <rd*@nospam.nospamwrote in message
news:ur**************@TK2MSFTNGP06.phx.gbl...
>This code (Visual Studio 2005) should generate a compilation warning to
the effect that I'm accessing a shared member through an instance
variable (the "color" variable):

Private Sub X(ByVal color As Color)
Me.BackColor = color.AliceBlue
End Sub

On *some* computers this produces the expected warning. On others it
does not. Any clue what setting is causing some computers to fail to
complain?

TIA - Bob

Oct 22 '08 #6

P: n/a
I believe your first two sentences contradict each other.
"James Hahn" wrote:
The code IS accessing a shared member through an instance variable. The
compiler will always make the access through the class or structure name
instead of evaluating the expression. The warning exists because the syntax
is legal, but the compiler action may be unexpected.

"Scott M." <s-***@nospam.nospamwrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...
Whether you get an error or warning or not is dependant on that particular
compiler settings (in the project's properties).

But, actually, you code is NOT accessing a shared member through an
instance variable.

Oct 22 '08 #7

P: n/a
Bob Altman wrote:
That much is obvious. The question is: Where is that configuration
setting hidden?
In VS 2005, I go to My Project, Compile Tab, and find a list of several
Conditions, each with a choice of Notification. One of them is "Instance
variable accesses shared member," with the notification set to "Warning." This
is a project level setting.
Oct 22 '08 #8

P: n/a
No James. No instance variable is being used here.

Here's an example that would be accessing a shared member through an
instance variable (pseudo-code)

Public Class Foo
Public Shared Property Value As String
Get
End Get
Set()
End Set
End Property
End Class

'Some other class...
Sub DoSomething()
dim f As New Foo ' <-- This is your instance variable
f.Value = "Something" '<--- This is an attempt to access a shared
member through an instance variable
End Sub

-----------

As I said, in the original example, when the compiler sees
"color.AliceBlue", it doesn't assume your are talking about the "color"
parameter, it knows to use the Color class and access its shared AliceBlue
property, which is entirely correct. No instance of the Color class has
been made (either implicitly or explicitly) and so no error occurs.

-Scott

"James Hahn" <jh***@yahoo.comwrote in message
news:eD*************@TK2MSFTNGP02.phx.gbl...
The code IS accessing a shared member through an instance variable. The
compiler will always make the access through the class or structure name
instead of evaluating the expression. The warning exists because the
syntax is legal, but the compiler action may be unexpected.

"Scott M." <s-***@nospam.nospamwrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...
>Whether you get an error or warning or not is dependant on that
particular compiler settings (in the project's properties).

But, actually, you code is NOT accessing a shared member through an
instance variable.

Oct 22 '08 #9

P: n/a
"Steve Gerrard" <my********@comcast.netwrote in message
news:X4******************************@comcast.com. ..
Bob Altman wrote:
>That much is obvious. The question is: Where is that configuration
setting hidden?

In VS 2005, I go to My Project, Compile Tab, and find a list of several
Conditions, each with a choice of Notification. One of them is "Instance
variable accesses shared member," with the notification set to "Warning."
This is a project level setting.
Hmmm... Sounded promising, but that's not it. This behavior is tied to the
PC, not to the project. I checked the project settings and "Instance
variable accesses shared member" is set to Warning as expected.

Just for grins I changed the code to look like this:

Private Sub X(ByVal color As Color)
' No warning...
Me.BackColor = color.AliceBlue
End Sub

Private Sub Y(ByVal a As Color)
' Warning: "Access of shared member...through an instance..."
Me.BackColor = a.AliceBlue
End Sub

On my PC the "color.AliceBlue" expression compiles without warning. But on
my co-worker's computer it gets the "Access of shared member...through an
instance..." warning.
Oct 22 '08 #10

P: n/a
No. The difference between what the code is doing and what the compiler is
doing is the reason for the warning.

"Family Tree Mike" <Fa************@discussions.microsoft.comwrote in
message news:DA**********************************@microsof t.com...
>I believe your first two sentences contradict each other.
"James Hahn" wrote:
>The code IS accessing a shared member through an instance variable. The
compiler will always make the access through the class or structure name
instead of evaluating the expression. The warning exists because the
syntax
is legal, but the compiler action may be unexpected.

"Scott M." <s-***@nospam.nospamwrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...
Whether you get an error or warning or not is dependant on that
particular
compiler settings (in the project's properties).

But, actually, you code is NOT accessing a shared member through an
instance variable.

Oct 23 '08 #11

P: n/a
The variable 'color' is an instance of the class 'Color', created in the Sub
declaration. The Color class includes shared readonly properties (the named
colors), so the reference within the sub to 'color.AliceBlue' is a reference
to the shared member (AliceBlue) using the instance 'color'. That's why the
warning appears.

In OP's case the issue is confused by the fact that a class name has been
used as the instance name. You can see what's actually happening by checking
the definition of 'color' (the instance, that is, as in 'color.AliceBlue').
The compiler doesn't automatically use the class instead of the instance
simply because there's a naming conflict. The compiler has detected that the
instance variable is being used to reference the shared member and has
provided a warning so that the programmer is aware that the compiler has
taken the source code to mean something other than what the programmer
wrote. But the code as written is using the instance variable, and that's
why the warning has appeared.

"Scott M." <s-***@nospam.nospamwrote in message
news:%2***************@TK2MSFTNGP03.phx.gbl...
No James. No instance variable is being used here.

Here's an example that would be accessing a shared member through an
instance variable (pseudo-code)

Public Class Foo
Public Shared Property Value As String
Get
End Get
Set()
End Set
End Property
End Class

'Some other class...
Sub DoSomething()
dim f As New Foo ' <-- This is your instance variable
f.Value = "Something" '<--- This is an attempt to access a shared
member through an instance variable
End Sub

-----------

As I said, in the original example, when the compiler sees
"color.AliceBlue", it doesn't assume your are talking about the "color"
parameter, it knows to use the Color class and access its shared AliceBlue
property, which is entirely correct. No instance of the Color class has
been made (either implicitly or explicitly) and so no error occurs.

-Scott

"James Hahn" <jh***@yahoo.comwrote in message
news:eD*************@TK2MSFTNGP02.phx.gbl...
>The code IS accessing a shared member through an instance variable. The
compiler will always make the access through the class or structure name
instead of evaluating the expression. The warning exists because the
syntax is legal, but the compiler action may be unexpected.

"Scott M." <s-***@nospam.nospamwrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...
>>Whether you get an error or warning or not is dependant on that
particular compiler settings (in the project's properties).

But, actually, you code is NOT accessing a shared member through an
instance variable.

Oct 23 '08 #12

P: n/a
"Scott M." <s-***@nospam.nospamschrieb
No James. No instance variable is being used here.
James is right. See below.
Here's an example that would be accessing a shared member through an
instance variable (pseudo-code) [...]
That's right.
As I said, in the original example, when the compiler sees
"color.AliceBlue", it doesn't assume your are talking about the
"color" parameter, it knows to use the Color class and access its
shared AliceBlue property, which is entirely correct. No instance
of the Color class has been made (either implicitly or explicitly)
and so no error occurs.
The compiler resolves names inside out. In this example

Private Sub X(ByVal color As Color)
Me.BackColor = color.AliceBlue
End Sub

the 2nd line accesses 'color'. When doing name resolution, the compiler
finds the _argument_ named color. This is definitely an instance variable.
Therefore, color.AliceBlue means accessing a shared member through an
instance variable. Therefore the warning.

The compiler does _not_ overlook the argument color, therefore it does _not_
find the (imported) (System.Drawing.)Color type. You would have to use
System.Drawing.Color, or Drawing.Color as the System namespace is imported
by default, to refer to the _type_ Color.

Though, this does not explain why the OP has different behavior on different
machines as long as the project's warning settings are the same. Maybe the
"warnings" check box is just not checked in the error/warnings window on the
other machine.
Armin

Oct 23 '08 #13

P: n/a
Though, this does not explain why the OP has different behavior on
different
machines as long as the project's warning settings are the same. Maybe the
"warnings" check box is just not checked in the error/warnings window on
the
other machine.
Nice try, but that's not it. Not only is there no warning message in the
error/warnings window (and, yes, I verified that warnings are enabled) but
there also is no wavy underline in the code window.

And, as I noted in another branch of this discussion, I verified that the
problem machine *does* generate the expected warning if the local variable
name is different than the class name, like this:

Private Sub X(ByVal color As Color)
' No warning...
Me.BackColor = color.AliceBlue
End Sub

Private Sub Y(ByVal a As Color)
' Warning: "Access of shared member...through an instance..."
Me.BackColor = a.AliceBlue
End Sub

On my PC the "color.AliceBlue" expression compiles without warning. But on
my co-worker's computer it gets the "Access of shared member...through an
instance..." warning.

Oct 23 '08 #14

P: n/a
Can someone explain to me why I only get the warning in the code below if
the argument is renamed to something other than "color"? In other words,
the code as is, gives no warning. The modified code using "colora" as the
parameter and using Me.BackColor = colora.AliceBlue, gives the warning.

I'm using Visual Studio Pro 2008, which I reallize is different than the OP.
"Bob Altman" <rd*@nospam.nospamwrote in message
news:u1**************@TK2MSFTNGP03.phx.gbl...
>
Nice try, but that's not it. Not only is there no warning message in the
error/warnings window (and, yes, I verified that warnings are enabled) but
there also is no wavy underline in the code window.

And, as I noted in another branch of this discussion, I verified that the
problem machine *does* generate the expected warning if the local variable
name is different than the class name, like this:

Private Sub X(ByVal color As Color)
' No warning...
Me.BackColor = color.AliceBlue
End Sub

Private Sub Y(ByVal a As Color)
' Warning: "Access of shared member...through an instance..."
Me.BackColor = a.AliceBlue
End Sub

On my PC the "color.AliceBlue" expression compiles without warning. But
on
my co-worker's computer it gets the "Access of shared member...through an
instance..." warning.
Oct 23 '08 #15

P: n/a
"Bob Altman" <rd*@nospam.nospamschrieb
Private Sub X(ByVal color As Color)
' No warning...
Me.BackColor = color.AliceBlue
End Sub

Private Sub Y(ByVal a As Color)
' Warning: "Access of shared member...through an instance..."
Me.BackColor = a.AliceBlue
End Sub

On my PC the "color.AliceBlue" expression compiles without warning. But on
my co-worker's computer it gets the "Access of shared
member...through an instance..." warning.
I don't know why I haven't tested it on my machine, yet. .... Did it now:
I do not get a warning in Sub X. My next thought was, it might be SP1 on one
machine and not on the other. I tried it on another machine without SP1....
No warning in Sub X, also. Same with a another machine without SP1.

Armin
Oct 23 '08 #16

P: n/a
"Scott M." <s-***@nospam.nospamschrieb
>
As I said, in the original example, when the compiler sees
"color.AliceBlue", it doesn't assume your are talking about the "color"
parameter, it knows to use the Color class and access its shared AliceBlue
property, which is entirely correct. No instance of the Color class has
been made (either implicitly or explicitly) and so no error occurs.
In addition...
You are saying that color.AliceBlue refers to the _type_ color, right? Then
this line must not work because 'R' is an instance member:

sub x(byval color as color)
dim b as byte = color.R
end sub

Though, it is compilable. Obviously there seems to be a contradiction in in
the compiler's behavior, IMO. - strangely not on each of Bob's machines,
whyever.
Armin

Oct 23 '08 #17

P: n/a
I tried this on both VS2005 and VS2008, and I don't get the warning in
either.

However, if I use DateTime instead of Color, I do get the warning in
both:

Private Sub Y(ByVal datetime As DateTime)
Dim xx As DateTime

datetime.AddDays(5) ' Instance Method, no error
datetime.FromBinary(9) ' Shared Method, error
xx = datetime.MaxValue ' Shared Property, error
On Thu, 23 Oct 2008 13:19:52 -0400, "Family Tree Mike"
<Fa************@ThisOldHouse.comwrote:
>Can someone explain to me why I only get the warning in the code below if
the argument is renamed to something other than "color"? In other words,
the code as is, gives no warning. The modified code using "colora" as the
parameter and using Me.BackColor = colora.AliceBlue, gives the warning.

I'm using Visual Studio Pro 2008, which I reallize is different than the OP.
"Bob Altman" <rd*@nospam.nospamwrote in message
news:u1**************@TK2MSFTNGP03.phx.gbl...
>>
Nice try, but that's not it. Not only is there no warning message in the
error/warnings window (and, yes, I verified that warnings are enabled) but
there also is no wavy underline in the code window.

And, as I noted in another branch of this discussion, I verified that the
problem machine *does* generate the expected warning if the local variable
name is different than the class name, like this:

Private Sub X(ByVal color As Color)
' No warning...
Me.BackColor = color.AliceBlue
End Sub

Private Sub Y(ByVal a As Color)
' Warning: "Access of shared member...through an instance..."
Me.BackColor = a.AliceBlue
End Sub

On my PC the "color.AliceBlue" expression compiles without warning. But
on
my co-worker's computer it gets the "Access of shared member...through an
instance..." warning.
Oct 23 '08 #18

P: n/a
On Oct 22, 3:03*am, "Bob Altman" <r...@nospam.nospamwrote:
This code (Visual Studio 2005) should generate a compilation warning to the
effect that I'm accessing a shared member through an instance variable (the
"color" variable):

* Private Sub X(ByVal color As Color)
* * Me.BackColor = color.AliceBlue
* End Sub

On *some* computers this produces the expected warning. *On others it does
not. *Any clue what setting is causing some computers to fail to complain?

TIA - Bob
Using VB 2005 Express with .NET 2.0 with default settings, it gives
the warning but it doesn't hurt the compilation. VS offers me to
change the line.

Oct 23 '08 #19

P: n/a

"James Hahn" <jh***@yahoo.comwrote in message
news:%2****************@TK2MSFTNGP06.phx.gbl...
The variable 'color' is an instance of the class 'Color', created in the
Sub declaration.
No, it is not and that's the source of your confusion. The variable color
isn't an "instance" of the class it is simply a parameter variable that
shadows the Color type's name. The compiler is able to tell the difference
between the two by the context in which the word "color" is used. Not to
mention that parameters don't create instances in the first place, they are
variables that are either passed a data value or a reference to either a
data value or a memory location where an object is stored. Parameters don't
instantiate anything.
>The Color class includes shared readonly properties (the named colors), so
the reference within the sub to 'color.AliceBlue' is a reference to the
shared member (AliceBlue) using the instance 'color'. That's why the
warning appears.
Your close, but not quite correct here. There is no instance of Color.
That's the whole point of shared type members, you don't call them from an
instance. As the OP states, he is NOT getting a warning about this line of
code and the reason he's not is because Color.AliceBlue is understood by the
compiler as accessing a shared member from a "type", not an instance.
In OP's case the issue is confused by the fact that a class name has been
used as the instance name. You can see what's actually happening by
checking the definition of 'color' (the instance, that is, as in
'color.AliceBlue'). The compiler doesn't automatically use the class
instead of the instance simply because there's a naming conflict. The
compiler has detected that the instance variable is being used to
reference the shared member and has provided a warning so that the
programmer is aware that the compiler has taken the source code to mean
something other than what the programmer wrote. But the code as written
is using the instance variable, and that's why the warning has appeared.
Again, you are wrong. There is NO instance being created here and the OP
inidcated that he wasn't getting a warning - - only in some cases was a
warning showing up. But, we've already answered the question about the
warning as being related to difference machine's different compiler warning
tolerance settings.

-Scott

>
"Scott M." <s-***@nospam.nospamwrote in message
news:%2***************@TK2MSFTNGP03.phx.gbl...
>No James. No instance variable is being used here.

Here's an example that would be accessing a shared member through an
instance variable (pseudo-code)

Public Class Foo
Public Shared Property Value As String
Get
End Get
Set()
End Set
End Property
End Class

'Some other class...
Sub DoSomething()
dim f As New Foo ' <-- This is your instance variable
f.Value = "Something" '<--- This is an attempt to access a shared
member through an instance variable
End Sub

-----------

As I said, in the original example, when the compiler sees
"color.AliceBlue", it doesn't assume your are talking about the "color"
parameter, it knows to use the Color class and access its shared
AliceBlue property, which is entirely correct. No instance of the Color
class has been made (either implicitly or explicitly) and so no error
occurs.

-Scott

"James Hahn" <jh***@yahoo.comwrote in message
news:eD*************@TK2MSFTNGP02.phx.gbl...
>>The code IS accessing a shared member through an instance variable. The
compiler will always make the access through the class or structure name
instead of evaluating the expression. The warning exists because the
syntax is legal, but the compiler action may be unexpected.

"Scott M." <s-***@nospam.nospamwrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl.. .
Whether you get an error or warning or not is dependant on that
particular compiler settings (in the project's properties).

But, actually, you code is NOT accessing a shared member through an
instance variable.



Oct 23 '08 #20

P: n/a
I disagree with your interpretation of what's going on here. Regardless of
"inside out" processing. Passing a parameter does not cause an instance of
anything to be made as parameters either receive a copy of data or a copy of
a reference to an "already existing" object. There is no instance being
created by this code.
"Armin Zingler" <az*******@freenet.dewrote in message
news:OJ**************@TK2MSFTNGP03.phx.gbl...
"Scott M." <s-***@nospam.nospamschrieb
>No James. No instance variable is being used here.

James is right. See below.
>Here's an example that would be accessing a shared member through an
instance variable (pseudo-code) [...]

That's right.
>As I said, in the original example, when the compiler sees
"color.AliceBlue", it doesn't assume your are talking about the
"color" parameter, it knows to use the Color class and access its
shared AliceBlue property, which is entirely correct. No instance
of the Color class has been made (either implicitly or explicitly)
and so no error occurs.

The compiler resolves names inside out. In this example

Private Sub X(ByVal color As Color)
Me.BackColor = color.AliceBlue
End Sub

the 2nd line accesses 'color'. When doing name resolution, the compiler
finds the _argument_ named color. This is definitely an instance variable.
Therefore, color.AliceBlue means accessing a shared member through an
instance variable. Therefore the warning.

The compiler does _not_ overlook the argument color, therefore it does
_not_
find the (imported) (System.Drawing.)Color type. You would have to use
System.Drawing.Color, or Drawing.Color as the System namespace is imported
by default, to refer to the _type_ Color.

Though, this does not explain why the OP has different behavior on
different
machines as long as the project's warning settings are the same. Maybe the
"warnings" check box is just not checked in the error/warnings window on
the
other machine.
Armin

Oct 23 '08 #21

P: n/a
This is exactly what I'm saying. In your first example, color.AliceBlue is
simply using the shared readonly property of the Color class - - business as
usual and no problem.

-Scott

"Bob Altman" <rd*@nospam.nospamwrote in message
news:u1**************@TK2MSFTNGP03.phx.gbl...
>Though, this does not explain why the OP has different behavior on
different
machines as long as the project's warning settings are the same. Maybe
the
"warnings" check box is just not checked in the error/warnings window on
the
other machine.

Nice try, but that's not it. Not only is there no warning message in the
error/warnings window (and, yes, I verified that warnings are enabled) but
there also is no wavy underline in the code window.

And, as I noted in another branch of this discussion, I verified that the
problem machine *does* generate the expected warning if the local variable
name is different than the class name, like this:

Private Sub X(ByVal color As Color)
' No warning...
Me.BackColor = color.AliceBlue
End Sub

Private Sub Y(ByVal a As Color)
' Warning: "Access of shared member...through an instance..."
Me.BackColor = a.AliceBlue
End Sub

On my PC the "color.AliceBlue" expression compiles without warning. But
on
my co-worker's computer it gets the "Access of shared member...through an
instance..." warning.

Oct 23 '08 #22

P: n/a

"Armin Zingler" <az*******@freenet.dewrote in message
news:O3**************@TK2MSFTNGP05.phx.gbl...
You are saying that color.AliceBlue refers to the _type_ color, right?
Then
this line must not work because 'R' is an instance member:

sub x(byval color as color)
dim b as byte = color.R
end sub

Though, it is compilable. Obviously there seems to be a contradiction in
in
the compiler's behavior, IMO. - strangely not on each of Bob's machines,
whyever.
No contradiction. This works because this time you are accessing the R
property of the instance of Color that would have to have been made by the
calling procedure, which is perfectly accepatable. What you've left out is
what the calling procedure would look like:

Sub test()
Dim c As Color = Color.FromName("SlateBlue")
x(c)
End Sub

Obviously, the "x" method has to have a way of accessing the instance of the
color made in the "test" method, so the code you've written would handle
that, but your code, itself, doesn't create the instance.

-Scott
Oct 23 '08 #23

P: n/a
No problem (no warning) on one computer. Problem (compiler warning) on a
different computer. I'm just trying to figure out what's different between
the two computers.

(I'll leave it to the rest of you to figure out whether or not the first
example should generate a warning. IMO, since the variable does, in fact,
have a shared member that I'm referencing, I would expect the compiler to
give me a warning. I would not expect the compiler to say "well, but I can
ignore the variable reference because it can also be interpreted as a direct
reference to the underlying class".)

"Scott M." <s-***@nospam.nospamwrote in message
news:Oy**************@TK2MSFTNGP02.phx.gbl...
This is exactly what I'm saying. In your first example, color.AliceBlue
is simply using the shared readonly property of the Color class - -
business as usual and no problem.

-Scott

"Bob Altman" <rd*@nospam.nospamwrote in message
news:u1**************@TK2MSFTNGP03.phx.gbl...
>>Though, this does not explain why the OP has different behavior on
different
machines as long as the project's warning settings are the same. Maybe
the
"warnings" check box is just not checked in the error/warnings window on
the
other machine.

Nice try, but that's not it. Not only is there no warning message in the
error/warnings window (and, yes, I verified that warnings are enabled)
but there also is no wavy underline in the code window.

And, as I noted in another branch of this discussion, I verified that the
problem machine *does* generate the expected warning if the local
variable name is different than the class name, like this:

Private Sub X(ByVal color As Color)
' No warning...
Me.BackColor = color.AliceBlue
End Sub

Private Sub Y(ByVal a As Color)
' Warning: "Access of shared member...through an instance..."
Me.BackColor = a.AliceBlue
End Sub

On my PC the "color.AliceBlue" expression compiles without warning. But
on
my co-worker's computer it gets the "Access of shared member...through an
instance..." warning.


Oct 23 '08 #24

P: n/a
But the parameter IS an instance that was passed in.

In these two scenarios:

Private Sub X(color As Color)

and

Dim color As Color

"color" is an instance of the class Color. In neither case is "color"
a reference to the class itself. Therefore color.AliceBlue should
give a warning and Color.AliceBlue should not.

See my other post where for me it appears that using DateTime instead
of Color gives the expected result.

On Thu, 23 Oct 2008 18:17:56 -0400, "Scott M." <s-***@nospam.nospam>
wrote:
>I disagree with your interpretation of what's going on here. Regardless of
"inside out" processing. Passing a parameter does not cause an instance of
anything to be made as parameters either receive a copy of data or a copy of
a reference to an "already existing" object. There is no instance being
created by this code.
"Armin Zingler" <az*******@freenet.dewrote in message
news:OJ**************@TK2MSFTNGP03.phx.gbl...
>"Scott M." <s-***@nospam.nospamschrieb
>>No James. No instance variable is being used here.

James is right. See below.
>>Here's an example that would be accessing a shared member through an
instance variable (pseudo-code) [...]

That's right.
>>As I said, in the original example, when the compiler sees
"color.AliceBlue", it doesn't assume your are talking about the
"color" parameter, it knows to use the Color class and access its
shared AliceBlue property, which is entirely correct. No instance
of the Color class has been made (either implicitly or explicitly)
and so no error occurs.

The compiler resolves names inside out. In this example

Private Sub X(ByVal color As Color)
Me.BackColor = color.AliceBlue
End Sub

the 2nd line accesses 'color'. When doing name resolution, the compiler
finds the _argument_ named color. This is definitely an instance variable.
Therefore, color.AliceBlue means accessing a shared member through an
instance variable. Therefore the warning.

The compiler does _not_ overlook the argument color, therefore it does
_not_
find the (imported) (System.Drawing.)Color type. You would have to use
System.Drawing.Color, or Drawing.Color as the System namespace is imported
by default, to refer to the _type_ Color.

Though, this does not explain why the OP has different behavior on
different
machines as long as the project's warning settings are the same. Maybe the
"warnings" check box is just not checked in the error/warnings window on
the
other machine.
Armin
Oct 23 '08 #25

P: n/a
"Scott M." <s-***@nospam.nospamwrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl...
>
"James Hahn" <jh***@yahoo.comwrote in message
news:%2****************@TK2MSFTNGP06.phx.gbl...
>The variable 'color' is an instance of the class 'Color', created in the
Sub declaration.

No, it is not and that's the source of your confusion. The variable color
isn't an "instance" of the class it is simply a parameter variable that
shadows the Color type's name. The compiler is able to tell the
difference between the two by the context in which the word "color" is
used. Not to mention that parameters don't create instances in the first
place, they are variables that are either passed a data value or a
reference to either a data value or a memory location where an object is
stored. Parameters don't instantiate anything.
Tht's just semantics. Let me rephrase it as "The declaration in the Sub is
advising the compiler that the object that will be passed to the Sub when it
executes will be an instance of the Color class." Did you do as I suggested
and ask the compiler to indicate the definition for the variable?
>>The Color class includes shared readonly properties (the named colors), so
the reference within the sub to 'color.AliceBlue' is a reference to the
shared member (AliceBlue) using the instance 'color'. That's why the
warning appears.

Your close, but not quite correct here. There is no instance of Color.
That's the whole point of shared type members, you don't call them from an
instance.
You are begging the question. Your comment is reasonable if we assume there
is no instance, but the point of the discussion is whether or not the
compiler believes that the instance exists. The point is that the compiler
reads the original code as attempting to access a shared member of an
instance. It's the compiler, not the programmer, that doesn't (won't) do
this. That's why the compiler is warning the programmer ('you') that it's
not going to do what was coded.
As the OP states, he is NOT getting a warning about this line of code and
the reason he's not is because Color.AliceBlue is understood by the
compiler as accessing a shared member from a "type", not an instance.
No. OP states that he WAS getting a warning on some machines. His concern
was for those cases wher he didn't get a warning.
>In OP's case the issue is confused by the fact that a class name has been
used as the instance name. You can see what's actually happening by
checking the definition of 'color' (the instance, that is, as in
'color.AliceBlue'). The compiler doesn't automatically use the class
instead of the instance simply because there's a naming conflict. The
compiler has detected that the instance variable is being used to
reference the shared member and has provided a warning so that the
programmer is aware that the compiler has taken the source code to mean
something other than what the programmer wrote. But the code as written
is using the instance variable, and that's why the warning has appeared.

Again, you are wrong. There is NO instance being created here and the OP
inidcated that he wasn't getting a warning - - only in some cases was a
warning showing up. But, we've already answered the question about the
warning as being related to difference machine's different compiler
warning tolerance settings.
No. Settings have been checked and are not the cause of the problem. The
difference is related somehow to the treatment of an instance with a name
that matches the class name. The OP will always get a warning if the
instance name is different than the class name. The problem was that on
SOME machines the warning is not given if the instance name is the same as
the class name.

If you want to assert that there is no instance then you have to explain why
the compiler issues the warning. I can accept that, in this example, somehow
the compiler is deciding that, since the programmer used an instance name
that matched (almost) the class name, then they were intending that the
reference to the shared variable be through the class, and no warning was
deemed necessary. However, I don't believe the compiler is this subtle (and
further testing indicates this doesn't happen for other classes). But in
any case, the lack of a warning on some machines does not demonstrate that
the compiler is treating the variable as a class instead of an instance.
And the explicit warning on some machines (and on all machines when the name
is different) clearly indicates that the compiler has detected that the
programmer is attempting to do something that the compiler will not do -
namely reference a shared variable through an instance.

Oct 23 '08 #26

P: n/a
Which suggests that the lack of a warning is related to some oddity in the
compiler's parsing of the label 'color'.

"Jack Jackson" <jj******@cinnovations.netwrote in message
news:6d********************************@4ax.com...
>I tried this on both VS2005 and VS2008, and I don't get the warning in
either.

However, if I use DateTime instead of Color, I do get the warning in
both:
Oct 23 '08 #27

P: n/a
"Scott M." <s-***@nospam.nospamschrieb
>
"Armin Zingler" <az*******@freenet.dewrote in message
news:O3**************@TK2MSFTNGP05.phx.gbl...
You are saying that color.AliceBlue refers to the _type_ color,
right? Then
this line must not work because 'R' is an instance member:

sub x(byval color as color)
dim b as byte = color.R
end sub

Though, it is compilable. Obviously there seems to be a
contradiction in in
the compiler's behavior, IMO. - strangely not on each of Bob's
machines, whyever.

No contradiction. This works because this time you are accessing
the R property of the instance of Color that would have to have been
made by the calling procedure, which is perfectly accepatable. What
you've left out is what the calling procedure would look like:
I don't know why you mention the calling procedure at all. It is out of
interest. We can play the same game with local variables only (which in fact
does not make any syntactical difference):

Dim color As Color
Dim b As Byte = color.R 'OK
Dim c As Color = color.AliceBlue 'should give a warning

In the two latter lines, we have exactly the same syntax and we are working
in the same scope. Therefore, you must decide for one of the following:

( ) color. refers to the type name
( ) color. refers to the variable name

No matter what you choose, we must get a warning in one of the two lines. As
I don't get a warning (and Bob on some machines), the compiler does not work
consistently.

I gave another proof in the other message I've just sent.

Armin

Oct 23 '08 #28

P: n/a
"James Hahn" <jh***@yahoo.comwrote in message
news:ON*************@TK2MSFTNGP04.phx.gbl...
You are begging the question. Your comment is reasonable if we assume
there is no instance, but the point of the discussion is whether or not
the compiler believes that the instance exists. The point is that the
compiler reads the original code as attempting to access a shared member
of an instance. It's the compiler, not the programmer, that doesn't
(won't) do this. That's why the compiler is warning the programmer
('you') that it's not going to do what was coded.
> As the OP states, he is NOT getting a warning about this line of code
and the reason he's not is because Color.AliceBlue is understood by the
compiler as accessing a shared member from a "type", not an instance.

No. OP states that he WAS getting a warning on some machines. His concern
was for those cases wher he didn't get a warning.
[Sigh] No James. Read the OP as well as the more recent posts from the OP
and he states that is NOT getting a warning with "color.AliceBlue". That's
becuase the compiler is completely ignoring the "color" parameter and simply
accessing the shared AliceBlue property of the Color type.

The OP said the he has seen warnings on a friend's pc, not his and his most
recent posts confirm what I'm stating here.
>
>>In OP's case the issue is confused by the fact that a class name has
been used as the instance name. You can see what's actually happening by
checking the definition of 'color' (the instance, that is, as in
'color.AliceBlue'). The compiler doesn't automatically use the class
instead of the instance simply because there's a naming conflict. The
compiler has detected that the instance variable is being used to
reference the shared member and has provided a warning so that the
programmer is aware that the compiler has taken the source code to mean
something other than what the programmer wrote. But the code as written
is using the instance variable, and that's why the warning has appeared.

Again, you are wrong. There is NO instance being created here and the OP
inidcated that he wasn't getting a warning - - only in some cases was a
warning showing up. But, we've already answered the question about the
warning as being related to difference machine's different compiler
warning tolerance settings.

No. Settings have been checked and are not the cause of the problem. The
difference is related somehow to the treatment of an instance with a name
that matches the class name. The OP will always get a warning if the
instance name is different than the class name. The problem was that on
SOME machines the warning is not given if the instance name is the same as
the class name.

If you want to assert that there is no instance then you have to explain
why the compiler issues the warning. I can accept that, in this example,
somehow the compiler is deciding that, since the programmer used an
instance name that matched (almost) the class name, then they were
intending that the reference to the shared variable be through the class,
and no warning was deemed necessary. However, I don't believe the
compiler is this subtle (and further testing indicates this doesn't happen
for other classes). But in any case, the lack of a warning on some
machines does not demonstrate that the compiler is treating the variable
as a class instead of an instance. And the explicit warning on some
machines (and on all machines when the name is different) clearly
indicates that the compiler has detected that the programmer is attempting
to do something that the compiler will not do - namely reference a shared
variable through an instance.
I have already explained why the compiler does issue the warning when the
parameter name is different than the class name and the explanation is that
if you want to access AliceBlue from some argument name (say c, rather than
color -- as in c.AliceBlue), then the compiler correctly says to itself "The
only way you could be passing a color type to this procedure is if you had
an instance of it somewhere else and if you have an instance of it somewhere
else, why are you trying to access a shared member of an instance?".

When you coincedentially use the word color as the argument name and then
write color.AliceBlue, the compiler completely ignores the "color" argument
and just assumes you mean "color" as a type and not an instance.

It's very clear what is happening and not really something that is in a grey
area.

-Scott
Oct 24 '08 #29

P: n/a
Ugh.... It's not an "oddity" it's simply the concept of the parameter
variable name "shadowing" the actual primitive name.
"James Hahn" <jh***@yahoo.comwrote in message
news:eS**************@TK2MSFTNGP04.phx.gbl...
Which suggests that the lack of a warning is related to some oddity in the
compiler's parsing of the label 'color'.

"Jack Jackson" <jj******@cinnovations.netwrote in message
news:6d********************************@4ax.com...
>>I tried this on both VS2005 and VS2008, and I don't get the warning in
either.

However, if I use DateTime instead of Color, I do get the warning in
both:

Oct 24 '08 #30

P: n/a
The only way we can definitively asnwer the why you get it in one place and
not in another is if we could compare each system's setup and configuration,
item for item, but clearly, that is what is causing the disparity, there
must be a difference in either the compiler settings or the compiler
themselves.

-Scott
"Bob Altman" <rd*@nospam.nospamwrote in message
news:Os**************@TK2MSFTNGP05.phx.gbl...
No problem (no warning) on one computer. Problem (compiler warning) on a
different computer. I'm just trying to figure out what's different
between the two computers.

(I'll leave it to the rest of you to figure out whether or not the first
example should generate a warning. IMO, since the variable does, in fact,
have a shared member that I'm referencing, I would expect the compiler to
give me a warning. I would not expect the compiler to say "well, but I
can ignore the variable reference because it can also be interpreted as a
direct reference to the underlying class".)

"Scott M." <s-***@nospam.nospamwrote in message
news:Oy**************@TK2MSFTNGP02.phx.gbl...
>This is exactly what I'm saying. In your first example, color.AliceBlue
is simply using the shared readonly property of the Color class - -
business as usual and no problem.

-Scott

"Bob Altman" <rd*@nospam.nospamwrote in message
news:u1**************@TK2MSFTNGP03.phx.gbl...
>>>Though, this does not explain why the OP has different behavior on
different
machines as long as the project's warning settings are the same. Maybe
the
"warnings" check box is just not checked in the error/warnings window
on the
other machine.

Nice try, but that's not it. Not only is there no warning message in
the error/warnings window (and, yes, I verified that warnings are
enabled) but there also is no wavy underline in the code window.

And, as I noted in another branch of this discussion, I verified that
the problem machine *does* generate the expected warning if the local
variable name is different than the class name, like this:

Private Sub X(ByVal color As Color)
' No warning...
Me.BackColor = color.AliceBlue
End Sub

Private Sub Y(ByVal a As Color)
' Warning: "Access of shared member...through an instance..."
Me.BackColor = a.AliceBlue
End Sub

On my PC the "color.AliceBlue" expression compiles without warning. But
on
my co-worker's computer it gets the "Access of shared member...through
an
instance..." warning.



Oct 24 '08 #31

P: n/a

"Jack Jackson" <jj******@cinnovations.netwrote in message
news:qv********************************@4ax.com...
Therefore color.AliceBlue should give a warning and Color.AliceBlue should
not.
VB is not case-sensitive so there is no reason to think that the case you
type it in would have any affect on the compiler.
Oct 24 '08 #32

P: n/a

"Armin Zingler" <az*******@freenet.dewrote in message
news:%2****************@TK2MSFTNGP06.phx.gbl...
I don't know why you mention the calling procedure at all. It is out of
interest. We can play the same game with local variables only (which in
fact
does not make any syntactical difference):

Dim color As Color
Dim b As Byte = color.R 'OK
Dim c As Color = color.AliceBlue 'should give a warning
None of these line result in a warning for me.
In the two latter lines, we have exactly the same syntax and we are
working
in the same scope. Therefore, you must decide for one of the following:

( ) color. refers to the type name
( ) color. refers to the variable name

No matter what you choose, we must get a warning in one of the two lines.
As
I don't get a warning (and Bob on some machines), the compiler does not
work consistently.
Now, here you are on to something. I think the solution lies in looking at
the IL. But, I don't have time to check that now-- I'll take a look
tomorrow.
-Scott
Oct 24 '08 #33

P: n/a
I don't think the case has any affect on the compiler. I think that the
compiler is flakey in the ambiguous case where there is an instance variable
name and a class name that are equivalent in a case insensitive way. The
lesson is, only if this ambiguous condition is defined in some VB.Net spec
(and it may be), then programmers just need to live with the poor choice of
coding with such parameter names.

"Scott M." <s-***@nospam.nospamwrote in message
news:%2***************@TK2MSFTNGP04.phx.gbl...
>
"Jack Jackson" <jj******@cinnovations.netwrote in message
news:qv********************************@4ax.com...
>Therefore color.AliceBlue should give a warning and Color.AliceBlue
should not.

VB is not case-sensitive so there is no reason to think that the case you
type it in would have any affect on the compiler.
Oct 24 '08 #34

P: n/a
So why do I get the warning for 'datetime' but not for 'color'?

On Thu, 23 Oct 2008 20:11:55 -0400, "Scott M." <s-***@nospam.nospam>
wrote:
>Ugh.... It's not an "oddity" it's simply the concept of the parameter
variable name "shadowing" the actual primitive name.
"James Hahn" <jh***@yahoo.comwrote in message
news:eS**************@TK2MSFTNGP04.phx.gbl...
>Which suggests that the lack of a warning is related to some oddity in the
compiler's parsing of the label 'color'.

"Jack Jackson" <jj******@cinnovations.netwrote in message
news:6d********************************@4ax.com.. .
>>>I tried this on both VS2005 and VS2008, and I don't get the warning in
either.

However, if I use DateTime instead of Color, I do get the warning in
both:
Oct 24 '08 #35

P: n/a
Scott M. wrote:
<snip>
[Sigh] No James. *Read the OP as well as the more recent posts from theOP
and he states that is NOT getting a warning with "color.AliceBlue". *That's
becuase the compiler is completely ignoring the "color" parameter and simply
accessing the shared AliceBlue property of the Color type.

The OP said the he has seen warnings on a friend's pc, not his and his most
recent posts confirm what I'm stating here.
Unfortunately it seems you are really mixing things up in at least two
accounts.

First, apparently you think the OP isn't expecting the warning. You
are wrong. The OP knows, as for his posts, that there *should* have
been a warning on his machine. He doesn't understand why there's no
warning and no indication that the compiler is catching up the error
in the code.

<snip>
I have already explained why the compiler does issue the warning when the
parameter name is different than the class name and the explanation is that
if you want to access AliceBlue from some argument name (say c, rather than
color -- as in c.AliceBlue), then the compiler correctly says to itself "The
only way you could be passing a color type to this procedure is if you had
an instance of it somewhere else and if you have an instance of it somewhere
else, why are you trying to access a shared member of an instance?".

When you coincedentially use the word color as the argument name and then
write color.AliceBlue, the compiler completely ignores the "color" argument
and just assumes you mean "color" as a type and not an instance.
And *that* is you second mix up. The code as is presented is wrong.
There *is* access to a shared member from an instance (yeah, the
choosing of the word "instance" in the warning may be misleading to
you, but I guess it is better than "non type path").

Your explanation of how the compiler is seeing the thing is way far
from the truth, I'm afraid to say. At that exact spot the compiler can
verify that the word "color" refers to a local variable, not to a
type. It doesn't care if the variable is a value type or a reference
type or even if it was correctly initialized (if it was of a reference
type). The compiler, at that moment, is only concerned in verifying if
there is a valid path to member "AliceBlue". Well, there *is* an
AliceBlue member in the Color class but then wait, the member is
marked as shared, so from VB rules a variable reference isn't a valid
path to this member.

Try it in your editor. You won't even be able to list the shared
members in intellisense. The cause of your confusion, it seems to me,
is that your notion of "instance" (correct, btw) is getting in the way
of your understanding. Maybe if the warning was "Access to a shared
member from an element that is not a type" you could actually get it?

Best regards,

Branco.

Oct 25 '08 #36

P: n/a
Actually, yes, AliceBlue shows in intellisense on my machine for any
instance. It only give's an warning (or is underlined) if it is not "color"
in spelling.
"Branco Medeiros" <br*************@gmail.comwrote in message
news:43**********************************@64g2000h su.googlegroups.com...

Try it in your editor. You won't even be able to list the shared
members in intellisense. The cause of your confusion, it seems to me,
is that your notion of "instance" (correct, btw) is getting in the way
of your understanding. Maybe if the warning was "Access to a shared
member from an element that is not a type" you could actually get it?

Best regards,

Branco.

Oct 25 '08 #37

P: n/a
Armin Zingler wrote:
"Bob Altman" <rd*@nospam.nospamschrieb
> Private Sub X(ByVal color As Color)
' No warning...
Me.BackColor = color.AliceBlue
End Sub

Private Sub Y(ByVal a As Color)
' Warning: "Access of shared member...through an instance..."
Me.BackColor = a.AliceBlue
End Sub

On my PC the "color.AliceBlue" expression compiles without warning.
But on my co-worker's computer it gets the "Access of shared
member...through an instance..." warning.

I don't know why I haven't tested it on my machine, yet. .... Did
it now: I do not get a warning in Sub X. My next thought was, it
might be SP1 on one machine and not on the other. I tried it on
another machine without SP1.... No warning in Sub X, also. Same with
a another machine without SP1.
I am surprised. I get the warning in Sub X, and it seems to me that I should. If
VB allows me to name a sub parameter color, it should then treat the word color
as that parameter, not the structure, within the local scope of the sub.

If it did not do so, and considered the word color to still be referring to the
structure, it should change it to Color, and should complain about having a
parameter name the same as a structure name.

So I consider the "shows warning" result to be correct, and the "no warning"
result to be incorrect.

And the big question is still, what is different on these various machines?
Oct 25 '08 #38

P: n/a
And the big question is still, what is different on these various
machines?

I'll be at PDC (the Microsoft Professional Developer's Conference) this
week. I'm going to see if I can get any insight from any of the MS
developers hanging out in the lounge.

Bob

Oct 26 '08 #39

P: n/a
>Unfortunately it seems you are really mixing things up in at least two
>accounts.
>First, apparently you think the OP isn't expecting the warning. You are
wrong.
No, I'm acutally trying to tell the OP that he shouldn't be expecting a
warning. And, since no warning is given, I'm explaining why.
>The OP knows, as for his posts, that there *should* have
been a warning on his machine.
Yes, and the OP is wrong to expect a warning.
He doesn't understand why there's no
warning and no indication that the compiler is catching up the error
in the code.
Again, yes - but just because he "expects" a warning doesn't mean he
"should" get one. I have been explaining that the reason he's not getting
one (which is the correct behavior) is because he is NOT accessing a shared
member through an inistance.
When you coincedentially use the word color as the argument name and then
write color.AliceBlue, the compiler completely ignores the "color"
argument
and just assumes you mean "color" as a type and not an instance.
>And *that* is you second mix up. The code as is presented is wrong.
There *is* access to a shared member from an instance (yeah, the
choosing of the word "instance" in the warning may be misleading to
you, but I guess it is better than "non type path").
As you correctly say (as I did as well)

<snip>
The compiler, at that moment, is only concerned in verifying if
there is a valid path to member "AliceBlue".
</snip>

This does follow exactly with what I stated. The compiler is trying to find
AliceBlue and it does, through the shared member of the Color type. Since
the reference to AliceBlue is through the type named "color", it assumes
that "color" refers to the type, not the variable.

<snip>
....so from VB rules a variable reference isn't a valid path to this member.
</snip>

Perhaps, but it's a good thing the compiler doesn't attempt to resolve
"color" as a variable, but instead resolves it to mean the type "color" and
hence, no warning.
>Try it in your editor. You won't even be able to list the shared
members in intellisense.
I think you should try it in your editor, because in mine, I do get the
shared members lisf after typing "color."
The cause of your confusion, it seems to me,
is that your notion of "instance" (correct, btw) is getting in the way
of your understanding. Maybe if the warning was "Access to a shared
member from an element that is not a type" you could actually get it?
I don't think your description has anything to do with anything. My
understanding of what "instance" means isn't getting in the way of anything.
I think you've misunderstood what you've read.

-Scott
Oct 27 '08 #40

P: n/a
You assert that this behaviour is 'correct' without any supporting argument
(other than that it seems sensible to you).

Perhaps you would like to refer us all to your MS reference for this single
exception to the standard name resolution rules in VB. Or some other case
where VB similarly ignores the standard rules without any warning.

"Scott M." <s-***@nospam.nospamwrote in message
news:ea**************@TK2MSFTNGP04.phx.gbl...
snip <

Again, yes - but just because he "expects" a warning doesn't mean he
"should" get one. I have been explaining that the reason he's not getting
one (which is the correct behavior) is because he is NOT accessing a
shared member through an inistance.
Oct 27 '08 #41

P: n/a

"James Hahn" <jh***@yahoo.comwrote in message
news:%2****************@TK2MSFTNGP03.phx.gbl...
You assert that this behaviour is 'correct' without any supporting
argument (other than that it seems sensible to you).

Perhaps you would like to refer us all to your MS reference for this
single exception to the standard name resolution rules in VB. Or some
other case where VB similarly ignores the standard rules without any
warning.
I'm sorry, did you provide a MS reference to the "standard name resolutions
rules for VB .NET"? It seems to me that you simply made an assertion of the
way naming works without any reference to support your statement as well.
>
"Scott M." <s-***@nospam.nospamwrote in message
news:ea**************@TK2MSFTNGP04.phx.gbl...
>snip <

Again, yes - but just because he "expects" a warning doesn't mean he
"should" get one. I have been explaining that the reason he's not
getting one (which is the correct behavior) is because he is NOT
accessing a shared member through an inistance.

Oct 28 '08 #42

P: n/a
"James Hahn" <jh***@yahoo.comschrieb:
No. The difference between what the code is doing and what the compiler is
doing is the reason for the warning.
Exactly. This is especially important if the shared member is accessed for
an object returned by an expression, which may change the application's
state, but the expression gets removed by the compiler:

\\\
Dim c As Color = Foo.DoSomething().AliceBlue
///

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

Oct 29 '08 #43

P: n/a
Well, how about
http://msdn.microsoft.com/en-us/libr...79(VS.71).aspx
http://msdn.microsoft.com/en-us/libr...82(VS.71).aspx

"Scott M." <s-***@nospam.nospamwrote in message
news:e%****************@TK2MSFTNGP03.phx.gbl...
>
"James Hahn" <jh***@yahoo.comwrote in message
news:%2****************@TK2MSFTNGP03.phx.gbl...
>You assert that this behaviour is 'correct' without any supporting
argument (other than that it seems sensible to you).

Perhaps you would like to refer us all to your MS reference for this
single exception to the standard name resolution rules in VB. Or some
other case where VB similarly ignores the standard rules without any
warning.

I'm sorry, did you provide a MS reference to the "standard name
resolutions rules for VB .NET"? It seems to me that you simply made an
assertion of the way naming works without any reference to support your
statement as well.
>>
"Scott M." <s-***@nospam.nospamwrote in message
news:ea**************@TK2MSFTNGP04.phx.gbl...
>>snip <

Again, yes - but just because he "expects" a warning doesn't mean he
"should" get one. I have been explaining that the reason he's not
getting one (which is the correct behavior) is because he is NOT
accessing a shared member through an inistance.

Oct 29 '08 #44

P: n/a
This note at the bottom of the second reference confuses me regarding the
color instance versus color class name:

Note An implication of this resolution process is that type members do not
shadow namespaces or types when resolving namespace or type names.
"James Hahn" <jh***@yahoo.comwrote in message
news:e%****************@TK2MSFTNGP03.phx.gbl...
Well, how about
http://msdn.microsoft.com/en-us/libr...79(VS.71).aspx
http://msdn.microsoft.com/en-us/libr...82(VS.71).aspx

"Scott M." <s-***@nospam.nospamwrote in message
news:e%****************@TK2MSFTNGP03.phx.gbl...
>>
"James Hahn" <jh***@yahoo.comwrote in message
news:%2****************@TK2MSFTNGP03.phx.gbl...
>>You assert that this behaviour is 'correct' without any supporting
argument (other than that it seems sensible to you).

Perhaps you would like to refer us all to your MS reference for this
single exception to the standard name resolution rules in VB. Or some
other case where VB similarly ignores the standard rules without any
warning.

I'm sorry, did you provide a MS reference to the "standard name
resolutions rules for VB .NET"? It seems to me that you simply made an
assertion of the way naming works without any reference to support your
statement as well.
>>>
"Scott M." <s-***@nospam.nospamwrote in message
news:ea**************@TK2MSFTNGP04.phx.gbl...
snip <

Again, yes - but just because he "expects" a warning doesn't mean he
"should" get one. I have been explaining that the reason he's not
getting one (which is the correct behavior) is because he is NOT
accessing a shared member through an inistance.


Oct 29 '08 #45

P: n/a
"Bob Altman" <rd*@nospam.nospamwrote in message
news:OE**************@TK2MSFTNGP04.phx.gbl...
>And the big question is still, what is different on these various
machines?

I'll be at PDC (the Microsoft Professional Developer's Conference) this
week. I'm going to see if I can get any insight from any of the MS
developers hanging out in the lounge.

Bob

Getting back to the original question, I talked to a VB compiler guy at PDC
(I don't remember his name, but I know I've read his blog) and he says that
the lack of a warning in this case is a bug that should be reported to MS
Connect, which I will do.

Bob (the now infamous OP)

Oct 29 '08 #46

This discussion thread is closed

Replies have been disabled for this discussion.