Digging Deeper

Entry posted by Josh · October 16, 2016

1,781 views

The general GUI elements for LeadwerksGUI are more or less done, and I have turned my attention to another problem. The LeadwerksGUI system is built around the notion that GUI widgets have a discrete bounding box in which they are contained. All events and drawing occur within these bounds, which are further constrained by either their parent widget's bounds or the area of the window they are created on. However, there are three situations where this paradigm breaks down.

Menus

Window menus expand when clicked on, and the submenu stretches depending on the number of menu items it contains. Furthermore, the menu may extend below the bottom edge of the window. This indicates that the menu itself must be another window that is parented to and moves with the parent. However, clicking on the menu would normally deactivate the parent, which is not the desired behavior. To get around this, I made the window class process return MA_NOACTIVATEANDEAT when a WM_MOUSEACTIVATE event occurs, for this type of window.

Dropdown Boxes

Dropdown boxes are similar to menus. In fact I think the Windows API creates menus as a special form of dropdown boxes. The same rules apply here.

Tool Tips

Tool tips can appear anywhere and can extend beyond the bounds of the parent window. Furthermore, tool tips do not gain the mouse focus and allow mouse events to pass through to the underlying window. At least I think they do. In practice, the tool tip will disappear as soon as you move the mouse off the hovered widget, so it should be impossible to ever click on them anyways. However, I did find a method of allowing mouse events to pass through the tool tip window to the window below. On Windows you can make mouse events pass through a window by returning HTTRANSPARENT when an WM_NCHITTEST event occurs.

So here's an unimpressive shot of a window with another window on top of it (the black rectangle on the top left). It's not visually amazing, but it is working.