In draw2d,How can I draw a figure without having any border?
How to implements the CustomBorder for rectangles to remove the border?
I know if we implement a class which extends Border, and in the paint method what should I do to remove the border?
Figures don't have a border unless you explicitly set one by calling setBorder(..). If you just want a blank figure that doesn't draw anything, then new Figure() will give you just that. There's no need to implement any custom borders or figures. If you are using a Rectangle then that's exactly what you will get: a rectangle; which is what you probably confused for a border.
You can disable the border with figure.setBorder(null); or you can put it in the constructor:
public static class BorderlessFigure extends Figure {
public BorderlessFigure() {
ToolbarLayout layout = new ToolbarLayout();
setLayoutManager(layout);
setBorder(null);
add(new Label("test"));
}
}
If you want a Border that does not paint anything you can extend org.eclipse.draw2d.AbstractBorder:
public class NoBorderBorder extends AbstractBorder {
#Override
public void paint(IFigure f, Graphics g, Insets i) { }
#Override
public Insets getInsets(IFigure f) {
return new Insets(0);
}
}
I don't know why would you do that though.
Related
I'm making a custom TextBox for UWP to simplify Win2D outlined text solution, for that I created a UserControl that contains only a canvas on which I'll draw the text.
Of course I need some properties, like text, outline thickness and color, etc...
I also need some properties that are already exposed by the inherited UserControl like Foreground, FontSize, FontFamily...
So far so good, it seems like I won't need to implement each one of those common properties.
The problem is that I can't find a way to hook up an event when one of those properties changes, as I have to call the Canvas.Invalidate() method to redraw it when the format changes.
Looks like I have to hide all those properties and create new Dependency Properties to call Canvas.Invalidate().
There is no way to do it faster?
Nevermind, the answer was behind the corner.
In the constructor, you can call
RegisterPropertyChangedCallback(DependencyProperty dp, DependencyPropertyChangedCallback callback);
For example:
public OutlinedText()
{
InitializeComponent();
RegisterPropertyChangedCallback(FontFamilyProperty, OnPropertyChanged);
RegisterPropertyChangedCallback(FontSizeProperty, OnPropertyChanged);
}
private void OnPropertyChanged(DependencyObject sender, DependencyProperty dp)
{
OutlinedText instance = sender as OutlinedText;
if (instance != null)
{
//Caching the value into CanvasTextFormat for faster drawn execution
if (dp == FontFamilyProperty)
instance.TextFormat.FontFamily = instance.FontFamily.Source;
else if (dp == FontSizeProperty)
instance.TextFormat.FontSize = (Single)instance.FontSize;
instance.needsResourceRecreation = true;
instance.canvas.Invalidate();
}
}
The Open/Closed Principle states that software entities (classes, modules, etc.) should be open for extension, but closed for modification. I learned about this today and my teacher said that this concept is intrinsically connected to the concept of polymorphism. I can´t really see how both concepts are connected, can anyone explain please?
Here's my exaplanation.
Look at the following example:
public interface IShape
{
void Draw();
}
public class Square : IShape
{
public void Draw()
{
// DRAW SQUARE
}
}
public class Circle : IShape
{
public void Draw()
{
// DRAW CIRCLE
}
}
public class Renderer
{
public void DrawShapes(ICollection<IShape> shapes)
{
foreach (var shape in shapes)
{
shape.Draw();
}
}
}
This code is open to extensions and closed to modifications therefore it follows the OCP principle. Why? In case you need to make the application able to draw a new shape (e.g. Triangle), you don't need to modify the DrawShapes method of the Render class.
You only need to create a new class "Triangle" that implements the interface IShape and pass it to the DrawShapes method.
This code is also polymorphic because the "DrawShapes" method does not need to know the types of the shapes that it is rendering.
Pay attention to one thing: the closure of the O.C.P. principle is always strategic. What does it mean? It means that you cannot have code that is 100% closed to modifications. Example: what happens if you need to draw all the squares before the circles? In that case you have to modify the DrawShapes method; maybe with a Strategy pattern you can inject the policy to sort the drawing of the shapes.
I'm now studying the decorator pattern, here some example code (PHP) :
abstract class component{
public function drawShape(){};
}
class concreteComponent extends component{
public function drawShape(){//code};
}
class decoratorComponent extends component{
private $component;
public function __construct($component){ $this->component=$component; }
public function drawShape(){
$this->component->drawShape();
}
}
class borderDecorator extends decoratorComponent{
public function drawShape(){
$this->drawBorder();
$this->component->drawShape();
}
public function setBorder(){};
public function drawBorder(){};
}
class bgColorDecorator extends decoratorComponent{
public function drawShape(){
$this->drawBgColor();
$this->component->drawShape();
}
public function setbgColor(){};
public function drawBgColor(){};
}
Ok, now:
$test=new concreteComponent();
$border=new borderDecorator($test);
$border->setBorder(10);
$bgColor= new bgColorDecorator($border);
$bgColor->setBgColor(#000);
Now I have a component decorated with a #000 bg color and a 10(some unit) border.
With
$bgColor->drawShape();
it means drawBgColor + drawBorder + drawShape and all right, BUT:
How can I modify or remove the border??
$bgColor-> ???
The bgColor class can't access directly the border methods...
Thanks
From what I understand you have chained your decorators in a way that leaves out a bgColorDecorator instance from which you cannot set/remove the borders.
What you should do is to change the order of construct and finish by the borderDecorator part :
$test=new concreteComponent();
$bgColor= new bgColorDecorator($test); // pass test to bgcolor
$bgColor->setBgColor(#000);
$border=new borderDecorator($bgColor); // pass bgcolor to border
$border->setBorder(10);
// You can now set/remove border on $border
// and of course : $border->drawShape();
It seems that your task is to render an object so the proper order of drawing should necessitate a change in your drawShape methods to keep the order background / shape / border
$this->drawBgColor();
$this->component->drawShape();
// will become a post-action
$this->component->drawShape();
$this->drawBgColor();
The problem is now you won't be able to set the backgroundcolor dynamically for the same reason. So the other solution could be to modify your decoratorComponent interface to include what you need and implement it in the decoratorComponent subclasses.
Edit for double border case :
Just chain two borderDecorator to a Component
$cmp = new concreteComponent();
$bDecrtor1 = new borderDecorator($cmp); // 1st border decorator on cmp
$bDecrtor1 ->setBorder(10);
$bDecrtor2=new borderDecorator($bDecrtor1); // 2nd border decorator on 1st one
$bDecrtor2->setBorder(20);
// $bDecrtor2->drawShape();
// You can then use bDecrtor1 or bDecrtor2 to (re)set the border properties
// You can use bDecrtor2 to chain other decorators...
What you could do is implement the magic method named __call() (a catch-all method), to try to delegate any non-existing method to the wrapped component:
class decoratorComponent extends component{
private $component;
/* ... */
public function __call( $name, $arguments ) {
return call_user_func_array( array( $this->component, $name ), $arguments );
}
}
You'll just have to build in safeguards to catch the cases where the method you're trying to call ultimately doesn't exist in any component down the line.
However, you should probably also evaluate whether it is even desirable to call the decorator methods after you have already wrapped them in another decorator.
The buttons in the application i've created, although set with custom images, are still Windows 7 themed (round borders, color gradience, etc). Is there a way to change them to a more windows classic or window 8 look? templates or anything that can be downloaded?
Basically you are limited to the properties provided by the windows forms button class that its shape depends on the environment (operating system version) you are running.
However, you still can customize your button shape by implementing your own CustomButton class that has the Button class as its base. In that class you have to override the painting methods (and possibly other methods) and using the passed paint event args graphics object to draw your prefered shape.
public class ExampleCustomButton : Button
{
protected override void OnPaintBackground(PaintEventArgs pevent)
{
using (Pen p = new Pen(Color.Yellow))
{
pevent.Graphics.DrawEllipse(p,
Left, Top, Width, Height); //for example
}
}
protected override void OnPaint(PaintEventArgs pevent)
{
using (Pen p = new Pen(Color.Yellow))
{
pevent.Graphics.DrawEllipse(p,
Left, Top, Width, Height); //for example
}
}
}
Please, do not forget to dispose IDisposable Graphics objects.
Good Luck
I'm very new to the SOLID design principles. One thing I had problem with understanding is the "Square-rectangle" example of a Liskov Substition Principle violation. Why should the Height/Width setter of a Square override the ones of a Rectangle? Isn't this exactly what's causing the problem when there's Polymorphism?
Doesn't removing this solve the problem?
class Rectangle
{
public /*virtual*/ double Height { get; set; }
public /*virtual*/ double Width { get; set; }
public double Area() { return Height * Width; }
}
class Square : Rectangle
{
double _width;
double _height;
public /*override*/ double Height
{
get
{
return _height;
}
set
{
_height = _width = value;
}
}
public /*override*/ double Width
{
get
{
return _width;
}
set
{
_width = _height = value;
}
}
}
class Program
{
static void Main(string[] args)
{
Rectangle r = new Square();
r.Height = 5;
r.Width = 6;
Console.WriteLine(r.Area());
Console.ReadLine();
}
}
Output is 30 as expected.
Imagine the user is implementing a bounding box in a GUI application, similar to this:
They want to represent this blue box by a Rectangle class, so that if the user clicks & drags down its height will increase; if the user drags right, its width will increase.
LSP states that a client should be able to use a derived class (Square) wherever you would use its superclass (Rectangle) without breaking the business logic of Rectangle — i.e. a user should be able to sub in one for the other & the rest of their code shouldn't break.
But the following are incompatible with each other:
It's an assumed post-condition of Rectangle that it's setter methods won't cause side effects (i.e. setWidth shouldn't affect the height)
It's inherent to the logic of a Square that its width will always equal its height.
If the programmer used Square instead of Rectangle, their assumption above wouldn't work, as if the user dragged down, the box would get bigger horizontally & vertically at the same time.
The trouble with the Square/Rectangle example is that we're assuming too much about Rectangle to begin with. A rectangle can have a different length to its height, but this is a property of a specific type of rectangle (an oblong rectangle).
A square is a rectangle, but a square is not an oblong rectangle. If we want to assume the behaviour of an oblong about our Rectangle class (that it's width & height can differ), it's then doesn't make sense for our Square class to extend from that.
The LSP states that substituting an object of a subclass should not change the behaviour, or the correctness, of the program. The classes you specify do change the correctness. With a rectangle, the client of the class expects that the height and width are independently settable. When you subclass with Square, this is no longer the case.
A client setting a width of 5 and a height of 10, whilst reference an object that happens to be a Square but is held in a Rectangle variable, will get different results according to the order in which they set the height and width properties. They might get a 5x5 rectangle or a 10x10 one. Either case will be unexpected.
There's Barbara's original complex description of LSP but Uncle Bob's makes it easier - "Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it". This is broken with the Square/Rectangle problem.
I wrote an article about this at http://www.blackwasp.co.uk/SquareRectangle.aspx.