Remove not working

Remove not working

Old forum URL: forums.lhotka.net/forums/t/5148.aspx


Wal972 posted on Thursday, July 24, 2008

I have a BLB with the following code. When its called it exits at point marked. WHY any help appreciated

Public Overloads Sub Remove(ByVal ShiftID As Int16)

For Each Item As Shift In Me   DOES NOT ENTER

If Item.ShiftID = ShiftID Then

Remove(Item)

Exit For

End If

Next

End Sub

 

Thanks

Ellie

reagan123 replied on Friday, July 25, 2008

I'm new to this so this could be wrong, but the only thing I can think of is that your collection doesn't contain any items.  Have you checked the count on the collection?

JoeFallon1 replied on Friday, July 25, 2008

Ellie,

The problem is that your code:

Public Overloads Sub Remove(ByVal ShiftID As Int16)
 
For Each Item As Shift In Me   DOES NOT ENTER

most likely has an identical signature to a real method in a base class and is not being called - the base method is called.

Also you have Overloads instead of Overrides, so you are not Overriding the base behavior.

If you really want to have a parallel method then add a dummy second parameter and re-run the code.

Public Overloads Sub Remove(ByVal ShiftID As Int16, ByVal DummyValue As Boolean)
 
For Each Item As Shift In Me   DOES NOT ENTER

The base method signature may be slightly different (e.g. ShiftID as Integer instead of Int16.)

But code can't tell the difference between the 2 when they are so similar and it must choose the neares match which is the base method.

Joe

ajj3085 replied on Monday, July 28, 2008

It's really a shame VB decided to handle overloads by requiring an Overloads keyword.  Seems like this is a pretty common mistake, and one that could have been avoided by not needing the keyword.  Anyone know why it was done this way?

JoeFallon1 replied on Monday, July 28, 2008

ajj3085:
It's really a shame VB decided to handle overloads by requiring an Overloads keyword.  Seems like this is a pretty common mistake, and one that could have been avoided by not needing the keyword.  Anyone know why it was done this way?

Paul Vick's book on VB.Net explains it on pages 302-305.

The gist of it is that Shadows is a key word that hides base methods. Overloads allows the base method to still be exposed - *as long as the signature is different.*

"Overloads is used because it allows methods and properties to be overloaded across the inheritnace hierarchy."

"If a member decalred as Overloads conflicts with a base class memebr that is not the same kind of member, Overloads is the equivalent of Shadows."

So you can have a base method and a derived Property with the same name and signature and the Overloaded Property will hide the base method!

"A method declared as Overloads will still hide a memebr with the same name and parameter list in the base class. This is because it would otherwise be impossible for the compiler to choose..."

Note: Overloads is only required when doing overloading across the inheritance hierarchy. It is never required when you are doing overloading within a class.

Joe

 

 

ajj3085 replied on Monday, July 28, 2008

JoeFallon1:
The gist of it is that Shadows is a key word that hides base methods.


Right, it's the equivalent of the new keyword in C#.

JoeFallon1:
Overloads allows the base method to still be exposed - *as long as the signature is different.*

"Overloads is used because it allows methods and properties to be overloaded across the inheritnace hierarchy."

"If a member decalred as Overloads conflicts with a base class memebr that is not the same kind of member, Overloads is the equivalent of Shadows."

So you can have a base method and a derived Property with the same name and signature and the Overloaded Property will hide the base method!

"A method declared as Overloads will still hide a memebr with the same name and parameter list in the base class. This is because it would otherwise be impossible for the compiler to choose..."

Note: Overloads is only required when doing overloading across the inheritance hierarchy. It is never required when you are doing overloading within a class.

Ahh.. well at least it's not required when overloading within a class.  I didn't know that, I thought it was always required.

Still.. I'm not sure why it's needed across the inheritance hierarchy.  C# gives a compiler warning... of course it really should be changed to a compiler error.  Something like that SHOULD require a keyword if you'll be hiding an inherited member.. but it seems overkill to always require it even if the signature is different.

So, I still don't totally understand.. but then I don't understand why the C# compiler doesn't make hiding a member without the new keyword a compiler error either.

Copyright (c) Marimer LLC