figure 1. the hierachy of an mdi application
creating the frame window
now we can turn our attention to the detail. first of all you need to create a frame window. it's created the same way as the normal window: by calling createwindowex. there are two major differences from a normal window.
the first difference is that you must call defframeproc instead of defwindowproc to process the windows messages your window don't want to handle. this is one way to let windows do the dirty job of maintaining mdi application for you. if you forget to use defframeproc, your application won't get the mdi feature. period. defframeproc has the following syntax:
defframeproc proc hwndframe:dword, hwndclient:dword, umsg:dword, wparam:dword, lparam:dword
if you compare defframeproc with defwindowproc, you'll notice that the only difference between them is that defframeproc has 5 parameters while defwindowproc has only 4. the extra parameter is the handle to the client window. this handle is necessary so windows can send mdi-related messages to the client window.
the second difference is that, you must call translatemdisysaccel in the message loop of your frame window. this is necessary if you want windows to handle mdi-related accelerator key strokes such as ctrl+f4, ctrl+tab for you. it has the following syntax:
translatemdisysaccel proc hwndclient:dword, lpmsg:dword
the first parameter is the handle to the client window. this should not come as a surprise to you because it's the client window that is the parent of all mdi child windows. the second parameter is the address of the msg structure you filled by calling getmessage. the idea is to pass the msg structure to the client window so it could examine if the msg structure contains the mdi-related keypresses. if so, it processes the message itself and returns a non-zero value, otherwise it returns false.
the steps in creating the frame window can be summarized as follows:
