Wish Legacy debug buttons in 5.0 Beta

HotShoe

Well-Known Member
Licensed User
Any chance we could get the buttons for run, step into, stop, etc back in legacy debug mode? They were in the lower left box in the debug panel. I don't see a shortcut to stop the debugging process so I nust use the top debug menu. The F8, F9, etc shortcuts are still there though. Maybe assign the old Delphi/C++ Builder Ctrl+F2 to stop debugging?

EDIT : I just found the buttons in the top toolbar. I'd still like to have a shortcut for Stop though.

--- Jem
 

qsrtech

Active Member
Licensed User
I was using legacy sometimes cause rapid didn't seem that rapid. Idk if anything changed in 5.x but i just tested one particular thing that was slow before and now it does seem "rapid" ;)
 

Erel

Administrator
Staff member
Licensed User
The "rapidness" comes from the fact that in many cases a full compilation is not required and the app is redeployed in a second or two. The rapid debugger is much more powerful than the legacy debugger and supports advanced features like hot code swapping, expression evaluation (which is very useful in the new IDE) and others.

If code execution is slow with the rapid debugger then you should force it to do a full compilation by clicking on Ctrl + P (clean project). Removing breakpoints can also improve the performance in some cases.
 

HotShoe

Well-Known Member
Licensed User
BTW, why are you using the legacy debugger and not the rapid debugger?
It's an old habit from when the rapid debugger was not terribly good. I will leave it on rapid debugging and see how it has grown.
 

canalrun

Well-Known Member
Licensed User
Hello,
This was discussed a few months ago, but I see it's being mentioned again.

I have had a great deal of difficulty using the Rapid Debugger. Every time I've tried to use it (up to version 3.82, haven't tried in 4.3) I find myself quickly returning to the Legacy debugger.

Personally, I don't see a need for faster compiles or smaller downloads – having the possibility that the debugger might introduce something that would not be present in the release code (slower execution or extra subroutine calls), I feel, is actually a huge disadvantage.

I've noticed when I use the Rapid debugger that I can no longer hover over variables after a breakpoint to see the value. After a breakpoint, there are usually only a half-dozen or so variables that I want to take a quick look at. Not having to scroll the bottom display back and forth and expand the line to see the value is time saver.

When there is an exception the Rapid debugger exits the code. Several times I've had the Rapid debugger tell me the error occurred past the last line of some included module when I know this would be impossible. I have to insert Log statements to trace execution in order to find where the error occurred.

The variable display at the bottom is very difficult to use – especially for views. Most of the variables shown for views are used internally by the view and are of no interest, but finding the one you want can be almost impossible.

I guess I just want to express my hope that the legacy debugger is continued.

Barry.
 

Erel

Administrator
Staff member
Licensed User
I've noticed when I use the Rapid debugger that I can no longer hover over variables after a breakpoint to see the value. After a breakpoint, there are usually only a half-dozen or so variables that I want to take a quick look at. Not having to scroll the bottom display back and forth and expand the line to see the value is time saver.
Important point. But not relevant any more.

See this screencast (watch it in HD):


There are two important features here:
1. You can examine the objects values.
2. If you hover over a property then you can see its value. This is very useful. It is based on the expressions evaluations engine.
 

canalrun

Well-Known Member
Licensed User
Thanks. Very nice.

Has the "exit application" on exception been changed in more recent versions?

Stopping after an exception with the offending line highlighted in yellow with the ability to view variables when using the legacy debugger is very handy. Has this been modified in recent versions also?

Barry.
 
Last edited:

ac9ts

Active Member
Licensed User
No. It is not really feasible due to the way the rapid debugger works.
This is why I also use the legacy debugger. The log files from the rapid debugger don't always show what line the error is at and I'm not always that clever to determine it by going through the entire log output. The legacy debugger will stop where the error is and then I'll use the rapid debugger to do the debug since I can change things on the fly. IMHO, they are both very useful tools.
 

ac9ts

Active Member
Licensed User
I just ran a simple test (not initializing a view) in v4.3 and rapid displays the line and legacy stops and highlights the line, as expected. I usually code in release mode (which doesn't show the line on errors) so, maybe out of habit, I went to legacy first. I'll try to remember to go straight to rapid in the future so......um.....never mind.
 

RandomCoder

Well-Known Member
Licensed User
If code execution is slow with the rapid debugger then you should force it to do a full compilation by clicking on Ctrl + P (clean project). Removing breakpoints can also improve the performance in some cases.
I've regularly experienced a slow down in the execution of code on a project I'm currently working on. Just through shear luck I've been performing a 'Clean Project' and then recompiling in 'Rapid Debug'. I never thought to report this as I didn't really associate the problem to be specific to the rapid debugger.

I definitely like the improvements in the rapid debugger. Especially the ability to see values by hovering over the variable in the IDE. I sometimes found the information in the watch window a little overwhelming especially for something like an edittext where there are is much information.
 
Top