Single-step message break
The single-step message break
Options available when the break occurs
Effect of ignoring the message using F6
Per-thread operation of the single-step message break
Switching on and off the single-step message break
Single-step message break ignoring some messages

The single-step message break
If this is "on" and you are single-stepping through your code, any message arriving at any window procedure within the debuggee will act as a breakpoint. It will cause the debuggee to enter the debug loop at the point where the window procedure is called with the message. Further processing will be halted until you decide what to do. You can see the message concerned in the status bar.

Here you can see from the status bar that the message WM_NOTIFYFORMAT was sent to the debuggee, and you can see from the codepane that it was sent to the window procedure "WndProc:", and you can see the first few lines of the code in the window procedure. On the status line you can see "Recursion=1". This means that the code was already executing in the window procedure when this message was sent. The first time a message is sent Recursion will be 0. If, before the code has returned from the window procedure, a further message is sent (no doubt caused by something happening in the window procedure), it will be 1, and so on.

Options available when the break occurs
When a single-step message break occurs, your options are:-

Effect of ignoring the message using F6
When you press F6 after a single-step message break you will see the codepane changes to show you what has happened and for a very short while the message remains in the status line. In order to keep control GoBug sets the trap flag on each instruction entering the debug loop, but it does not log any instructions, although it will log messages which arise while the message being ignored is being processed see message recursion. Keeping the trap does not usually slow the debuggee down greatly, but if it has a lot of work to do whilst processing the message you may see the vertical red ignore lines in the codepane animate. This indicates that the debuggee is still processing the message in the window procedure and has not yet returned.

Per-thread operation of the single-step message break
In practice, usually the single-step message break will be operative only on one thread in your program. This is because Windows messages are normally involved in the user interface, and it is bad programming practice to have more than one thread involved in this. However, it is possible that a secondary thread might have its own message loop or receive messages. In fact this is one good way for threads to communicate with each other. Hence GoBug permits the use of the single-step message break with more than one thread. Remember that whenever the debuggee is in the debug loop all its threads are suspended. So until you permit the processor to proceed, there will be no messages received by any other thread.

Switching on and off the single-step message break
For the main thread and for new threads this may be done in the "action" menu by setting or clearing the tick against the appropriate menu item. For all threads, you may control the single-step message break by using the traffic light control.

Single-step message break ignoring some messages
Messages destined for window procedures within the system Dlls are ignored by the single-step message break. There are often a large number of these, particularly when dealing with dialogs and custom controls. As far as GoBug is concerned, "System Dlls" are those which are in the Windows\system folder or in the Windows\WinSxS folder. If your system Dlls are in any other folder, please let me know on jg@jgnet.co.uk.

The single-step message break will also ignore those messages ignored by the log. To change these use the menu item "settings, log settings" and the tab "ignores".