Any way to debug and see the form at the same time?

[LeP]

I'm talking about Delphi (but not only that; it's the same with other debuggers like Windbg) in both 32- and 64-bit.
The only way I can synchronize the debugger with graphics (any graphics, whether modal windows or dialog boxes) is to use a secondary monitor.
I debug with the primary monitor, and the application uses the secondary monitor.
After years of struggling, this has solved all my debugging problems, starting with Windows 7.

[old_DOS_err]

Wow, ok, thanks Benny, worth looking into. I would have thought it was quite common to have GUI issues or code doing strange things due to the way forms behave (like being surprised how many time owner draw method is called in a listbox).

I'm still trying to trace the bug, I know from experience I've done something stupid, but because it only shows during the resize testing, it's tough. It's like training a dog, you can't tell it off after it has done something wrong, you have to catch it mid-event.

Thanks @Martin_fr, that looks really helpful. I didn't know about stopping on a variable change, will definitely explore that. And thank you for the clarity on the units, yep, I was doing it the wrong way, just putting it in the uses clause. It is just a single use function, I have a tendency to build a large collection of 'library' codes, from very simple inline to drop-in subforms (TFrames - though I will have a look at Handoko's idea). I had no idea about adding them to the project. I've gone on the policy since I started many moons ago, if it works, just be thankful and don't ask questions.

Thanks for the reply @Handoko, again, something I had no idea about. I knew from previous searches TFrames didn't seem very popular, but I didn't know what people used instead.

Thank you everyone, I feel like a kid on Christmas morning, stupid I know, but it is really nice when people put time and effort into making these replies.

Phil

[old_DOS_err]

Interesting way of doing it @Lep. Can that still be interactive? For example, if you are running your form, and you have the code open on another, can see the data live if you hover the mouse on it, or if the code hits a breakpoint, can you do anything with the form, like resize it. Even as write that, I feel I'm answering my own question. I think that is a level of interaction that is the holy grail, but I would love to be proven wrong. If AI can make a believable talking yeti, then anything is possible.

[Handoko]

... it is really nice when people put time and effort into making these replies.

If you aren't busy you should visit this forum frequently. Even you have nothing to ask, you always can learn something new simply reading the posts. People here like to share tricks and knowledge obtained from years of using Lazarus/Pascal.

[LeP]

Interesting way of doing it @Lep. Can that still be interactive? For example, if you are running your form, and you have the code open on another, can see the data live if you hover the mouse on it, or if the code hits a breakpoint, can you do anything with the form, like resize it. Even as write that, I feel I'm answering my own question. I think that is a level of interaction that is the holy grail, but I would love to be proven wrong. If AI can make a believable talking yeti, then anything is possible.

P.S: [EDIT] of course, you cannot view a live data without breakpoints. Only with breakpoints you will see any data. If you want to see in live action, do a "writeln" with your datas to a windows console attached.

Yes, while debugging, you can see everything (or almost everything). The only thing you might have trouble with is mouse management... when the debugger enters, the mouse moves from the application to the debugger, so whatever you're doing when you restart from the breakpoint, it stops (the mouse operations, for example, resizing).
Honestly, I haven't debugged things like this in years; I don't think there are any "secrets" anymore.
When I did it years ago, I used Delphi's remote debugger: it allowed you to remotely debug the application (on two different systems), so the debugger didn't interact graphically with the mouse or anything else.

