Feedback Search Top Backward Forward

Questions and Answers

Written by Larry Salomon, Jr.


Gotcha Notes!

This is a part of this column that will appear from time to time, whenever someone else (or myself) manages to stumble upon something that is not obvious, yet doesn't belong anywhere else in the column. Things that end up here are not documentation errors or vagaries, but just things to be careful of. If you have something that would be of help to another of your fellow developers, please send it in.

The first submission this month deals with MDI applications, minimized icons, and the WM_QUERYTRACKINFO message. As many of you know, this message is sent to the frame whenever any tracking-related event - most notably moving and sizing - occurs to allow the frame to set parameters for the event. The point is that, by subclassing the frame window and intercepting this message, you can control some very important things such as minimum or maximum size of the window simply by setting one or more fields in the TRACKINFO structure pointed to by PVOIDFROMMP(mpParm2).

After investigating a bug reported by one of the users of an application I wrote, I discovered - much to my chagrin - that if a window is minimized and the user decides to move the icon, the frame receives this message. If, as was the case in my application, the frame is subclassed and the ptlMaxTrackSize is blindly set without any concern about the type of operation in progress, the icon will disappear when the operation is finished!

The way to avoid this is to check that you are not minimized (by calling WinQueryWindowULong(hwndWnd,QWL_STYLE) and checking for the WS_MINIMIZED bit) before proceeding to set any fields in the TRACKINFO structure.

On a related topic, it should be noted that this message is not sent to the frame when the user maximizes the frame. The message that is sent to the frame is WM_ADJUSTWINDOWPOS.

Eberhard Mattes noted that, for menu items with the style MIS_BITMAP, it isn't stated that bitmaps of menus are loaded from the .EXE file and not resource DLL. He presents a solution to this in the Snippet(s) of the Month section of this column.

Questions and Answers

You have to love it when it seems that everyone else is writing your column for you. ;) This answer to a frequently asked question comes from Juergen Hermann (

The answer to the question "how to bind a default icon to an .EXE file" is that the system looks for an icon resource with the (magic) number 1, so you have to use the following in your resource file.


It was pointed out that this will cause trouble if you define a constant for the number 1 because it conflicts with DID_OK, which is defined by the Toolkit. My experience has indicated that the first icon resource found in the executable is used, but since the first icon resource in my application are usually the lowest numbered also, this could instead by the criteria. Given that you can't get much lower than 1 (0?), the behavior I have seen would be consistent with what is described above.