| 8177 | |
| 8178 | |
| 8179 | LRESULT CALLBACK GuiWindowProc(HWND hWnd, UINT iMsg, WPARAM wParam, LPARAM lParam) |
| 8180 | { |
| 8181 | // If a message pump other than our own is running -- such as that of a dialog like MsgBox -- it will |
| 8182 | // dispatch messages directly here. This is detected by means of g->CalledByIsDialogMessageOrDispatch==false. |
| 8183 | // Such messages need to be checked here because MsgSleep hasn't seen the message and thus hasn't |
| 8184 | // done the check. The g->CalledByIsDialogMessageOrDispatch method relies on the fact that we never call |
| 8185 | // MsgSleep here for the types of messages dispatched from MsgSleep, which seems true. Also, if |
| 8186 | // we do launch a monitor thread here via MsgMonitor, that means g->CalledByIsDialogMessageOrDispatch==false. |
| 8187 | // Therefore, any calls to MsgSleep made by the new thread can't corrupt our caller's settings of |
| 8188 | // g->CalledByIsDialogMessageOrDispatch because in that case, our caller isn't MsgSleep's IsDialog/Dispatch. |
| 8189 | // As an added precaution against the complexity of these message issues (only one of several such scenarios |
| 8190 | // is described above), CalledByIsDialogMessageOrDispatch is put into the g-struct rather than being |
| 8191 | // a normal global. That way, a thread's calls to MsgSleep can't interfere with the value of |
| 8192 | // CalledByIsDialogMessageOrDispatch for any threads beneath it. Although this may technically be |
| 8193 | // unnecessary, it adds maintainability. |
| 8194 | LRESULT msg_reply; |
| 8195 | if (g_MsgMonitor.Count() // Count is checked here to avoid function-call overhead. |
| 8196 | && (!g->CalledByIsDialogMessageOrDispatch || g->CalledByIsDialogMessageOrDispatchMsg != iMsg) // v1.0.44.11: If called by IsDialog or Dispatch but they changed the message number, check if the script is monitoring that new number. |
| 8197 | && MsgMonitor(hWnd, iMsg, wParam, lParam, NULL, msg_reply)) |
| 8198 | return msg_reply; // MsgMonitor has returned "true", indicating that this message should be omitted from further processing. |
| 8199 | g->CalledByIsDialogMessageOrDispatch = false; |
| 8200 | // Fixed for v1.0.40.01: The above line was added to resolve a case where our caller did make the value |
| 8201 | // true but the message it sent us results in a recursive call to us (such as when the user resizes a |
| 8202 | // window by dragging its borders: that apparently starts a loop in DefDlgProc that calls this |
| 8203 | // function recursively). This fixes OnMessage(0x24, "WM_GETMINMAXINFO") and probably others. |
| 8204 | // Known limitation: If the above launched a thread but the thread didn't cause it turn return, |
| 8205 | // and iMsg is something like AHK_GUI_ACTION that will be reposted via PostMessage(), the monitor |
| 8206 | // will be launched again when MsgSleep is called in conjunction with the repost. Given the rarity |
| 8207 | // and the minimal consequences of this, no extra code (such as passing a new parameter to MsgSleep) |
| 8208 | // is added to handle this. |
| 8209 | |
| 8210 | GuiType *pgui; |
| 8211 | GuiControlType *pcontrol; |
| 8212 | GuiIndexType control_index; |
| 8213 | bool text_color_was_changed; |
| 8214 | TCHAR buf[1024]; |
| 8215 | |
| 8216 | switch (iMsg) |
| 8217 | { |
| 8218 | // case WM_CREATE: --> Do nothing extra because DefDlgProc() appears to be sufficient. |
| 8219 | |
| 8220 | case WM_SIZE: // Listed first for performance. |
| 8221 | if ( !(pgui = GuiType::FindGui(hWnd)) ) |
| 8222 | break; // Let default proc handle it. |
| 8223 | pgui->mIsMinimized = wParam == SIZE_MINIMIZED; // See "case WM_SETFOCUS" for comments. |
| 8224 | if (pgui->mStatusBarHwnd) |
| 8225 | // Send the msg even if the bar is hidden because the OS typically knows not to do extra drawing work for |
| 8226 | // hidden controls. In addition, when the bar is shown again, it might be the wrong size if this isn't done. |
| 8227 | // Known/documented limitation: In spite of being in the right z-order position, any control that |
| 8228 | // overlaps the status bar might sometimes get drawn on top of it. |
| 8229 | SendMessage(pgui->mStatusBarHwnd, WM_SIZE, wParam, lParam); // It apparently ignores wParam and lParam, but just in case send it the actuals. |
| 8230 | switch (wParam) |
| 8231 | { |
| 8232 | case SIZE_RESTORED: wParam = 0; break; |
| 8233 | case SIZE_MAXIMIZED: wParam = 1; break; |
| 8234 | case SIZE_MINIMIZED: wParam = -1; break; |
| 8235 | //default: |
| 8236 | // Note that SIZE_MAXSHOW/SIZE_MAXHIDE don't seem to ever be received under the conditions |
nothing calls this directly
no test coverage detected