Use this in your FormCreate event, and if there is a secondary monitor your application will showed on this (it's for Delphi but should works in Lazarus too):

Code: Pascal  [Select][+][-]

1.   var i: integer;
2.   ......
3.   if Screen.MonitorCount > 1 then
4.     begin
5.       for i := 0 to Screen.MonitorCount-1 do
6.         begin
7.           if (not Screen.Monitors[i].Primary) and (Screen.Monitors[i].Left = Screen.Width) then
8.             begin
9.               Top := Screen.Monitors[i].Top;
10.               Left := Screen.Monitors[i].Left;
11.               //MakeFullyVisible(Screen.Monitors[i]);
12.               break;
13.             end;
14.         end;
15.     end;
16.  

[old_DOS_err]

@LeP thanks for that info. I do have an old, but working monitor right next to the main one (currently attached to a Lenovo that probably would be out-performed by a BBC micro). So wlll try to explore that, would be a good excuse anyway, only time I ever do 2 monitors is if I have to use a laptop (I attach keyboard, mouse and monitor, and voila, no longer mobile).

[Martin_fr]

@LeP thanks for that info. I do have an old, but working monitor right next to the main one (currently attached to a Lenovo that probably would be out-performed by a BBC micro). So wlll try to explore that, would be a good excuse anyway, only time I ever do 2 monitors is if I have to use a laptop (I attach keyboard, mouse and monitor, and voila, no longer mobile).

IMHO multiple Monitors help a lot with working on code, debugging, and more...

Especially, if you use a docked IDE and that will occupy one screen by itself, and you can't spare a corner for the running app, that you want to debug.

The crux is (IMHO) that a docked IDE is something you start to need, if you have a single screen, because then you have so many IDE Windows that they don't fit the space you have. And then, if you have only one single screen, the docked IDE makes it a lot harder to have some spare space for the app to run...

I only use docking on my laptop, and I don't do much serious work on it, otherwise I have several screens and space enough for all the IDE windows **and** any app I am running.

So, if you have a spare monitor, even if it is old and the quality may not be good, use it. If you debug your app on it, it shouldn't matter that is may not have the best contrast or lower resolution, or slow pixel switching times ...

For example, if you are running your form, and you have the code open on another, can see the data live if you hover the mouse on it, or if the code hits a breakpoint, can you do anything with the form, like resize it. Even as write that, I feel I'm answering my own question. I think that is a level of interaction that is the holy grail, but I would love to be proven wrong. If AI can make a believable talking yeti, then anything is possible.

There is no "live data". Data only gets loaded when the app is paused (at a breakpoint / single stepping / ...). And when the app is paused you can't interact with it (you can't click buttons, or change the size).

Partly that is actually dictated by the "data" itself.

NOTE: the below is "in theory". What could be added to the debugger, and what could not. But the below is not currently implemented.

Lets start with local vars, they only exist while inside a routine. But to interact with the app, the app must run => so the app will be in different routines all the time. It be 10 millisecond in one routine. There wouldn't be a point to show the data for 10 millisecs.

Global vars of course exists all the time. It would be possible (as a feature that has not yet been added) to watch a global var, by pulling the value every 50 millisecs.

Fields (in object, e.g. fields of a form or frame) are a middle ground. The are like locals, if the object is a local. If the object is global, and you specify the full name from that global var => and if that feature was implemented (which it is not), then that could be done.

Of course that would likely by of limited use. The value could change several time in such short intervals, that you would not even be able to see that it changed several times (or changed at all, if it changed back immediately).

And if the value gets updated "on a timer" (e.g. the debugger checks ever 50millisecs) then the debugger may even miss that it changed.
Of course the debugger could use the "value changed" notification (which is used for "data breakpoints"). But only 4 values (and only up to pointer size) can be monitored like this....

So, "live watching" would have a lot of limitations.

Anyway as it stand now, you can only see values while paused.

The usual approach is to single step, and monitor the watch you are interested in, as single stepping will pause at each statement, and therefore give you updates. But if you don't know where approx you need to debug, single stepping may not be a solution (no one would single step 1000 steps...)

