GuiControl.OnNotify()

[just me]

Code: Select all

	case WM_NOTIFY:
	{
		if (   !(pgui = GuiType::FindGui(hWnd))   )
			break; // Let DefDlgProc() handle it.

		NMHDR &nmhdr = *(LPNMHDR)lParam;
		if (!nmhdr.idFrom)
		{
			// This might be the header of a ListView control.  Although there may be some
			// risk of notification codes being ambiguous for custom controls (between the
			// actual control and any child controls), the ability to monitor a ListView's
			// header notifications seems useful enough to justify the risk.
			control_index = pgui->FindControlIndex(nmhdr.hwndFrom);
		}
		else
		{
			control_index = (GuiIndexType)GUI_ID_TO_INDEX(nmhdr.idFrom); // Convert from ID to array index.  Relies on unsigned to flag as out-of-bounds.
		}

I agree that it's useful to be able to monitor the header notifications, but it should be optional. E.g. in case of NM_CUSTOMDRAW both the list-view and the header are sending WM_NOTIFY messages while you resize a column. It results in many needless handler calls if you want to handle only notifications sent by the list-view. Also, this technique isn't used for OnCommand() so don't get notifications sent by the list-view's edit child.

When I suggested OnCtrlNotification() I assumed it would be implemented as an addition to the existing message monitor. I still prefer solution not depending on a GuiControl. GuiControl.OnCommand() and GuiControl.OnNotify() could be preserved as 'syntax sugar', though.

[lexikos]

Events are registered on the GuiControl object because:

• Event registration is primarily designed and intended for the named events (built into the GUI system), not general messages.
• It reduces the number of message monitors that the program must search through when receiving any arbitrary message.
• It ensures handlers are never left behind after a control/window is destroyed (which could cause issues in the event that a HWND value is recycled by the system).

I may consider your comments at a later date. At the moment I'm rather biased by lack of interest.