Thread: OOP Design

I have a question regarding design of an application in an OOP sense...

In the case that I am creating a real time windows app (either a game or a graphical simulation) - I have a class which is the application class, CApp.

Now most of the action occurs in the windows procecure, in this case AppWndProc(). And I am unsure how to make the Graphics class (which is probably going to be called frequently in response the WM_PAINT messages) communicate with the rest of the program.

Now, my actual question is - what would be the best way to have the graphical part of the app interact with the windows procedure contained within the main app - would it be best to create an instance of the class as a private member of the CApp class? Or is it best to keep this object seperate?

Thanks

Code:

class CApp
{
private:
    CGraphics cg;

public:
     LRESULT CALLBACK AppWndProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam)
};

I make the graphics objects members of my window class.

The heirarchy I use is roughly:

Code:

struct rectangle {
};

struct windowbase : rectangle {
};

struct window : windowbase {
hbrush brush;
hbitmap bitmap;
hpen pen;
hfont font;
hmenu menu;
};

struct wndclassex : WNDCLASSEX {
};

struct application : wndclassex, window {
MSG msg;
};

Excellent, thanks for that - that is very helpful!

Actually, I have another question, (of course!) and it's related to the same app.

I have created a logging class, essentially it takes a string describing an error and writes it to a file along with a time stamp. It outputs the info with some formatting data to HTML.

Now - I new the methods in this class would probably end up being called by almost every object in the program. So I created the class with static methods (obviously never instantiating it) and called the methods using the scope resolution operator as such:

Code:

CLog::writeError("This is an error");

Is this normally the way that most people would deal with an object like this? I couldn't think of a way of allowing each object to communicate with the logging object without inheriting from it (which would mean many instances of the one class and a bit of code bloat). It would also mean I would be opening and reopenning the file many times creating a performance hit.

Originally posted by filler_bunny
Actually, I have another question, (of course!) and it's related to the same app.

I have created a logging class, essentially it takes a string describing an error and writes it to a file along with a time stamp. It outputs the info with some formatting data to HTML.

Now - I new the methods in this class would probably end up being called by almost every object in the program. So I created the class with static methods (obviously never instantiating it) and called the methods using the scope resolution operator as such:

Code:

CLog::writeError("This is an error");

Is this normally the way that most people would deal with an object like this? I couldn't think of a way of allowing each object to communicate with the logging object without inheriting from it (which would mean many instances of the one class and a bit of code bloat). It would also mean I would be opening and reopenning the file many times creating a performance hit.

You could make your error logging class a singleton and then just have the single global copy and use it everywhere.