Both, create triangle, override method, add new methods, add interface.
I think that microsoft doesn't need to write all that code by your self, just enable things, so that we programmers could do it. And then you can focus on right/middle bottom click, printing support, IFrame, Edit, TextBox, mouseScroll, mix-ing SL and HTML
z-order.
well, i believe that this might be a little more complicated that it may seem at first. i think that the managed objects you see are just wrappers around unmanaged code which is responsible for performing the drawings. this seems to be confirmed by the fact
that all ui elements (which aer alsoe dependency obejcts) must be identified by some sort of unique ui. so, if what i said is correct and if you "open" the shape class and let you create new classes that extend the existing ones, you will need to provide an
unique ID and have some way to inject the needed code for drawing those shapes.
btw, if you just need to add new methods to existing classes, why not use the new extension methods introduced by C# 3.0?
I also need properties and events.
I will try to explain my logic on very simple example.
Let say that i don't want to write Shape.GetValue(Canvas.LeftProperty);
but i only want to use Left. So i must implement my own Left property:
public double Left
{
get
{
return this.GetValue(Canvas.LeftProperty);
........
The example is very very basic. In xaml i would still have Shape, but when i say in constructor of the control:
TShape oShape;
.....
Stream s = this.GetType().Assembly.GetManifestResourceStream(this.GetType(), pXAML);
oRootCanvas = this.InitializeFromXaml(new StreamReader(s).ReadToEnd()) as TCanvas;
oShape.BaseClass = (Shape)FindName("something");
The only problem here is how to get access to base class. But there must be a way to accomplished that.
So, in design you would still use Shape, but in code you would use TShape with all features that you want.
It would be much better if you could use TShape in xaml, but i don't think that is easy to do.
1. well, i agree that using a property is better than using the method so maybe the suggestion is adding those properties to the existing classes.
2. that won't happen. in xaml, when you say shape, you're talking about shape and not about line. that's how it works and it's not a limitation of silverlight.
Here is an example of why I would like to derive from a shape:
I would like a control that does nothing but draw a dotted line. I would like the following:
public class DottedLine : Line
{
.. set properties to make the Line dotted
}
I can do this with a UserControl that contains a single Line or a custom control where I create a control template that contains only a Line, so having the Line class sealed is not a show stopper. Just a convenience issue. At any rate, I love Silverlight,
so please don't take this as a complaint.
I can understand the performance issue, but it still would be really nice to be able to extend the functonality of alot of classes in Silverlight. Many times i find myself making a class that derives from Grid or UserControl, just to have it contain another
Silverlight class, ie. Image, and a bit of extra code. It would be much prettier to just extend the Image class, and i guess it would also mean better performance in this example?
Can you help me understand what you were trying to do exactly with Path and Rectangle? eg, you wanted to override the _____ method. Or create a Triangle class. etc... Thanks.
I want to make shapes that are cloneable. I want these shapes to be available to other users and work in Blend where the Fill and Stroke properties work properly with them. This is my current reason for being unhappy with your decision to to seal shapes.
I've been trying to circumvent this and make some sort of jury rig work but to no avail so far. About the closest I can think of is a user control with a path shape as it's content but the user control doesn't have a Fill or Stroke property. I tried retrieving
those properties with GetValue and got an "unexpected catastrophic error" for my trouble so while I can set the Fill and Stroke properties to my heart's content, I haven't found any way to retrieve them and apply them to the shape. Even if I manage, the obvious
and easy way to handle this would have been to subclass Path - if it works at all, a user control with a path in it is a klunky workaround at best.
I can't believe that you guys just couldn't think of ANY scenarios where this would be useful. I want shapes that report their areas. I want shapes that report the length of their perimiters. I want shapes that can return points on their border as a
function of distance from some canonical point so I can animate things along their borders. I want shapes that send events when other shapes in the same class cover them. I want shapes that report the smallest distance between a point and their perimiters.
The list goes on and on.
I can think of a million reasons to wish to subclass shapes, but even if I couldn't, the rule shouldn't be "I, the developer, can't think of what subclassing might be used for so it's obvious that it can't be used for anything" but "Can I absolutely guarantee
that I've covered all cases and for fundamental reasons, subclassing would never be desired for this class".
We want to err on the side of less API surface area -- if you're missing something important someone will tell you, but if you include a feature that doesn't get used you'll never hear about it, and will pay the download cost for it forever.
Nice excuse to write less documentation. I fail to see how unsealing something increases download cost.
I mean, really, what on earth is the point of sealing ScrollBar? Performance? For instantiating a class of which there'll likely be only a couple instances? There's no other way to watch for when the scroll range changes!
If we need to get back to Microsoft about missing features and we can't implement them ourselves because critical components are sealed, we're screwed.
Most of us have project deadlines that are shorter than Silverlight release cycles.
forci
Member
351 Points
275 Posts
Re: Re: Why are shapes sealed?
Jun 26, 2007 06:18 AM | LINK
Both, create triangle, override method, add new methods, add interface.
I think that microsoft doesn't need to write all that code by your self, just enable things, so that we programmers could do it. And then you can focus on right/middle bottom click, printing support, IFrame, Edit, TextBox, mouseScroll, mix-ing SL and HTML z-order.
That things, that programmers can not do it.
forci
Member
351 Points
275 Posts
Re: Re: Re: Why are shapes sealed?
Jun 28, 2007 06:27 AM | LINK
I wonder if you will remove sealed mark from shapes classes?
As i already say, there is no way that you (microsoft guys) could wrote all code that we would want, so please remove it.
luisabreu
Participant
1676 Points
612 Posts
Re: Re: Re: Why are shapes sealed?
Jun 28, 2007 09:18 AM | LINK
hello.
well, i believe that this might be a little more complicated that it may seem at first. i think that the managed objects you see are just wrappers around unmanaged code which is responsible for performing the drawings. this seems to be confirmed by the fact that all ui elements (which aer alsoe dependency obejcts) must be identified by some sort of unique ui. so, if what i said is correct and if you "open" the shape class and let you create new classes that extend the existing ones, you will need to provide an unique ID and have some way to inject the needed code for drawing those shapes.
btw, if you just need to add new methods to existing classes, why not use the new extension methods introduced by C# 3.0?
http://msdn2.microsoft.com/en-us/library/ms364047(vs.80).aspx#cs3spec_topic3
it's a little akward at first, but then you'll get used to it and it'll help you it might help several scenarios
forci
Member
351 Points
275 Posts
Re: Re: Re: Re: Why are shapes sealed?
Jun 28, 2007 11:42 AM | LINK
I also need properties and events.
I will try to explain my logic on very simple example.
Let say that i don't want to write Shape.GetValue(Canvas.LeftProperty);
but i only want to use Left. So i must implement my own Left property:
public double Left
{
get
{
return this.GetValue(Canvas.LeftProperty);
........
The example is very very basic. In xaml i would still have Shape, but when i say in constructor of the control:
TShape oShape;
.....
Stream s = this.GetType().Assembly.GetManifestResourceStream(this.GetType(), pXAML);
oRootCanvas = this.InitializeFromXaml(new StreamReader(s).ReadToEnd()) as TCanvas;
oShape.BaseClass = (Shape)FindName("something");
The only problem here is how to get access to base class. But there must be a way to accomplished that.
So, in design you would still use Shape, but in code you would use TShape with all features that you want.
It would be much better if you could use TShape in xaml, but i don't think that is easy to do.
luisabreu
Participant
1676 Points
612 Posts
Re: Re: Re: Re: Why are shapes sealed?
Jun 28, 2007 12:21 PM | LINK
Hello.
1. well, i agree that using a property is better than using the method so maybe the suggestion is adding those properties to the existing classes.
2. that won't happen. in xaml, when you say shape, you're talking about shape and not about line. that's how it works and it's not a limitation of silverlight.
forci
Member
351 Points
275 Posts
Re: Re: Re: Re: Re: Why are shapes sealed?
Jun 29, 2007 06:14 AM | LINK
2. I know and i don't expect something like that.
I only want to override this classes for better experience when using those shapes in code. That's all.
richardfen
Member
54 Points
81 Posts
Re: Re: Why are shapes sealed?
Oct 18, 2008 09:53 AM | LINK
Here is an example of why I would like to derive from a shape:
I would like a control that does nothing but draw a dotted line. I would like the following:
public class DottedLine : Line
{
.. set properties to make the Line dotted
}
I can do this with a UserControl that contains a single Line or a custom control where I create a control template that contains only a Line, so having the Line class sealed is not a show stopper. Just a convenience issue. At any rate, I love Silverlight, so please don't take this as a complaint.
syntax42
Member
6 Points
9 Posts
Re: Re: Why are shapes sealed?
Nov 07, 2008 04:26 PM | LINK
I can understand the performance issue, but it still would be really nice to be able to extend the functonality of alot of classes in Silverlight. Many times i find myself making a class that derives from Grid or UserControl, just to have it contain another Silverlight class, ie. Image, and a bit of extra code. It would be much prettier to just extend the Image class, and i guess it would also mean better performance in this example?
darrellp
Member
4 Points
4 Posts
Re: Why are shapes sealed?
Mar 18, 2009 06:31 AM | LINK
I want to make shapes that are cloneable. I want these shapes to be available to other users and work in Blend where the Fill and Stroke properties work properly with them. This is my current reason for being unhappy with your decision to to seal shapes. I've been trying to circumvent this and make some sort of jury rig work but to no avail so far. About the closest I can think of is a user control with a path shape as it's content but the user control doesn't have a Fill or Stroke property. I tried retrieving those properties with GetValue and got an "unexpected catastrophic error" for my trouble so while I can set the Fill and Stroke properties to my heart's content, I haven't found any way to retrieve them and apply them to the shape. Even if I manage, the obvious and easy way to handle this would have been to subclass Path - if it works at all, a user control with a path in it is a klunky workaround at best.
I can't believe that you guys just couldn't think of ANY scenarios where this would be useful. I want shapes that report their areas. I want shapes that report the length of their perimiters. I want shapes that can return points on their border as a function of distance from some canonical point so I can animate things along their borders. I want shapes that send events when other shapes in the same class cover them. I want shapes that report the smallest distance between a point and their perimiters. The list goes on and on.
I can think of a million reasons to wish to subclass shapes, but even if I couldn't, the rule shouldn't be "I, the developer, can't think of what subclassing might be used for so it's obvious that it can't be used for anything" but "Can I absolutely guarantee that I've covered all cases and for fundamental reasons, subclassing would never be desired for this class".
reinux
Member
35 Points
23 Posts
Re: Why are shapes sealed?
May 06, 2009 07:40 PM | LINK
Nice excuse to write less documentation. I fail to see how unsealing something increases download cost.
I mean, really, what on earth is the point of sealing ScrollBar? Performance? For instantiating a class of which there'll likely be only a couple instances? There's no other way to watch for when the scroll range changes!
If we need to get back to Microsoft about missing features and we can't implement them ourselves because critical components are sealed, we're screwed.
Most of us have project deadlines that are shorter than Silverlight release cycles.