The same handler could be assigned to multiple windows or controls, so unless the programmer chooses to create a new handler for each object that needs one, it would be O(N+M). Refernce counting like with facets would be a good thing, though if there are construction/destruction events then ref counting could be tied to that (depending on how control specific data is associated). The call on f is to set up the functions, not signal an event. That constructor is for static objects so all the events can be set without passing all the functions as parameters. Each event would pass the target along with the message data, similar to how the window procs for WIndows receive the HWND of the reciever of the message. Regarding extensibility, the handler is meant to deal with system messages; therefore at best for custom messages there would be a way to install translators that would convert unknown messages into generic events such as command and notify (message flow: system -> standard or custom translator -> event handler -> application). This is because the code processing the system messages would need to know how to format the data for the event handler, and if it cannot then the ability to add custom events to the handler would be useless. Furthermore it seems redundant to me to have both custom translations and custom event types. The reason behide dynamically creating the handler is because other than having the handler be a virtual class no method of creating it at compile time comes to mind, and I was trying to find a better way because it seems that many feel that is not good enough (or at least with some implementations of it like in MFC). Would you care to suggest a way?