Windows messaging system

How I understand windows messaging system

I have taken a look to MFC, WTL frameworks and desided to explain some moments aligned to window creation and user interaction on Windows API level

Creating  a Window

To create window in Windows OS you call CreateWindow(className,...)
There is a enum of predefined classes
COMBOBOX, BUTTON, STATIC, LISTBOX and other default classes

As far as thay are already pressent in the system they asosiated with WindowProc. Actually every window class is asociated with windowProc inside OS.
What is window proc? it is just a function like below


INT_PTR CALLBACK MyDialog_DialogProc( HWND hwnd,
UINT messageId,
WPARAM wParam,
LPARAM lParam )


WindowProc is responsible for the window message processing. Thats why BUTTON for example looks like button :) , so to create a dialog not from window resources you need. To understand how OS GUI works lets create a dialog manually and not using resource file for that.


Creating Dialog window not from recources


1. register class

WNDCLASS wndClass = {0};
wndClass.lpfnWndProc = (WNDPROC)MyDialog_DialogProc;
wndClass.lpszClassName = L"DIALOG";
ATOM atom = RegisterClass(&wndClass);
HWND dialogHwnd = CreateWindow(L"DIALOG", L"MyDlg", ~WS_DLGFRAME &    ~WS_CLIPSIBLINGS, 10,10, 200,200, NULL, (HMENU)0, instance, 0); 

2. write a WindowProc

INT_PTR CALLBACK MyDialog_DialogProc( HWND hwnd,

UINT messageId,

WPARAM wParam,

LPARAM lParam )

{

if (messageId == WM_CREATE)

{

     // create button

   HINSTANCE hInstance = GetModuleHandle(NULL);

     HWND myButton = CreateWindow(L"BUTTON", L"ClickMe"
           , WS_CHILD, 10,10, 100,20, hwnd
           ,(HMENU)1, hInstance,0);

     if (!myButton)

     {

         // log error

     }

         ShowWindow(myButton, SW_SHOWNORMAL); 

  // create othe controls if there is a need!

  return TRUE;

}

return DefWindowProc( hwnd,  messageId, wParam, lParam); 

}

You can change this default WindowProc and this process is so calling subclassing
There is a lot of windows messages so if you don't need (or you don't want) to process all of them you need to call oldWindowProc to process messages that your new WindowProc doesn't process

I found that class "DIALOG" is not a default class in windows. This class creates when you are going to create a dialog based on recource file. When you create dialog from recource (using CreateDialog for example) this function register dialog class read resource file read styles inside dialog and raise WM_INITDIALOG and othe windows messages (WM_FONT is GWS_FONT defined) and after that call ShowWindow (if GWS_VISIBLE is defined)
all this steps is strictly synchronous because SendMessage is sync function.
How windows looks depends on window class and on windows style

Message handling 

As you may know some messages are received in thread queue others processed directly in WindowProc so you will never get WM_SIZE using GetMessage() or similar function

But messages from mouse and keybord will be sent to system queue
for example for erlier created messages in the same thread we use:


MSG msg;
while (GetMessage(&msg,0,0,0))
{
TCHAR buffer[MAX_PATH] = {0};
TCHAR windowName[MAX_PATH] = {0};
GetWindowText( msg.hwnd, windowName, MAX_PATH);
swprintf(buffer,L"Handle [0x%X] WindowName [%s] Message: [0x%X] \n",msg.hwnd, windowName , msg.message);
OutputDebugString(buffer);
DispatchMessage(&msg);
}

GetMessage Log:

