Changing editable values in the debugger

Should we be able to modify the editable properties in the debugger (numeric, Boolean, string) and have the changes affect the running app? I’ve tried in 19r3, 19r1.1, and 18r2, and it appears that the app is not passed changed values.

Again, should that work?

Hi @Tim Jones

it seems to be a bug under macOS and (probably) Linux. It works on Windows.

I filled a bug case already on Feedback.

Hi Javier,

What’s the Feedback ID?

<https://xojo.com/issue/58622>

Is that Privvte? I get No Results found.

Oh, yes… sorry! I’ll try to make it visible .-|

It should be visible (public) now…

In VB6 is possible to change also code in debbugging mode without having to restart the debugging.
Is there any trick to do the same in Xojo ?
It is very large time consuming when you detect a mistake on code and have to stop and restart rhe debugging process again in large projects !!!

Hey @Mariano Poli !

Nope, there is no way you can do that in current (and previous) releases of Xojo! Anyway, most of the times the Stop debugger / Correction / Start again isn’t that time consuming… in fact is something Xojo has been speeding up along last releases.

But of course it would be great being able to change code on the fly. The main problem, I guess, is that the debugged app is already compiled, so…

@Javier Menéndez … You are right… in most projects it is not so time consuming
But in large ones, and if you use some third parties plugins, the time consuming is quite significant, also using a modern mac with enough memory resourses, SSD disk and an i7 processor.

Also see recent thread on this topic:

[quote=469178:@Mariano Poli]@Javier Menéndez … You are right… in most projects it is not so time consuming
But in large ones, and if you use some third parties plugins, the time consuming is quite significant, also using a modern mac with enough memory resourses, SSD disk and an i7 processor.[/quote]
Or - when your processes to get to a point in your app where an issue occurs that you are tracking down that can take long hours or even days to reach … being able to fix and continue would be awesome and very time saving.

Xojo would have to record the state of the CPU and its registers, all existing variables, instances and their states, etc in order to be able to “rewind” back to any point
OR it would have to be able to “unexecute” whatever machine code it needs to to rewind

Both unlikely to happen

Unlike VB in debug mode its NOT running p-code
Its running a fully compiled & linked executable and in order to fix & continue would require patching machine code while running

Again, unlikely to happen unless Xojo chnages the debug behaviour to something NOT running fully compiled & linked code
But then the debug experience is NOT the same as a build app

[quote=469329:@Norman Palardy]Again, unlikely to happen unless Xojo chnages the debug behaviour to something NOT running fully compilde & linked code
But then the debug experience is NOT the same as a build app[/quote]

This.

I’ve always chalked it up to running compiled code instead of p-code or interpreted code, and the nature of the beast. The first 64-bit versions of the Xojo compiler were full compiles and not optimized for code that had not changed, and that made debug cycles much more painful. Things are certainly better now, but stopping and changing values in the debugger does seem much less reliable than the 32-bit days. Which I assumed was at least in part due to now using an optimized compiler.

But letting the debugger work with p-code but shipping a compiled object is a two-edged sword. It may make debug cycle times faster, but at the expense of not really testing the final program. So stopping and entering edge case values into variables is not really the same as in the compiled app. Which would limit its usefulness.