Known issues and bugs
From TeamDeveloperWiki
This page covers miscellaneous known issues & bugs.
Contents |
OutlineListbox/Combobox: item values -2 to -6 issue
When populating items in an OutlineListbox, a strange effect can be seen when values are used
between -2 and -6 passed with the VisListLoadChild function.
This piece of code is handled differently in older TD versions (<TD4.2) compared to newer versions (TD4.2 and up).
Including TD5.1 and TD5.2 !
VisListLoadChild( lbTest, nRoot, 0, 0, "This is item text", -2, 0 )
Instead of the wanted text, a replacement text is presented in the listbox.
See screenshot below to compare the same application running in TD3.1 and in TD5.2.
Here you can download the testcase:
Debugger fails to perform "step-over"
In some situations when debugging, the "step-over" functionality does not work.
Instead it performs a "step-into" or even a "continue run".
One clear and reproducible cause is the use of WM_Enable in the message actions section of top-level windows.
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.
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.