Handle [0x0] WindowName [] Message: [0xC0B1] 
Handle [0x0] WindowName [] Message: [0xC0B1] 
Handle [0x60878] WindowName [MyDlg] Message: [0xF]  // WM_PAINT
Handle [0x60870] WindowName [ClickMe] Message: [0xF]  // WM_PAINT
Handle [0x6086E] WindowName [CicMarshalWndAJCB] Message: [0xC0B7] 
Handle [0x6086E] WindowName [CicMarshalWndAJCB] Message: [0xC0B6] 
Handle [0x6086E] WindowName [CicMarshalWndAJCB] Message: [0xC0B6] 
Handle [0x6086E] WindowName [CicMarshalWndAJCB] Message: [0xC0B9] 
Handle [0x6086E] WindowName [CicMarshalWndAJCB] Message: [0xC0B6] 
Handle [0x6086E] WindowName [CicMarshalWndAJCB] Message: [0xC0B9] 
Handle [0x6086E] WindowName [CicMarshalWndAJCB] Message: [0xC0B6] 
Handle [0x6086E] WindowName [CicMarshalWndAJCB] Message: [0xC0B9] 
Handle [0x6086E] WindowName [CicMarshalWndAJCB] Message: [0xC0B6] 
Handle [0x6086E] WindowName [CicMarshalWndAJCB] Message: [0xC0B9] 
Handle [0x6086E] WindowName [CicMarshalWndAJCB] Message: [0xC0B6] 
Handle [0x6086E] WindowName [CicMarshalWndAJCB] Message: [0xC0B9] 
Handle [0x6086E] WindowName [CicMarshalWndAJCB] Message: [0xC0B6] 
Handle [0x6086E] WindowName [CicMarshalWndAJCB] Message: [0xC0B6] 
Handle [0x6086E] WindowName [CicMarshalWndAJCB] Message: [0xC0B6] 
Handle [0x6086E] WindowName [CicMarshalWndAJCB] Message: [0xC0B6] 
Handle [0x6086E] WindowName [CicMarshalWndAJCB] Message: [0xC0B6] 
Handle [0x6086E] WindowName [CicMarshalWndAJCB] Message: [0xC0B6] 
Handle [0x6086E] WindowName [CicMarshalWndAJCB] Message: [0xC0B6] 
Handle [0x6086E] WindowName [CicMarshalWndAJCB] Message: [0xC0B6] 
Handle [0x6086E] WindowName [CicMarshalWndAJCB] Message: [0xC0B6]


from the log we can see that only WM_PAINT message we receive from GetMessage. Messages with 0 handle are messages not aligned to windows. There is also a CicMarshalWndAJCB but we didn't create window with such mane. I created only two windows "ClickMe" and "MyDlg" so what is "CicMarshalWndAJCB" for?

of cource when I move my mouse to that window I receive all mouse/keyboard input messages like WM_MOUSEMOVE WM_KEYDOWN and othe hardware messages

In  the Internet I also could not find any information about that window , so if someone reading this could help, please do

To complete  this article I put log in dialog window proc to better understand what messages come  first

WindowProc Log



Handle [0x3B086A] Message: [0x24]  //WM_GETMINMAXINFO
Handle [0x3B086A] Message: [0x81]  //WM_NCCREATE
Handle [0x3B086A] Message: [0x83]  //WM_NCCALCSIZE
Handle [0x3B086A] Message: [0x1]   //WM_CREATE
Handle [0x3B086A] Message: [0xD]   //WM_GETTEXT my call
Handle [0x3B086A] WindowName [MyDlg] Message: [0x1] //WM_CREATE we receive only one wm create but I put log just to be sure that windowname is MyDlg
Handle [0x3B086A] Message: [0x210] // WM_PARENTNOTIFY
Handle [0x3B086A] Message: [0x18]  //WM_SHOWWINDOW
Handle [0x3B086A] Message: [0x46]  // WM_WINDOWPOSCHANGING
Handle [0x3B086A] Message: [0x46]  // WM_WINDOWPOSCHANGING // this call from thread
Handle [0x3B086A] Message: [0x1C]  // WM_ACTIVATEAPP
Handle [0x3B086A] Message: [0x86]  // WM_NCACTIVATE
Handle [0x3B086A] Message: [0xD]   // WM_GETTEXT
Handle [0x3B086A] Message: [0x6]   // WM_ACTIVATE
Handle [0x3B086A] Message: [0x7]   // WM_SETFOCUS
Handle [0x3B086A] Message: [0x85]  // WM_NCPAINT
Handle [0x3B086A] Message: [0xD]   // WM_GETTEXT
Handle [0x3B086A] Message: [0x14]  // WM_ERASEBKGND !! I have handled it
Handle [0x3B086A] Message: [0x47]  // WM_WINDOWPOSCHANGED
Handle [0x3B086A] Message: [0x5]   // WM_SIZE
Handle [0x3B086A] Message: [0x3]   // WM_MOVE
Handle [0x3B086A] Message: [0x7F]  // WM_GETICON
Handle [0x3B086A] Message: [0x7F]  // WM_GETICON
Handle [0x3B086A] Message: [0x7F]  // WM_GETICON
Handle [0x3B086A] Message: [0xF]   // WM_PAINT
Handle [0x3B086A] Message: [0x135] // WM_CTLCOLORBTN ClickMe send this message to parent


