Custom WinAPI Control: subclass, owner-draw or custom class?

Started by
0 comments, last by Amr0 7 years, 11 months ago

I am attempting to create a unique WinAPI control and I am struggling to pick the best/least effort intensive solution to create it.

Its essentially a Horizontal Listbox (HLB) of WinAPI Button controls (see the control at the bottom of the following image). The user scrolls the HLB by left mouse button down (anywhere inside the HLB HWND) and moving the mouse horizontally anywhere (even outside the HWND bounds). The buttons have up, down and hover skins/images.

2LYQr.jpg

Each solution has its drawbacks, maybe there is a Common Control I dont know about that I could subclass?

Solution 1: Sub-class a static control as the HLB.

- Make the subclassed static control the parent of each of the buttons and space out horizontally

- Static controls can't have scroll bars (AFAIK) or atleast they don't receive scroll messages.

- Set the buttons skins using Button_SetImageList().

- Buttons steal the focus. Meaning if the user left clicks down on the button and mouse moves with the intention of horiz scrolling the HLB, the HLB wont receive any mouse move messages because they all get dispatched to the button until left mouse button up is fired. I guess I could also subclass the buttons to dispatch their mouse messages to the HLB - unless there is a better method you can suggest?

- Horiz scrolling will only work when the scroll bar is clicked and dragged. If the user clicks inside the main HLB HWND no scrolling events are fired.

Solution 2: Use a Pager control? Not exactly sure this will work.

- Pager should align and space out the buttons for me which is good.

- Unsure if the control allows for horiz scrolling by clicking inside the Pager HWND and dragging the mouse? Do you know?

- The Pager has arrows on the left and right of the control (to scroll left and right). Is it possible to hide these?

Solution 3: Create my own Owner Drawn window and draw the buttons also (so they wont be WinAPI Button controls).

- Requires me to do lots of hit testing and painting; 'Is the mouse over button x and is left mouse button down: paint down image to specific region', same again for hover, have to detect WM_MAXIMIZE, WM_MINIMIZE and repaint the window, detect WM_SIZE and rescale buttons. Ie lots of work.

- I can rather easily detect when the user intends to scroll and when they intend to click a button because all events are sent to the one HWND.

Solution 4: Sublcass a Scroll Bar and add WinAPI buttons to that

- Not very familiar with these controls. Any advice? Can you see any problems I could run into?

Solution 5: Make the HLB a custom class window and add WinAPI buttons to it

- This is the solution I am tending towards. I add a scroll bar to this control (and hide it). Add buttons to it.

- I run into the same problem of buttons stealing the focus.

Any advice how you would implement this?

Advertisement

I'd go with a completely custom class, and I'd not use native buttons inside the control and instead have the control draw the buttons itself, just like a list box draws the items itself. Implementing hit-testing for such a simple item layout is trivial, especially if the buttons are equally sized. The same can be said about drawing the items.

But what you seem to want to implement is exactly a toolbar, but scrollable. How is that better than a native toolbar with a chevron for example?

This topic is closed to new replies.

Advertisement