Re: Understanding different messages

Hi,

Thank you for your help. I goofed the other night in my initial reply.
Very late and I must have been nearly asleep.

Regards,
Mark
 

-----Original Message-----
From: Discussion relating to the specifics of the C# and Managed C++
languages [mailto:[email protected]] On Behalf Of Ian
Griffiths
Sent: Tuesday, 1 August 2006 2:51 AM
To: [email protected]
Subject: Re: [DOTNET-CX] Understanding different messages

> In the first case I get an error when I want to override from one 
> class to the other

If you want to override then you should be using the override keyword.

The implication of your original message was that you only started
seeing this error when you moved to .NET 2.0. But from that error text,
it looks a lot like the error would also have occurred in .NET 1.1. Did
you really only see this first error when switching to .NET 2.0?


As for the 2nd one:

> And the other is similar yet different. I think the difference is that

> the second case overrides a Microsoft class member.
> 
> Warning 2
>
'Pipercove.Lcce.Forms.TreeForms.SettingsUI.UCSystemDeploymentContent.Min
> imumSize' hides inherited member
> 'System.Windows.Forms.Control.MinimumSize'. To make the current member

> override that implementation, add the override keyword. Otherwise add 
> the new keyword.
>
C:\share\Pipercove\PSA2\Pipercove.Lcce.Forms\TreeForms\SettingsUI\UCSyst
> emDeploymentContent.cs  144     15      Pipercove.Lcce.Forms

So the problem here is that you've got a class derived from Control and
you've given it a member MinimumSize.

That's a problem because .NET 2.0 has added a new member to Control
called MinimumSize. This new member causes a collision with your member
of the same name. This error didn't occur before because in .NET v1.1,
Control didn't define such a member.



> I'm surprised that I would need to put the override keyword everywhere

> now.

I'm surprised that you should think that this might be the correct thing
to do. Here's what I said in my previous email:


>> This means that YOU SHOULD NOT OVERRIDE.

I thought that was fairly clear, so I'm wondering how you drew the
conclusion that you should put the override keyword everywhere.

Adding the override keyword here would be ABSOLUTELY THE WRONG THING TO
DO in this case.

Maybe the SCREAMING CAPS aren't getting through - maybe you wisely
ignore people when they shout. :) So let me be clear: don't override
here!


The reason you absolutely don't want to override here is that your
UCSystemDeploymentContent.MinimumSize member was not designed to be an
override for this new Control.MinimumSize member. (After all,
Control.MinimumSize didn't even exist when
UCSystemDeploymentContent.MinimumSize was written. So there's just no
way that UCSystemDeploymentContent.MinimumSize could have been designed
as a replacement for Control.MinimumSize.)

The only reason the C# compiler has suggested overriding as a possible
fix is that it has no way of knowing that your
UCSystemDeploymentContent.MinimumSize was written before the new
Control.MinimumSize member was added to the .NET framework.

Since your MinimumSize was not designed as a replacement for the new
Control.MinimumSize, it would be an error to replace Control.MinimumSize
with your MinimumSize. (Which is what you would be doing if you used
override here.)


So how do you fix it? Well first you need to do the following two steps:

 1) Review the code for UCSystemDeploymentContent.MinimumSize, working
out what it's for and how it works.
 2) Review the documentation for the new Control.MinimumSize, working
out what it's for

Once you've done this, you should be in a position to answer the
following question:

 "Does the new Control.MinimumSize member do exactly what my
UCSystemDeploymentContent.MinimumSize does?"

If the answer is "yes", you can safely delete
UCSystemDeploymentContent.MinimumSize, because .NET 2.0 now provides
built-in functionality where you previously had to write your own code.

If the answer is "no", then you should pick a new name for
UCSystemDeploymentContent.MinimumSize - a name that is not the same as
any members of the Control class. And preferably a name that makes it
clear what the member is for and how it's different from
Control.MinimumSize. 

If the answer is a more complex one, like "well not exactly, but the
functionality of these two member is related and sort of overlaps - they
both do a similar job but the way they do it is quite different", then
you'll have to rethink that part of your design, and once you've done
that, implement your revised design.


As a stopgap solution, you could mark
UCSystemDeploymentContent.MinimumSize with the 'new' keyword. That will
shut the compiler up, and will probably enable the code to continue
working as before. (Although if your
UCSystemDeploymentContent.MinimumSize happens to do a similar thing to
the new Control.MinimumSize you might find that the existing code no
longer works, as it is conflicting with new functionality in the .NET
2.0 framework.)

But remember that this is the "can of puncture fixing gunk sprayed into
a flat tyre fix" - it's a short term 'get you home' kind of a fix that
will probably result in a catastrophic failure further down the road if
you don't get it fixed properly soon.


In short, you'll need to understand the nature of the conflict, and then
resolve the conflict.



--
Ian Griffiths
http://www.interact-sw.co.uk/iangblog/ 

> -----Original Message-----
> From: Mark Gregory
> 
> Hi Ian,
> 
> Thank you for the info, I'm still a little confused.
> 
> In the first case I get an error when I want to override from one
class
> to the other
> 
> Warning 1       'Pipercove.Lcce.Projects.Resources.CPart.IgnoreCost'
> hides inherited member 'Pipercove.Lcce.Projects.CResource.IgnoreCost'.
> Use the new keyword if hiding was intended.
> C:\share\Pipercove\PSA2\Pipercove.Lcce.Projects\Resources\CPart.cs
> 675     15      Pipercove.Lcce.Projects
> 
> And the other is similar yet different. I think the difference is that

