[All TD versions] Debug: Step-over fails (it does Step-into)

[EwaldP]

I discovered that in one particular instance, the debugger fails to do "step-over".
Instead it performs a "step-into".

It is caused by a single message, WM_Enable !
When under the message actions of a top-level window the WM_Enable event is coded, whatever implementation, the debugger will fail to do "step-over".
By commenting the code (and keep the WM_Enable message present, but without actions) the debugger works like it should.

I created a very simple testcase (see attachment)

Steps to reproduce :
- Place a breakpoint at the first line of the SAM_Click of the pushbutton on the form.
- Run application and try to "step-over" the code. It will fail, you get a "step-into"

Now to see how WM_Enable is related:
- Go to the message actions of the form and locate WM_Enable
- Comment the line of code under the message

Code: Select all

Message Actions
   On WM_ENABLE
      If TRUE      ! Just comment this line to get the debugger working again

- Run the application and retest the debugger. Now it is stepping over.

I have tested this on TD1.5.1, TD3.1 and TD4.2 and have seen the issue is present in all those versions.
Testing TD5.1 and TD5.2 shows the issue is not present there, seems the internal handling of WM_Enable has changed.

I tried to subclass the WM_Enable message (by using subclasser) by sending another custom message, but that fails also.
Also eating the message completely and resend it as another custom one does not help. Even sending it to a completely different window does not solve it.
Seems WM_Enable is internally processed by TD and interferes with the debugger.


Can anyone confirm this issue ?
Furthermore, does anyone have a solution? We need WM_Enable on top level forms, but right now the debugging is very inefficient.

[markus.essmayr]

Hi Dave,

great work!

I can absolutely confirm that this application allows to reproduce the debugger issue easily if executed on a TD 3.1 environment.
On a TD 5.1 environment, the debugger behaves as it should.

But in TD 5.1 I noticed, that a debugger issue like this exists.
Sometimes the "Step Over" does a "Step Into" but it's definitively not caused by WM_ENABLE there.
Or better, it's not caused by that simple application.
Sorry, but I don't have a repro case for that.

Max

[markus.essmayr]

Back again!

I now did some playing around with TD 5.1 and it's debugger.
The sample Dave attached did work well in my environment.
So I decided to just add a MDI window, move the Form window as child window.

It again is a very simple application.

Now set your breakpoint into the SAM_Click message handler of the button.

Notice, that there are two WM_ENABLED handlers in the MDI windows message actions.
The first is called the Debugger "Step Into" handler.
It's the same Dave used in his sample.
If this on is active, the TD 5.1 debugger performs a "Step Into" even if you press "Step Over".

If you comment out the first, and comment in the second WM_ENABLE handler, the Debugger "Continue" handler, you notice, that the debugger continues if you click "Step Over".

Can you verify that on your side?

Max

[Dave Rabelink]

Hi Max,

Yes, I confirm the issue on TD5.1 and also on TD5.2 !

Very strange, does not make sense to me.
Hope these testcases can help Unify pinpointing the issue and maybe find other debugger related issues.

[Dave Rabelink]

I did some further analysis and now I know why the debugger is failing.

At the time the debugger is activated (when a breakpoint is reached) TD disables all present top level windows and brings the IDE to front.
(this is probably to avoid interference of the windows while debugging, a disabled window will not receive any messages, can not be clicked and put to front).

So what happens when code is present on the WM_Enable on a window:
When the debugger starts it first does a disable of all windows. This triggers a WM_Enable message on those windows. The code there is executed.
This code confuses TD. It expects to start debugging at the breakpoint, but TD is performing the actions on the WM_enable message BEFORE it reaches the breakpoint. So after the WM_Enabled message is processed, the debugger stops at the breakpoint. Now TD's debugger is messed up, it's execution context, current line of code etc etc seem not to correspond anymore. So the debugger is off track and step-into, step-over actions will be erratic and in some cases fail.

Strangely, when you put a breakpoint at the WM_enable message, the debugger does not stop at that breakpoint. And that is obvious, a chicken and egg issue.
The debugger will only trigger a WM_Enable when a breakpoint is reached. The breakpoint on the WM_Enable will not be triggered when the debugger is not activated.
Even when the debugger triggers WM_Enable, the breakpoint is not active. Seems TD is executing all code under the WM_enable, but it's breakpoint is ignored.


So what solution could there be?
I think TD should eat up the WM_Enable message when the debugger disables the windows. Then the code will not be executed and the debugger will not get confused (I think).

In line with this assumption, I created a workaround which actually works. It depends what code is executed at the WM_Enable if you really need it at debug time. In our case, the WM_enable message is used to update GUI objects to reflect the enabled/disabled states. This is not needed at debugtime (the GUI is not visible at that time).

So maybe this trick will work for others having this issue:

At creation of top level windows, detect if the application is running from executable or is running in IDE.
When running in IDE, the WM_Enable message should be eaten up so the code is never executed.
When running from executable, the WM_Enabled message should be executed.

So this piece of code will do that.

Code: Select all

On SAM_Create
   If SalStrRightX( strArgArray[0], 3 ) != "exe"
       Call RegSubclass( hWndForm, WM_ENABLE, hWndNULL, WM_ENABLE, SUBCLASS_FLAG_INSTEAD )

On WM_Enable
   ...
   Do actions here
   ...

You need Subclasser.
http://www.cschubert.net/html/subclasser.html

It subclasses WM_Enable and will send it to nirvana and eats it up.
The WM_Enabled message actions will never be executed.

[hotzi]

Hopefully the Step-over/Step-into problem can be fixed in the next service pack for TD 5.2!?