-
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.
-
Quote:
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.