Then you can use watchpoints. If you know which value should change => set a watchpoint. (you can combine that with the history / if you don't want to pause the app completely when it happens)

[440bx]

First, I want to second (pun intended) all the recommendations about having a second monitor.   It really makes life a lot easier in many ways, debugging among them.

That said, there are some cases where even having more than one monitor isn't helpful and, that's when the code that needs to be debugged is executed in real time as a result of mouse movements.  That's the one case where normal debugging doesn't cut it.  Fortunately, there is a solution:

make the program a console program by adding {$APPTYPE CONSOLE} at the top of the .lpr file then, simply place writeln instructions to output whatever values are of interest onto the console.  This way, the results of moving the mouse can be inspected in the console window.  If necessary, right click on the console title bar and set  the screen buffer size to 9999.  That will usually be sufficient.

Using a console allows tracing any value in real time, which is sometimes necessary.  One unexpected and advantageous side effect of logging to a console window is that is slows down the repainting in the GUI program.  This can sometimes be very useful in uncovering a bug.

HTH.

PS: the ExtTextOut.7z file attached to the post at:
https://forum.lazarus.freepascal.org/index.php/topic,53791.msg398390.html#msg398390
is an example of how to do this.  It tracks the values of the mouse in real time as the GUI window is resized.

[old_DOS_err]

@Martin_Fr Thank you. I like the analysis of the live data issue, as I noted even as I typed the question I relialised I was being a bit of an idiot.

@440bx Thank you, that looks fascinating, I downloaded that link. I've only recently started using the $define structure in some of my units to create debug code, nothing sophisticated, just adding lines to a TStringList.

It feels quite exciting, a new challenge. It will take me several days to go through this lot and implement stuff, sadly speed is something I can only reminisce about these days.

Phil

[cdbc]

Hi
Attached is a snapshot of a 'Live' debug-session.... 
Regards Benny

[old_DOS_err]

Thanks Benny, always helpful to have a "This is what it should like." BTW, I did use your label suggestion, although the TFrame sits snugly inside the parent panel, because I'm in a testing program, the parent had a spare label, so just put a TLabel into the TFrame and linked them. Then I could see the relevent values as I dragged the window left and right. They were as expected. So I'm still puzzled about why my program is not behaving correctly on resizing. Hey ho. I'm off to shove more things in the label. Basically I'm using TArrrow for scrolling with a set of home made tabs, these work fine when I just add or remove tabs (it has a trim feature), but on the resize, the arrow is not showing, I checked the Left and it was adjusted correctly, I put the breakpoint where I turn the arrow on, all good. But still the arrow doesn't show. There are times I find programming soo frustrating.

[Martin_fr]

Well, one idea that could be done (not sure when...)

The watches window could keep the last value visible, when the app continues.
Currently it goes back to "invalid", because while the app is running, the value could be anything. So showing the last known value is technically wrong.

But, showing the last know value would be useful if you have a breakpoint that continues automatically. The app would pause, but for a few millisecs only. The watches would be evaluated, and while the app runs again, the user could still read the values.

I had for a while the idea to "fade out"  the values, in order to reduce flicker when stepping => That is most single steps take only a few ms, if the watches would wait 100ms before clearing (or fading) the values, then during stepping the reset to "invalid" would not happen.
Of course keeping the last value would solve that too. Or could be combined, fade to a slightly diff color as indicator that the value is "old".
Question then is, when the debug session ended, how long to keep the last set of values? Because IMHO when the app has stopped entirely then it should be cleared. (as code will be edited, and values become pointless) / And they can be viewed on request using the history, which is only cleared when starting the next debug session.

Well, for now this remains on my todo, one way or another.

[old_DOS_err]

I was wondering about coming in the from the other end, so to spreak. Instead of trying to work out what the system is doing, which was hard enough in MSDOS on an 8086, for those really hard to solve problems that defy all logic, create a simulator. It would be very slow, but for the one-offs it would be fine. Then the simulator creates the forms and is in control of the data, it could emulate things like scope and range checking.

I live in a world where I have a thousand ideas, where not even the most basic will ever see see the light of day. Cue violin music, fade to black...

[Martin_fr]

I was wondering about coming in the from the other end, so to spreak. Instead of trying to work out what the system is doing, which was hard enough in MSDOS on an 8086, for those really hard to solve problems that defy all logic, create a simulator. It would be very slow, but for the one-offs it would be fine. Then the simulator creates the forms and is in control of the data, it could emulate things like scope and range checking.

My first thought (ignoring your dos references) would have been that you may come from scripting (like javascript). Because there you have the interpreter, and it can hook better into the app than traditional debuggers can (at least without to much slow down).

About "simulating" => I don't think that is practical. There is something close to that, but for a totally different purpose. Actually not a simulator, but a tool that single steps your entire app without you need to do anything:
   valgrind  (Linux only)
One of its uses ( -tool=memcheck ) is to find: memleaks, out of bound access, access after free, ....
However, if you use it your app will be crawling slow.
But it is a good way to find those kind of errors.

Another approach of debugging (but Lazarus does not yet have it, I don't know if you can do it with raw gdb from console... maybe/ maybe not):
"Back in time debugging" or "reverse stepping"
The debugger will again single step everything (takes lots of time), and record everything (at a much higher level of detail than the History in Lazarus). But when you pause anywhere, then you can go back on the timeline (like in a movie editor). You can see the app (not visually, but the data) at any time. You can search when a variable had changed, and stuff like that.
Well, we are very far from having that, not sure if we will get that at all.

[Thausand]

@Thausand I did not understand what you meant by "front debugger", was that something specific or a general reference?

I sorry for broken english. Other users write more better grammar for explain (and have explain, so thank).

For clarify: When debug application then is present 2 forms. 1 for application and 1 for debug (debugger can have more but for keep simple example). When make step in debugger then debugger make show source step (source-code is front). When code is make update to form for application then code is execute and make application form 'move' to front of debug window and make show update (draw line, draw text, refresh etc). When form finish draw (refresh) then debug window is 'move' to front. It is switch front-back-front ad infinitum (ofc it stop wen application is stop/finish  )

That why other users also write make change for form (example, make update visible component) then form is refresh and show window place 'on top' (=front) debug window (debug window = back"). That back and front explain. I sorry if not clear when first write.