   One WndProc per window?
  OK, so the tile editor I'm making has three windows, the main editor window, the tool window and one for tile selection. The editor window has two scroll bars, the tools window has 12 buttons and the tile window will have around 4 buttons (haven't done the UI for this window yet). Of course, all controls in Windows are windows. So, to process the interaction with these controls, I have to wrap them all within the one WndProc that is registered to my app's process. This is absurd! That is at least 21 windows, each sending events that need to be processed. All within one massive function. And that is not even taking the menus into account!There has got to be a better way. Is there a way to attach a WndProc to a window instead of the process? I know it can be done with dialogs, but I'm not dealing with dialogs (maybe I should be?).   
  The first argument to WndProc is the handle for your window -- you can use that to call a different event handling function for each window.   ;  First, you should have a different window class for each of your parent windows (the editor, the toolbox window, and the tile selector window). Since you specify the wndproc when calling RegisterClass or RegisterClassEx, this will allow you to divide up implementations into multiple wndproc functions. It's a good idea in general to use a different window class for each different window, since it makes things like this a lot easier to deal with.Secondly, your buttons/etc. shouldn't need a wndproc per button window. Instead, use the WM_COMMAND message, which triggers when a button or menu item is clicked. This means that you can handle all of your UI within the three wndprocs defined as outlined above.Finally, if you are thoroughly insane (or want to do something really clever) you can subclass a window by replacing its window procedure, using SetWindowLongPtr with GWLP_WNDPROC.   ;  I must have misunderstood the reason behind RegisterClass. I thought this registered the instance of the app with Windows.I am a little insane and I would love to look clever, so I may try the subclass method.Quote:Original post by ApochPiQSecondly, your buttons/etc. shouldn't need a wndproc per button window. Instead, use the WM_COMMAND message, which triggers when a button or menu item is clicked. This means that you can handle all of your UI within the three wndprocs defined as outlined above.I understand this. My point was that there are so many controls that a single WndProc would turn into an absurd, unwieldy mess.   ;Quote:Original post by maspeir My point was that there are so many controls that a single WndProc would turn into an absurd, unwieldy mess.Possibly, but that's usually an indication that you have an awful UI design that needs to be broken up into separate controls. Plus, you can always write functions (or member functions if you've shoved your windows into classes) and call them from the message handler cases.Win32 code is not exactly elegant given its primitive event-handling approach, but it shouldn't turn into a monstrosity unless you do Very Bad Things™.   ;Quote:Original post by OluseyiQuote:Original post by maspeir My point was that there are so many controls that a single WndProc would turn into an absurd, unwieldy mess.Possibly, but that's usually an indication that you have an awful UI design that needs to be broken up into separate controls. Plus, you can always write functions (or member functions if you've shoved your windows into classes) and call them from the message handler cases.Actually I couldn't break up the controls any more. There are 12 tools in the tool window, each is a single control. Same for the other windows. I cannot think of any other way to do this, short of writing my own GUI functions or using a library, neither of which I care to do.ApochPiQ gave me the solution though. I was unaware of exactly what RegisterClass did. Now that I know, it makes the process much easier.   ;Quote:Original post by maspeirActually I couldn't break up the controls any more. There are 12 tools in the tool window, each is a single control. Same for the other windows. I cannot think of any other way to do this, short of writing my own GUI functions or using a library, neither of which I care to do.ApochPiQ gave me the solution though. I was unaware of exactly what RegisterClass did. Now that I know, it makes the process much easier.Your second paragraph invalidates your first, though: since your approach was structurally wrong, the organizational difficulties you were struggling with were an artifact of your error, and not of limitations in Win32 (even though they do exist). That is, having used RegisterClass appropriately and distributed the event handling burden across the proper, separate window classes, do you still find your window procedure to be a huge mess?   ;Quote:Original post by ApochPiQFinally, if you are thoroughly insane (or want to do something really clever) you can subclass a window by replacing its window procedure, using SetWindowLongPtr  with GWLP_WNDPROC.You should only need to subclass a system window (i.e. control (i.e. button, label, etc)) if you wish to override the default behaviour of those controls.If you are just using those controls normally then you do not need to subclass anything. Just handle the WM_COMMAND messages in your window's WndProc as mentioned in ApochPiQ's second point.Of course, there are always alternatives to Windows UI programming. wxWidgets and Qt are two examples.   ;Quote:Original post by OluseyiYour second paragraph invalidates your first, though: since your approach was structurally wrong, the organizational difficulties you were struggling with were an artifact of your error, and not of limitations in Win32 (even though they do exist). That is, having used RegisterClass appropriately and distributed the event handling burden across the proper, separate window classes, do you still find your window procedure to be a huge mess?No, by registering a class for each window, I can split up the WndProc between the three main windows. This eliminates the issues of trying to cram the functionality of 21+ controls/windows into one function. As I stated, I was unaware that this was possible due to not understanding the RegisterClass function.My first paragraph was in response to your post where you said I need to break up the UI into separate controls. I had already done that (by having 21 controls/windows), but they were all linked to the same class. It is possible I did not understand what you meant by breaking up the UI.   ;  I made buttons their own class.  They're registered to the parent window and are handled inside that windows procedure class (that you've registered properly).  This way, you can "add" a button (or hundreds) and not have a larger function in the WndProc.  It just calls the buttons function, clicked() or whatever you wish to call it.  Then just program that function and away you go.  Your WM_COMMAND could be a few lines long total then.   