> the second case overrides a Microsoft class member.
> 
> Warning 2
>
'Pipercove.Lcce.Forms.TreeForms.SettingsUI.UCSystemDeploymentContent.Min
> imumSize' hides inherited member
> 'System.Windows.Forms.Control.MinimumSize'. To make the current member

> override that implementation, add the override keyword. Otherwise add 
> the new keyword.
>
C:\share\Pipercove\PSA2\Pipercove.Lcce.Forms\TreeForms\SettingsUI\UCSyst
> emDeploymentContent.cs  144     15      Pipercove.Lcce.Forms
> 
> I'm surprised that I would need to put the override keyword everywhere

> now.
> 
> I would appreciate your thoughts.
> Regards
> Mark
> 
> 
> -----Original Message-----
> From: Ian Griffiths
> Sent: Monday, 31 July 2006 1:47 AM
> 
> The difference is that with CS0108 there is just one possible root 
> cause, whereas CS0114 is caused by either of two different problems,
and
> the compiler has no way of knowing which of the two it is. There's
some
> overlap because one of the two problems that can cause CS0114 happens
to
> be the same as the one problem that can cause CS0108.
> 
> The first possible problem is that you might have intended to override

> an abstract or virtual function in the base class but accidentally
left
> off the 'override' keyword.
> 
> The second possible problem is that you didn't intend the function in 
> the derived class to be in any way related to the function of the same

> name in the base class - you just have a naming collision between two 
> unrelated members.
> 
> CS0108 occurs when the problem is unambiguously the second one. If the

> base member cannot be overridden (i.e., either it's not a function, or

> it's a non-virtual function) then the compiler can know that the first

> problem cannot apply - it has to be the second problem. Since the 
> compiler is able to give you a more precise explanation of the problem

> in this situation you get this unambiguous warning. But if the member
in
> question is a virtual function, the compiler can't tell which of the
two
> problems is the root cause as both produce the same symptoms - it has
to
> give you the slightly more ambivalent message, CS0114.
> 
> 
> If you're getting these in .NET 2.0 where you weren't previously
getting
> them in 1.1, that suggests that the problem is the second one - name 
> collisions with unrelated functions. (The compiler can't work this out

> for itself because it has no knowledge of what changed between v1.1
and
> v2.0 of the framework.)
> 
> This means that YOU SHOULD NOT OVERRIDE. If you wrote a function that 
> was not intended to override an existing function in the base class,
and
> you then go ahead and make that function override some new function 
> added in .NET 2.0 in the base class, you'll essentially be 
> brain-damaging that class - you'll be replacing part of its 
> functionality with some piece of logic that was never written with the

> intention of being a replacement for whatever function it is now 
> overriding.
> 
> 
> It's rather surprising that you're getting "a lot of messages of this 
> kind." For that to happen you would need to be doing two things:
> 
>  1) You'd need to derives lots of your own classes from classes
defined
> in the .NET Framework Class Libraries and
>  2) You'd need to have an uncanny knack for picking function names in 
> your derived classes that match names Microsoft have added in V2.0 as 
> new members of existing classes.
> 
> Even if you think that (1) is a good idea (I don't but I'm aware some 
> people believe it to be a fine idea), you wouldn't expect to hit (2)
all
> that often. If you see one or two, that'd be not too big a deal. But
to
> see a lot suggests something fishy is going on. I'd want to look into 
> why you're seeing so many before working out how you're going to
resolve
> it.
> 
> 
> The correct way to resolve this is to rename the relevant members so 
> that you no longer have naming collisions. You really don't want to be

> in a situation where you have what looks like the same name for two 
> different things. (Technically they are two different names - 
> Base.method and Class.method as you point out. But in C# we don't 
> explicitly qualify method names except for static methods, so it's
very
> easy to end up calling the wrong one by accident.)
> 
> The ability to mark a method with 'new' lets you get rid of the
warning,
> but should be regarded as a stopgap. It's a bit like one of those cans

> of 'get you home' filler gunk they give you in cars without spare
tires
> that let you patch up a tire in the event of a puncture: they offer a 
> messy but workable temporary solution, but you need to fix the problem

> properly at the earliest possible opportunity.
> 
> 
> --
> Ian Griffiths
> 
> 
> 
> -----Original Message-----
> From: Mark Gregory
> 
> I would like to know what is the difference between
> 
> CS0108 and CS0114
> 
> In my program upgrade to .Net 2.0 I get a lot of messages of this
kind.
> 
> What happens if I choose to add new rather than override? Does this
mean
> that both the base method and the class method are active? I thought 
> this would be resolved by how the method is called?
> 
> Base.method
> Class.method
> 
> Or if I choose override does this preclude any use of Base.method?
> 
> I'm a little confused by what is happening here.

===================================
This list is hosted by DevelopMentor(r)  http://www.develop.com

View archives and manage your subscription(s) at
http://discuss.develop.com

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com