Connecting Windows Messages/Events with Boost callbacks
Hi, I recall sometime back someone posted this question on this list and the response/answer was very good. Could someone please provide link to that earlier post? Or, alternatively, could you please post the solution again? Best regards / Asif
I recall sometime back someone posted this question on this list and the response/answer was very good. Could someone please provide link to that earlier post? Or, alternatively, could you please post the solution again?
What are "boost callbacks"? You can use portable idiom of condition_variable instead of windows-specific events.
Hi Igor, I meant that somehow the Windows events were connected to user defined functions using boost::bind or something like that. I have been trying very hard to find that post but without any success so far. Will be thankful if anyone could provide a link to that post or an alternative/better solution. Would you elaborate as to what you mean by portable idiom of "condition_variable"? Do you mean the condition variables that we normally use in threads? I don't understand this part. Best regards, Asif On Wed, Mar 23, 2011 at 12:02 AM, Igor R <boost.lists@gmail.com> wrote:
I recall sometime back someone posted this question on this list and the response/answer was very good. Could someone please provide link to that earlier post? Or, alternatively, could you please post the solution again?
What are "boost callbacks"? You can use portable idiom of condition_variable instead of windows-specific events. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
I meant that somehow the Windows events were connected to user defined functions using boost::bind or something like that.
Are you sure you're talking about Windows events? Events are just synchronization objects, they are not connected to any code. http://msdn.microsoft.com/en-us/library/ms682396(v=vs.85).aspx
On Thu, Mar 24, 2011 at 6:13 AM, Igor R <boost.lists@gmail.com> wrote:
I meant that somehow the Windows events were connected to user defined functions using boost::bind or something like that.
Are you sure you're talking about Windows events? Events are just synchronization objects, they are not connected to any code. http://msdn.microsoft.com/en-us/library/ms682396(v=vs.85).aspx
I think he is talking about the windows message loop. http://en.wikipedia.org/wiki/Message_loop_in_Microsoft_Windows John
Hi John, Yes, exactly. Windows messages (I want to avoid having to write long case statements in message loops) - that's what I mean. I'd be thankful if anyone could point me to the right direction. Thank you very much, Asif On Thu, Mar 24, 2011 at 3:26 PM, John Drescher <drescherjm@gmail.com> wrote:
On Thu, Mar 24, 2011 at 6:13 AM, Igor R <boost.lists@gmail.com> wrote:
I meant that somehow the Windows events were connected to user defined functions using boost::bind or something like that.
Are you sure you're talking about Windows events? Events are just synchronization objects, they are not connected to any code. http://msdn.microsoft.com/en-us/library/ms682396(v=vs.85).aspx
I think he is talking about the windows message loop.
http://en.wikipedia.org/wiki/Message_loop_in_Microsoft_Windows
John _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Yes, exactly. Windows messages (I want to avoid having to write long case statements in message loops) - that's what I mean. I'd be thankful if anyone could point me to the right direction.
// pseudo-code! // Lets say it's a botton; switch(message) { case WM_LBUTTONDBLCLK: onDoubleClick(message); break; //... }; // member function void onDoubleClick(Message message) { doSomething(message); onDoubleClick_(arg1, arg2); } // member boost::signals2::signal<void(Arg1, Arg2)> onDoubleClick_; Now multiple listeners of your button can connect the signal: struct Handler { void onDoubleClick(Arg1 a1, Arg2 a2); }; button->onDoubleClick.connect(boost::bind(&Handler::onDoubleClick, handler, _1, _2)); This's only a sketch, in real code hou have to care about proper encapsulation, appropriate arguments etc.
Hi Igor, Thank you very much. The thing that I don't understand is that how folks such as those from SmartWin++ are able to seemlessly connect functions with Windows messages without using a case statement in a message loop. An example is at the following page: http://smartwin.sourceforge.net/getting_started.php Using your approach, I need to use a case statement inside a message loop. That's what I don't want to do. I am familiar with CRTP that SmartWin++ folks seem to have used as deriving new classes is very easy and the resulting code is very clean. So, I can at least imagine the design behind this library. But I wonder if they have written such case statements in message loops under the hood for every single GUI element. Someone on Boost Users mailing list did provide a solution to this a few months back (I do recall but cannot seem to find that post - I starred it in my thunderbird inbox but I have lost my inbox backup - I can scan the whole boost users list but I have limited time available to accomplish what I want). Best regards, Asif On Thu, Mar 24, 2011 at 4:02 PM, Igor R <boost.lists@gmail.com> wrote:
Yes, exactly. Windows messages (I want to avoid having to write long case statements in message loops) - that's what I mean. I'd be thankful if anyone could point me to the right direction.
// pseudo-code!
// Lets say it's a botton; switch(message) { case WM_LBUTTONDBLCLK: onDoubleClick(message); break; //... };
// member function void onDoubleClick(Message message) { doSomething(message); onDoubleClick_(arg1, arg2); }
// member boost::signals2::signal<void(Arg1, Arg2)> onDoubleClick_;
Now multiple listeners of your button can connect the signal:
struct Handler { void onDoubleClick(Arg1 a1, Arg2 a2); }; button->onDoubleClick.connect(boost::bind(&Handler::onDoubleClick, handler, _1, _2));
This's only a sketch, in real code hou have to care about proper encapsulation, appropriate arguments etc. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On Thu, Mar 24, 2011 at 8:16 AM, asif saeed <asif.lse2@gmail.com> wrote:
Hi Igor,
Thank you very much.
The thing that I don't understand is that how folks such as those from SmartWin++ are able to seemlessly connect functions with Windows messages without using a case statement in a message loop. An example is at the following page:
I would look at the source. To me it looks like SmartWin++ is using boost signals but I did not dig too deeply into the source since I am at work.. http://smartwin.cvs.sourceforge.net/viewvc/smartwin/SmartWin/ John
The thing that I don't understand is that how folks such as those from SmartWin++ are able to seemlessly connect functions with Windows messages without using a case statement in a message loop. An example is at the following page:
Where do you windows messages there? All the message processing is hidden inside the framework.
Using your approach, I need to use a case statement inside a message loop.
As you can see, struct Handler in my example doesn't have any case statements as well. Again: the basic, lowlevel message processing is hidden - in my example in the "button" class, in smart win++ somewhere in WidgetWindow or its base classes. The *users* of the framework do not need to deal with messages as the framewotrk exposes higher-level facilities.
On Thursday, March 24, 2011 8:42 AM, Igor R wrote:
Using your approach, I need to use a case statement inside a message loop.
As you can see, struct Handler in my example doesn't have any case statements as well. Again: the basic, lowlevel message processing is hidden - in my example in the "button" class, in smart win++ somewhere in WidgetWindow or its base classes. The *users* of the framework do not need to deal with messages as the framework exposes higher-level facilities.
Perhaps you can replace the switch statement with a map or similar (warning: untested): typedef std::map <UINT, boost::signals2::signal <LRESULT (HWND, UINT, WPARAM, LPARAM)> MessageMap; MessageMap message_map; LRESULT CALLBACK WindowProc( __in HWND hwnd, __in UINT uMsg, __in WPARAM wParam, __in LPARAM lParam ) { MessageMap::const_iterator handler = message_map.find (uMsg); if (handler != message_map.end()) { return handler->second (hwnd, uMsg, wParam, lParam); } else { return DefWindowProc (hwnd, uMsg, wParam, lParam); } } You could then insert any handler for any message into message_map. I'm not sure what combiner would be most appropriate here. There is also the question of where message_map should really go. A global variable (as my example implies) probably isn't the best place.
Hi Andrew, Thank you for giving me a good example. Though I haven't yet bothered to look into the SmartWin++ source code but I suspect they have done something more smarter. Thank you all. -Asif On Thu, Mar 24, 2011 at 7:12 PM, Andrew Holden < aholden@charteroaksystems.com> wrote:
On Thursday, March 24, 2011 8:42 AM, Igor R wrote:
Using your approach, I need to use a case statement inside a message loop.
As you can see, struct Handler in my example doesn't have any case statements as well. Again: the basic, lowlevel message processing is hidden - in my example in the "button" class, in smart win++ somewhere in WidgetWindow or its base classes. The *users* of the framework do not need to deal with messages as the framework exposes higher-level facilities.
Perhaps you can replace the switch statement with a map or similar (warning: untested):
typedef std::map <UINT, boost::signals2::signal <LRESULT (HWND, UINT, WPARAM, LPARAM)> MessageMap; MessageMap message_map;
LRESULT CALLBACK WindowProc( __in HWND hwnd, __in UINT uMsg, __in WPARAM wParam, __in LPARAM lParam ) { MessageMap::const_iterator handler = message_map.find (uMsg); if (handler != message_map.end()) { return handler->second (hwnd, uMsg, wParam, lParam); } else { return DefWindowProc (hwnd, uMsg, wParam, lParam); } }
You could then insert any handler for any message into message_map. I'm not sure what combiner would be most appropriate here. There is also the question of where message_map should really go. A global variable (as my example implies) probably isn't the best place. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On Friday, March 25, 2011 12:52 AM, asif saeed wrote:
Thank you for giving me a good example. Though I haven't yet bothered to look into the SmartWin++ source code but I suspect they have done something more smarter.
I agree. I was trying to put together a very rough proof of concept. It would take a lot of work to make a real product out of it. To start, it would need a way to give each window its own map (dynamic allocation and SetWindowLongPtr comes to mind and the logic needed to destroy the map when the window closes). It would also need a way to make the slots easier to use, perhaps helper functions that use bind, lambda, or phoenix to convert the WPARAM/LPARAM pair to meaningful parameters.
Hi Igor, Thank you for replying yet again. On Thu, Mar 24, 2011 at 5:42 PM, Igor R <boost.lists@gmail.com> wrote:
All the message processing is hidden inside the framework.
Basically, I want to use this library but it (and some of its examples) is not building on the Express version of Visual C++ 2010. Yesterday, I built it using the Ultimate version and it built perfectly fine without any problems. They *are* using boost and I really like their design and wish if were available on *nix as well. If I did embark on writing my own library, I'd try to do it like these guys have done it. The *users* of the framework do not need to deal with messages as the
framewotrk exposes higher-level facilities.
Yes. Thanks. -Asif
participants (4)
-
Andrew Holden -
asif saeed -
Igor R -
John Drescher