Pointer to class functions
Author
I've got a question regarding pointers to class functions.
I've written a simple GUI for my engine. It supports callbacks for several events (onclick, onmousover, etc...). The GUI along with my engine is inside a spererate dll. My application then creates the GUI from within another the module. But this way prevents the usage of templates within the GUI, because it just doesn't know the classes of the application.
Is there a way to call functions to unknown classes from within the GUI & engine module? Maybe I could provide a basic class that will be inherited by the classes of my application, but I'm unshure if it's a good idea.
Author
But to use template based function pointers, the GUI also needs the declaration of the called class & function, doesn't it?
when setting your callback, you will just have to create a functor object via boost::function and bind it's first parameter to the instance of the class on which it operates. Your GUI subsystem just get a functor and does not have to know anything about the underlying class.
To call a classes member function you need the address of the function and an instance of the class on which the function is to be called. Is that what you mean?
Author
Quote:Original post by DaveTo call a classes member function you need the address of the function and an instance of the class on which the function is to be called. Is that what you mean?
I'm worried about that I can't call the function of a class, of wich I don't know the declaration.
Quote:Original post by Mawww
when setting your callback, you will just have to create a functor object via boost::function and bind it's first parameter to the instance of the class on which it operates. Your GUI subsystem just get a functor and does not have to know anything about the underlying class.
Ok, I'll try this out. Would be perfect in my case, thanks :)
You cannot call if you don't know the declaration... no of parameters return type.
'->*' and '.*' operators
http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/com.ibm.vacpp6m.doc/language/ref/clrc13cplr034.htm
'->*' and '.*' operators
class C{ int Foo(char*){...};};typedef int (C::*p_FN)(char*);main(){ C c; C* pc = &c; p_FN ptr2foo=C::Foo; // // to call you need a ptr to the obj // ((pc)->*(ptr2foo))("bla"); // //or // ((c).*(ptr2foo))("bla");}http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/com.ibm.vacpp6m.doc/language/ref/clrc13cplr034.htm
What I do for my engine GUI is very simple, and does not require any explicit function pointers for event handling.
I just have one class, Screen (you can call it Widget if you like), which has virtual functions like Render, Update, OnDeserialize, OnSerialize, OnMove, OnSize, OnMouseMove, OnLButtonDown, OnKeyDown, OnKeyPress, etc.
The engine calls those virtual functions in response to events. Render() is called from Engine::Render, Update is called from Engine::Update, OnMove is called when Screen's position gets modified; OnMouseMove, OnKeyDown and other input events are called by code in EngineWndProc (because engine subclasses client window). In the Screen class, default processing is done in response to those events.
However, the client can choose to subclass that Screen class, and create, for example ScreenTextbox. Then client can overload OnKeyDown virtual function to make the text box respond to key down events, and client could also overload Render virtual function to draw textbox's visible text. Because ScreenTextbox will also be referrable to as Screen, you can give Engine the pointer to ScreenTextbox and it will call virtual functions as if nothing happened. But, when those virtual functions are called, your handler code ends up being executed, instead of the default code in Screen.
I just have one class, Screen (you can call it Widget if you like), which has virtual functions like Render, Update, OnDeserialize, OnSerialize, OnMove, OnSize, OnMouseMove, OnLButtonDown, OnKeyDown, OnKeyPress, etc.
The engine calls those virtual functions in response to events. Render() is called from Engine::Render, Update is called from Engine::Update, OnMove is called when Screen's position gets modified; OnMouseMove, OnKeyDown and other input events are called by code in EngineWndProc (because engine subclasses client window). In the Screen class, default processing is done in response to those events.
However, the client can choose to subclass that Screen class, and create, for example ScreenTextbox. Then client can overload OnKeyDown virtual function to make the text box respond to key down events, and client could also overload Render virtual function to draw textbox's visible text. Because ScreenTextbox will also be referrable to as Screen, you can give Engine the pointer to ScreenTextbox and it will call virtual functions as if nothing happened. But, when those virtual functions are called, your handler code ends up being executed, instead of the default code in Screen.
Author
Quote:Original post by gyula
You cannot call if you don't know the declaration... no of parameters return type.
'->*' and '.*' operators
*** Source Snippet Removed ***
http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/com.ibm.vacpp6m.doc/language/ref/clrc13cplr034.htm
That's not entirely true. It's possible: this proves it.
I've just implemented it. Works great.
Quote:Original post by ValMan
What I do for my engine GUI is very simple, and does not require any explicit function pointers for event handling.
I just have one class, Screen (you can call it Widget if you like), which has virtual functions like Render, Update, OnDeserialize, OnSerialize, OnMove, OnSize, OnMouseMove, OnLButtonDown, OnKeyDown, OnKeyPress, etc.
The engine calls those virtual functions in response to events. Render() is called from Engine::Render, Update is called from Engine::Update, OnMove is called when Screen's position gets modified; OnMouseMove, OnKeyDown and other input events are called by code in EngineWndProc (because engine subclasses client window). In the Screen class, default processing is done in response to those events.
However, the client can choose to subclass that Screen class, and create, for example ScreenTextbox. Then client can overload OnKeyDown virtual function to make the text box respond to key down events, and client could also overload Render virtual function to draw textbox's visible text. Because ScreenTextbox will also be referrable to as Screen, you can give Engine the pointer to ScreenTextbox and it will call virtual functions as if nothing happened. But, when those virtual functions are called, your handler code ends up being executed, instead of the default code in Screen.
That's a good design, but I would need to rewrite a lot of code, 'cause my system is totally different. I'll just stick to functors, they're perfect in my case.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
