forums.silverfrost.com

[Anonymous]

I have changed my PC from a Dell desktop to an HP laptop, and have just installed FTN95 v 4.8 on the latter. I cannot now debug programs that create a window using Clearwin, as follows. I step line by line through SDBG (console mode) in the normal way. At a certain point the first (main) Clearwin window is created and displayed. Thereafter, whenever I reposition any window on the screen with the mouse, the window leaves a trail ( multiple outlines of its frame) behind it that wipes out the display of everything in its trajectory. This did not happen on the desktop machine with the same FTN95 v 4.8. To investigate further, I then borrowed a Fujitsu laptop and got the identical problem. All three machines have the same up-to-date Windows XP. Is there some setup or setting that I am missing? Has anyone else experienced this problem? Thanks.

[Anonymous]

Do you mean any sdbg window, your program's windows or any window on the desktop?

[Anonymous]

Sorry, I should have been more explicit. The problem does not arise until the program being debugged creates a window. Then, when the created window is dragged across any SDBG windows, the traversed areas within these latter windows suffer temporary erasure, but they recover slowly (i.e. the windows are refreshed in half a second, say). The real problem is that the created window becomes permanently obscured by a staggered series of window frames when any other window (of SDBG or a separate application or the DOS window that launched SDBG) is dragged across it. The windows of DOS and separate applications never become affected when anything is dragged across them. All this happens with my own Clearwin-based programs and with the Clearwin demos included with FTN95. Running SDBG in MDI form makes no difference. Again, the problem occurs on two modern laptops, and not on the desktop PC. The programs work normally in non-debug mode. Thanks.

[Martin]

If you are paused in SBDG then your program's window will not get chance to refresh after it has been partially or totally covered up by another window. It will only refresh once your program gets a reasonable amount of running time.

Martin

[brianstott]

Thanks for the reply, which addresses the first phenomenon I described, of abnormally slow SDBG window refreshal. I have subsequently noticed that the refreshal is sometimes incomplete, as well as slow. This does not prevent me from continuing the debug session, but it suggests some incompatibility between SDBG and the laptop machines (one of which is very fast with 1 Gb memory). The second phenomenon, where the window created by my program is permanently covered up by dragging any other window over it, makes debugging impossible.

[Martin]

Actually I was only responding to your second problem. When you cover up your program's window it will only refresh when your program is running, as opposed to paused in the debugger. You should not be able to interface with your program while it is paused in the debugger anyway - if the program is paused it can't possibly process your input.

As for the SDBG problem, I too have noticed the delay on redrawing the screen. I have never counted this as a problem, however, as it hasn't interfered with my work. I believe this only happens when the program is not paused though, so there is not much you can do with the debugger anyway. The drawing corruption sounds like more of a problem - if it doesn't successfully refresh when the program is paused and the debugger regains control. Perhaps a screenshot of this corruption would help make it clearer for us.

Hope this helps,

Martin

[Anonymous]

As Martin says when the program is paused there is no way the debuggee's windows can be refreshed -- the code is not running. This happens in similar debug environments where you are debugging a true .exe (Delphi for example). However, even if you step over chunks of code or run the program to a point it does not mean the screen will be refreshed. Screen refresh is a very low priority task and the program may not get time to process the event before another debugging event occurs. Another program is the code being debugged has to do 'something' which would cause the event queue to be processed at all. In addition to all this, there may be some paint optimisation that is getting in the way and making the refrsh seem slower when debugging.