So this mechanism works very good
all other stuff and errors and a lot of complains alligned to higher level of API in user mode. Teoretically it is possible to rewrite user mode API to have very simple and ea sy to use operating system. I think this is might be done by 3rd party vendows that works with Windows CE OS

Subclassing child window using WTL

To create custom control  you may use WM_DRAW_ITEM but this message you will receive in DLGPROC
So you have to draw control not in his own procedure but in parent one.

To resolve this complexity you can use subclassing with the child control.
If you are using WTL - all need to do is create class dediven not from standard WTL controls with other template parameter

For example for ATL::CListBox use

class CListBoxEx;

typedef CWindowImpl< CListBoxEx, CWindow, CControlWinTraits> CMyListBox;
template <>
HWND CListBoxT::Create(HWND hWndParent, ATL::_U_RECT rect, LPCTSTR szWindowName,
DWORD dwStyle, DWORD dwExStyle,
ATL::_U_MENUorID MenuOrID, LPVOID lpCreateParam)
{
      return CMyListBox::Create( hWndParent
                               , rect
                               , szWindowName
                               , dwStyle
                               , dwExStyle
                               , MenuOrID
                               , lpCreateParam);
}

template <>
CListBoxT::CListBoxT(HWND hParentHwnd)
:CMyListBox()
{
   if (::IsWindow(hParentHwnd))
   {
      CMyListBox::SetParent(hParentHwnd);
   }
}

class CListBoxEx :
public CListBoxT
{
...
}
 
This code allows you create a control and using Subclass-window replace WNDPROC for that control class
Now we can create or subclass a control


class CList_boxDialog : public CAppStdDialogResizeImpl,
public CUpdateUI,
public CMessageFilter, public CIdleHandler
{
... 
LRESULT OnInitDialog(UINT uMsg, WPARAM /*wParam*/, LPARAM /*lParam*/, BOOL& bHandled) 
{
    ..
    CWindow wnd = GetDlgItem(IDC_LIST_ADAPTERS);  
    mListBox.SubclassWindow(wnd);
    mListBox.SetParent(m_hWnd);

    mListBox.ResetContent();
    mListBox.AddString(_T("First"));
    mListBox.AddString(_T("Second"));
    ..
}

..
CListBoxEx mListBox;
} 

Code above get controls window handle and WTL replace controls window procedure


You should allow all unhandled messages to pass to old WNDPROC to do it just return 'false' from
ProcessWindowMessage()  

in CListBoxEx class:


BEGIN_MSG_MAP(CListBoxEx)
   MESSAGE_HANDLER(OCM_DRAWITEM, OnDrawItem)
   MESSAGE_HANDLER(OCM_MESUREITEM, OnMesureItem)
END_MSG_MAP()


Next step is message reflection

One of the most difficulties is to follow code in templates .. 
In your CDialog class you need to reflect all messages so they will be handled in child control class
to reflect all unhanded messages use

class CMyDialog;
BEGIN_MSG_MAP(CMyDialog)

    REFLECT_NOTIFICATIONS()
    CHAIN_MSG_MAP(CAppStdDialogResizeImpl<CMyDialog>)END_MSG_MAP()

Now you should be able to receive OCM_XXX and handle them in child control

This trick allow you to hold code in one place and increase portability and reduce time to create applications
As usual people don't create GUI in C++  even for Windows CE, Mobile but who knows ;)

Windows Mobile API ToolBar

Today I'd like to make some suggestion about CCommandBar class for Windows Mobile 5.0.
You can use MFC menu wrapper class or you can use Windows WINAPI function to get access to the ToolBar


MFC class CCommandBar class has no API to access to menu items and doesn't know how to control the menu. After a brief investigation and experiments with the menu I have got a working code:
 TBBUTTON tbb;
 ::SendMessage(m_oCommandBar.GetSafeHwnd(),     TB_GETBUTTON, 1, (LPARAM)&tbb);
 HMENU hMenu=HMENU(tbb.dwData);
 if(hMenu)
 {
     ::DeleteMenu(hMenu,0,MF_BYPOSITION);
     ::InsertMenu(hMenu,0,MF_BYPOSITION, ID_MENU_FR_SHOWDETAILS, L"Show Details");
 }

Here m_oCommandBar is an instance of CCommandBar. By using windows messages you can access to WINAPI menu and create a dynamic menus :-)