David, I'm kind of new to the inheritance logic, so I'm exploring as well. From what I have been exposed to it, the whole *Core thing is different than I have seen, but it makes sense as it still allows the base class to have logic that runs, and then optionally run related logic from the deriving class. This protects you from a user that doesn't call base.foo in their overriding implementation? In other applications, I've seen notes in the help system that warn a user that they should call the base method in their overriding implementation. You've protected us from an failure to do so. Thank you :)
Please understand that I'm not pushing for an overridable IsVisible, or complaining that it is not overridable. It's as much an academic question as anything, as I try and get a sense for the extensibility features of MapSuite. It is this extensibility that will determine if we select MapSuite as our package going forward, or keep exploring (and right now, you are looking very good).
So, here is my "IsVisible" scenario:
I use layers as a placeholder on the map, so that if I know that I always want layers loaded as streams on the bottom, roads over the top of them, and utilities on top of those, I can order the layers into an overlay one time. Sometimes I have road data, and sometimes I don't. But by keeping an empty layer there, all I have to do is plug in a roads datasource to the layer and refresh. I don't have to worry about reordering the layers after adding a new roads layer. So, if there is no data source, the layer is forced to IsVisible = false, even if the user has checked the "Show Roads" checkbox. There are other data triggers for visibility, as well as the obvious IsVislble selection by the user.
In my existing code, whenever one of the four things that set visibility changes, I call this.IsVisible and in that setter, I check the state of all four things and then call the base.IsVisible setter with the appropriate value. In my this.IsVisible getter, I just return the base.IsVisible.
If I could override IsVIsible, I would not need to have the calls to this.IsVisible in the four locations where visibility status might be changed. Rather, the this.IsVisible getter would return true or false upon demand, based upon the state of the four visibility dependency items.
None of this is a big deal. I just feel that you have to be very careful when you are overriding base functionality with a "New" attribute. Makes me feel like the base author didn't think that method or property should be overridden, and raises a red flag for me. I could also add a Visible property, rather than overriding the base IsVisible, but the intended purpose is the same, so it seams like it would be a mistake to use a differently named property in the deriving class.
Thanks for the discussion.