Custom Objects Accessible by Many Forms

kialmur

I am trying to create a GUI for a C++ application using Visual Studio 2005, which I am new to. The GUI has one main form and several minor forms that all need access to an object, not GUI related, that I created. What is the best way to make this object accessible to all forms? Should I pass a pointer to it in the constructor of each form? Should I create a global object that the forms can refer to? Or does Visual Studio have some built in mechanism to share that ressource? I would appreciate any suggestions and help. kialmur

led mike

You have been at this for two weeks now. You should be posting information about what you have tried along with how and why it did not work as expected. Off by one thread error :-D

Last modified: Friday, June 30, 2006 10:22:50 AM -- posting error by user - led mike

Zac Howland

The short answer is: You can pass it any way you want to. The long answer is: There are some good ways, and some bad ways of doing this depending on what you are trying to do. If you can be more specific about the architecture (e.g. are the forms/dialogs that need access to this object going to be writing to it, or just reading from it? are they only going to need part of the information for each dialog? etc), more details can be given about how you might want to implement it. If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac

led mike

Now I am responding to your post. :) Take a look at the Model-View-Controller Design Pattern[^]

kialmur

I basically used the standard Windows forms project to start off. The .cpp, with the main(), that Visual Studio automatically creates is used to run the thread that launches my main form. The main form allows me to modify and view the status of my object, which interacts with various hardware cards and other. From that form, I have one sub-layer of forms that allow me to modify specific aspects of the object. Each form, except the main one, typically modifies or views information about one portion of the object, such as a card it interacts with. So I need to both write and read from the object within both layers of forms. To answer the post of the next person, I have already separated my application based on the Model-View-Controller pattern. I simply do not know how to give access to the object to each form, since each form is a class. I hope this helps you in answering me. I am hoping you will be able to suggest one of the good ways to give access. Thanks in advance. kialmur

led mike

kialmur wrote:

To answer the post of the next person, I have already separated my application based on the Model-View-Controller pattern. I simply do not know how to give access to the object to each form, since each form is a class.

So each form is a "view" in the design and uses the "controler" to send messages into the other isolated objects in the design.

kialmur wrote:

So I need to both write and read from the object within both layers of forms.

Well not directly that is why you have the MVC design. The forms don't know about the object just the controller and events. So the forms call methods of the controller which results in the "write" operations. Some other object(s) should be performing the "read" operations which then results in an "event" that the forms can subscribe to. The event can contain the data directly or the data can be sent into the "model" in the design at "read" time and then when the form event handler fires it can access the data through the "model" object. Does that help?

kialmur

I understand what you are saying about the controller. However, how do I access the controller functions from the forms. If I wrap them in a class, they become hard to access from the forms because I have to pass a pointer to the class object or use some other method. I can make the functions public, but I would prefer not to, naturally. How do I make my controller functions available to my forms in Visual Studio or any other software? kialmur

led mike

That depends on your use model. In some use models controllers can just be instantiated whenever needed by the "view", other use models might require a Singleton design. With most good designs passing pointers about is rarely necessary.

Zac Howland

One way to to this is to create a set of abstract classes (aka interfaces), have your object class implement the methods for those interfaces, and pass a pointer to the proper interface to the respective dialog (either at construction, or via a member function). For example:

class IPersonalInfo
{
public:
	void setName(const std::string& name) = 0;
	void setAddress(const std::string& addr) = 0;

	const std::string& getName() const = 0;
	const std::string& getAddress() const = 0;
};

class IFavoriteMovie
{
public:
	void setMovie(const std::string& movie) = 0;

	const std::string& getMovie() const = 0;
};

class MyData : public IPersonalInfo, public IFavoriteMovie
{
public:
	MyData() : _Name(""), _Address(""), _FavMovie("")
	{}

	// implement the IPersonalInfo interface
	void setName(const std::string& name)		{ _Name = name; }
	void setAddress(const std::string& addr)	{ _Address = addr; }
	const std::string& getName() const 		{ return _Name; }
	const std::string& getAddress() const		{ return _Address; }

	// implement the IFavoriteMovie interface
	void setMovie(const std::string& movie)		{ _FavMovie = movie; }
	const std::string& getMovie() const		{ return _FavMovie; }

private:
	std::string _Name;
	std::string _Address;
	std::string _FavMovie;
};

// Main Dialog has MyData object
class CMainDialog : public CDialog
{
...
private:
	MyData _MyData;
};

// Each child dialog gets a pointer to proper interface
class CPersonalInfoDialog : public CDialog
{
public:
	CPersonalInfoDialog(IPersonalInfo* pInfo);
...
};

class CFavoriteMovieDialog : public CDialog
{
public:
	CFavoriteMovieDialog(IFavoriteMovie* pInfo);
...
};

The dialogs would operate on your data via the interfaces. There are other ways of doing it, and all have their pro's and con's. If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac

kialmur

Thanks. I cannot simply reinstantiate a new controller each time, but the Singleton design works for me. kialmur