What do you think?

[as96]

This is the header of the button:

#pragma once#include <memory>#include <SFML/Graphics.hpp>#include <SFML/System.hpp>#include "Command.h"#include <iostream>namespace GUI{	struct ButtonStyle	{		ButtonStyle(sf::Color buttonColor, sf::Color textColor) : ButtonColor(buttonColor), TextColor(textColor) {}		sf::Color ButtonColor;		sf::Color TextColor;	};	class Button	{	public:		Button(sf::RenderWindow* windowPointer, std::unique_ptr<Command> command);		Button(sf::RenderWindow* windowPointer, std::unique_ptr<Command> command, sf::Texture* texture);		Button(sf::RenderWindow* windowPointer, std::unique_ptr<Command> command, sf::Texture* texture, sf::String text);		Button(sf::RenderWindow* windowPointer, std::unique_ptr<Command> command, sf::Texture* texture, sf::String text, ButtonStyle style);		void SetEnabled(bool isEnabled);		bool IsEnabled();		void OnClick();		void OnMouseOver();		void OnMouseExit();		void Update();		void Draw();		void SetPosition(sf::Vector2f position);		sf::Vector2f GetPosition();	private:		sf::RenderWindow* mWindowPointer;		std::unique_ptr<Command> mCommand;		sf::Sprite mSprite;		sf::Text mText;		sf::Font mFont;		sf::Time mCDTime = sf::Time::Zero;		sf::Clock mCDClock;		bool mEnabled = true;		bool mMouseIn = false;	};}

This is an example of a "Command"

class MyCommand : public Command{public:	void OnClick() { std::cout << "MouseClick\n"; }	void OnMouseOver() { }	void OnMouseExit() { std::cout << "MouseExit\n"; }private:};

And this is what the result is:

Button myButton1(&window,std::unique_ptr<Command>(new MyCommand()),&buttonTexture, sf::String("Button"), ButtonStyle(sf::Color::White, sf::Color::Red));myButton1.SetPosition(sf::Vector2f(myButton1.GetPosition().x + 20.f, myButton1.GetPosition().y));

 

The "Command" class has just 3 pure virtual methods nothing more.

 

Any suggestions? Using a class for the events (the Command class) looked like a good idea at first now I'm not too sure though, what do you think?

[PetiteBob]

All that coding for a button. 

[as96]

All that coding for a button. 

Actually there is more, I didn't post the .cpp of the button class, it's not that much code though.

[as96]

If you guys want I can post the .cpp, it's not a problem.

[madknight3]

A better way might be to use interfaces and abstract classes. When controls have common functionality, they will likely implement some of the same interfaces or inherit some of the same abstract classes. 

 

To show an example, here's how .NET organizes things.

// The button class inherits ButtonBase and implements IButtonControlButton : ButtonBase, IButtonControl// The button base inherits ControlButtonBase : Control// Control inherits and implements lots of things and some of those also continue on with more stuffControl : // Lots of stuff// Some other things that inherit ButtonBase are Checkbox and RadioButton. But these don't implement IButtonControlCheckbox : ButtonBaseRadioButton : ButtonBase// Some things that inherit Control directly instead of ButtonBase areLabel : ControlListView : Control// And take LinkLabel, it inherits Label but also implements IButtonControlLinkLabel : Label, IButtonControl

So all of these classes have the functionality described in Control while only some of them need the functionality in ButtonBase or need to implement the methods in IButtonControl. 

[prolemur]

All that coding for a button. 

The code to even create a window is a lot larger than that if SFML wasn't used IIRC.

[FourBit]

Lot's of potential for other programs.

[manon_gfx]

I am not sure about your implementation of you constructors, but you could probably generalize them into 1 constructor using default parameters.

Personally I think it would be better to pass a pointer to the window in there draw function, since the data is (probably) not needed anywhere else. I like the data classes keep as small as possible. I am also not sure why your keep a time and clock object in your button.

Other than that, you gotta add some getters and setters for your texture, text, font, etc.

I like how you abstracted away what the button does with a command interface.

[as96]

I am not sure about your implementation of you constructors, but you could probably generalize them into 1 constructor using default parameters.

Personally I think it would be better to pass a pointer to the window in there draw function, since the data is (probably) not needed anywhere else. I like the data classes keep as small as possible. I am also not sure why your keep a time and clock object in your button.

Other than that, you gotta add some getters and setters for your texture, text, font, etc.

I like how you abstracted away what the button does with a command interface.

I need the pointer to the window to check the mouse position relative to it, it's not just for the draw function.