CodeLite IDE

Per bug 3059778 reported by me on SourceForge CodeLite bug tracker, patch offered.

Applied

Eran

I found a regression using this patch:
If I start a new debug sessions while I already have 'watches' from the previous debug session, codelite does not show the green arrow. I have to manually click on the 'Show Current Line' button in the debugger tool.
Until this is fixed, I am changed this code:
into this:
Eran

eranif wrote:I found a regression using this patch:
If I start a new debug sessions while I already have 'watches' from the previous debug session, codelite does not show the green arrow. I have to manually click on the 'Show Current Line' button in the debugger tool.

Could the system be setup to raise a flag when the debugger starts called "m_debuggerHasRestarted" and a count called "m_debuggerCallbacks" indicating how many times it's been "activated" through an error or through a user stepping since the start of the debugger session? That way it could be tested the first time RefreshValues() is called and always force the refresh. It may also provide interesting / useful statistics (debugger cycles, debugger up-time, efficiency, etc.).

Also, on my install (Ubuntu 10.04 Linux), CodeLite doesn't update the green arrow ever until it reaches a breakpoint or an error. And in my version, it is always updating the display when that happens and I never have to click the "show current line" button. How are you using the debugger to have it not show the green arrow?

In the alternative, here's a patch which only calls RefreshValues(false) from OnNewWatch() and OnDisplayFormat(), and from cl_editor.cpp when the user right-clicks or selects the menu to add a watch. Everywhere else uses the default/old RefreshValues() functionality, which forces the full editor position refresh.

- Rick

foxmuldr wrote:Could the system be setup to raise a flag when the debugger starts called "m_debuggerHasRestarted" and a count called "m_debuggerCallbacks" indicating how many times it's been "activated" through an error or through a user stepping since the start of the debugger session? That way it could be tested the first time RefreshValues() is called and always force the refresh. It may also provide interesting / useful statistics (debugger cycles, debugger up-time, efficiency, etc.).

The interaction with the debugger is done in an async mode. A counter can be added, but I'd rather use it only for statistics.
The order of the replies is not guaranteed.

foxmuldr wrote:In the alternative, here's a patch which only calls RefreshValues(false) from OnNewWatch() and OnDisplayFormat(), and from cl_editor.cpp when the user right-clicks or selects the menu to add a watch. Everywhere else uses the default/old RefreshValues() functionality, which forces the full editor position refresh.

This sounds like a better alternative, I will give it a try

Eran

eranif wrote:This sounds like a better alternative, I will give it a try

Was this patch ever applied?

foxmuldr wrote:Was this patch ever applied?

the original patch yes, the latest one: not yet. I will apply it on my local copy and test it as soon as I find some spare time

Eran