7 replies to this topic

[Buttacup]

I'm creating a Toolbox and filling it with Tools. Each Tool has it's own methods and achieves it's goals differently but I want to house them all in Toolbox. So I've created a parent class CTool from which all child classes inherit. The properties of Tool are defined within the child class. Upon construction all Tool types assign their enumerated type within the parent. I store all of the tools as base type pointers within Toolbox. When I access them I call a function which checks type and downcasts the Tool into it's child and calls for execution();

So am I really going about this the wrong way?

Should I be looking at creating interfaces?

What is the more standard approach to this problem within C++/VC++?

:p


CToolBox.h

#ifndef C_TOOLBOX
#define C_TOOLBOX

#if _WIN32
#pragma once
#endif

#include "NMMain.h"
#include "CTool.h"
#include "2DLocker.h"

#define TOOLSET_SIZE 32

class CToolset
{
private:
	vector<CTool*>			Drawer;
public:
	CToolset(){Drawer.reserve(TOOLSET_SIZE);};

	void 					PutInDrawer(CTool* store){Drawer.push_back(store);};
	void 					RemoveFromDrawer();
	UINT					ReturnSize(){return Drawer.size();};
	CTool*					CheckoutTool(UINT ptr){ return Drawer.at(ptr);};
};

class CToolBox
{
private:
	HRESULT					ActivateTool();
	HRESULT					LoadTB();

public:
	CToolBox(UI_TOOLBOX_ID ident) : UI_TB_ID(ident) {LoadTB();}
	HRESULT					MouseActivityTB(SMouseStroke*, CToolBox*);

	POINT					GetObjToolboxHandle(){return objToolboxHandle;};
	POINT					GetPntBoundingBox_1(){return pntBoundingBox_1;};
	POINT					GetPntBoundingBox_2(){return pntBoundingBox_2;};

private:
	UI_TOOLBOX_ID			UI_TB_ID;

	CToolset				Toolset;

	C2DModel 				tb_surface;
	POINT					objToolboxHandle;
	POINT					pntBoundingBox_1;
	POINT					pntBoundingBox_2;

	CTool*					ToolActive;
};

class CNonActiveToolbox : public CToolBox
{
public:
	CNonActiveToolbox() : CToolBox(UI_DEFAULT) {}
	bool					isDevToolActive;
};

class CUserInterfaceEditor : public CToolBox
{
public:
	CUserInterfaceEditor() : CToolBox(UI_DEV_TOOL) {}

	HRESULT 				SaveUI();
	HRESULT 				DeleteUI();
	HRESULT 				RenameUI();
	HRESULT 				SaveToolBox();
	HRESULT 				DeleteToolBox();

public:
	bool 					isActive;
};

#endif

CToolBox.cpp

#include "CToolBox.h"

HRESULT CToolBox::LoadTB()
{
	HRESULT hr = S_OK;;

	Toolset.PutInDrawer(new CToolPoly);
	ToolActive = Toolset.CheckoutTool(0);

	return S_OK;
}

HRESULT CToolBox::MouseActivityTB(SMouseStroke* ptrMouseStroke,CToolBox* ToolboxHit)
{
	HRESULT hr = S_OK;;

	if(ToolboxHit == NULL && ToolActive != NULL)
		ToolActive->Execute();
	else if(ToolboxHit == this && ToolActive == NULL)
		ActivateTool();

	return S_OK;
}

CTool.h

#ifndef C_TOOL
#define C_TOOL

#if _WIN32
#pragma once
#endif

#include "NMMain.h"

class CTool
{
private:
	UI_TOOL					UI_T_ID;

public:
	CTool(UI_TOOL ident) : UI_T_ID(ident) {}

	HRESULT					Execute();
	//POINT					pointOnClick;
};

class CToolPoly : public CTool
{
public:
	CToolPoly() : CTool(TOOL_POLY){}
	HRESULT					PerformDuties();
};

#endif

CTool.cpp

#include "CTool.h"

HRESULT CTool::Execute()
{
	switch(this->UI_T_ID)
	{
		case TOOL_POLY:
			static_cast<CToolPoly*>(this)->PerformDuties();
			break;
	}
}

[ZekeDragon]

You apparently want all tools to have the Execute method, correct? If that's not the case, just inherit an interface-like object called "CTool" and keep them separate. I'd do the tool this way:

class CTool
{
public:
	CTool(UI_TOOL ident) : UI_T_ID(ident) {}

	virtual HRESULT				Execute() = 0;
	//POINT					pointOnClick;

private:
	UI_TOOL					UI_T_ID;
};

You'd then implement Execute in each of the implementers of this, what is essentially an Interface, class (it actually isn't, since it requires a constructor that takes in a UI_TOOL enum type).

class CToolPoly : public CTool
{
public:
	CToolPoly() : CTool(TOOL_POLY) {}

	HRESULT					Execute();
};

I'm just saying for the reasons you thus far are using UI_T_ID, you don't need it. However, there may be other situations where some reflection is very useful, so I wouldn't drop the idea completely, namely when you'd pass a pointer to a CTool to a function that treats them generically, and might need to treat some specifically. I think considering what you want to do (IE each tool can be treated similarly, but perform different actions) is absolutely perfect for an interface, it's what they were meant to do. Just remember that it may be difficult to determine which objects you need to use, especially with that toolbox class which offers NO assistance in figuring out what object does what. Keep them as modular as possible, unless you really need a container for them, I wouldn't make one yet.

That's just me though. :P

[Buttacup]

Yeah tough decisions, thanks for the input you! :)

[Buttacup]

I'm reading off of this looking at as much as I can about how to make and use interfaces. One thing I'm having a hard time understanding is the exact purpose of declaring

class MyClass : implements MyInterface

??

Getting the basic concepts down as pointed out by ZekeDragon was fairly easy and simple. I found this article particularly helpful. I do however find the manipulation of the data into a fabricated interface model for c++ quite intriguing and am trying to understand all that is being done in the first linked article. It is as always probably something very simple that I'm missing! What exactly does implement do with regards to interfaces as, correct me if I'm wrong, interfaces is not entirely the task for which implements was created....... :)

[WingedPanther]

The first article... *shudder*. The C++ concept of an interface is a pure abstract class with no member variables, just methods. It defines what functions will be offered, but NOT how they will be implemented or what data will be stored to offer them.

The second article is much better, IMHO, as it doesn't try to make C++ look like other languages. Also, #define's always stand out as a red flag to me.

[Buttacup]

Yes! And I noticed that implements was #defined in this article. However in VC++ it is already defined; I may be missing something here.... And as so implements is even within the MSDN Library, yus! So I read this little tidbit about the implements attribute as defined by MSDN and is says this "Specifies dispatch interfaces that are forced to be members of the IDL coclass." Now I kind of sort of have an idea of what this is saying but what does this mean that it is doing. In article #1 implements was simply #defined as public but now correct me if I'm wrong VC++ has it defined as something more. Is it? And if so how is it something more?

[WingedPanther]

VC++ has some non-standard extensions to the C++ language. Short version, if you use those extensions, they won't be cross-platform compatible code.

Basically, an interface is just inheritance where you have additional methods you need to define.

[Buttacup]

So then IDL(Interface Definition File/Language) as a whole is Microsoft Platform specific?

Quote

The IDL interface header specifies information about the interface as a whole. Unlike the ACF, the interface header contains attributes that are platform-independent.

-MSDN

[edit] Looking around that was a rather silly question...... I think I found enough stuff to get me going so I is going to run away again. :)