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

[old_DOS_err]

At the risk of being burnt at the stake by the programming community, I think that subtle debugging may be a valid use of AI. I did a tiny bit of program slicing back in the 90s, an interesting idea, semantic checking is a lovely goal. Afterall, what is the job of a computer if not to run through huge volumes of data and make connections that would drive a human insane. It feels odd in a way that we are still relying on an area humans are not strong in, to create programs to make life easier for others. In a few recent google searches, for example drawing a polygon for my tabs, the AI came back with snippets that were actually useful. I know that is a whole other discussion, I noted the Chat GPT subject but not my area. But I think it is a realistic choice now, to put the work in to build better debugging tools as the size of projects grow, or look at using an area where computers are actually more suited.

But in the meantime, yes, I think this sort of trail would be very useful. I assume you meant a time line, like say Windows Media Player or youtube, whereby the programmer could have the relevant data in a window and the time line is the duration on the run. Then by simply dragging the mouse (keyboard options), one could get a snap shot of the program at any given (integral) point. I don't think that would be that difficult, for example I used the stringlist to record the data of my program at key points, but the thing is when looking at the text file after, it really didn't mean anything to me, because I couldn't put it into context of what happened in the run just before. The slider is nice and easy.

@Thausand thanks for clarifying. No worries, I am English, but have trouble explaining myself, so I can empathise. This is why others have suggested a second monitor, which makes a lot of sense, to get around the to and fro problem. I hope I understood what you were saying.

[Thausand]

@old_DOS_err:
Yes, you have make good understood. Have 2 monitor (or more) is very good solve (and then no have problem back/front, then have problem look left/right and up/down)

[LeP]

A thought of mine, perhaps off-topic, on debugging.
Debugging is an art.
It's not complex, but it requires a lot of imagination and technical knowledge, as well as having the right tools.
Debugging is simple, but effective debugging is not.
Many rely on breakpoints, but these are only aids for analyzing a specific "component": is it better to have an effective and complete "stack trace" or see a limited snapshot?
And can a profiler help with debugging?

You see, let me make a comparison with the universe... when we observe "Proxima Centauri," we see a star, but in reality, we're seeing what happened many years ago (about four and a half years ago) and we're observing history.
If we could see a truly current "snapshot"... who knows, maybe "Proxima Centauri" no longer exists. So in debugging, sometimes it's more important to see the "history" than a snapshot.....

[old_DOS_err]

@LeP, deep man

Update:

All my values seemed correct, the program was doing what it should do, but still the right arrow wasn't displaying. Using the passive breakpoint mentioned by @Martin_fr, it showed the line to make it visible was hit numerous times in the resize. Additional adds to the label mentioned by Benny, showed something odd with ClientWidth. At one point it froze and did not update as the width was changed. In general it seemed this value was too high, I use the width to determine where the right arrow would go, choosing to place it just inside the right edge of the frame rather than at the end of the tabs.

Anyway, because of my low level history, I still tend to do everything manually. This can sometimes lead to problems, especially with forms. In looking up issues about resizing problems, I found it recommended to change over to Align = alClient, it was alNone. Had to rejig a bit and put an OnResize into the frame (the way it had worked was the OnResize of the parent form had a call to a manual resize method). This has made the program behave rather differently and I need to re-evaluate this change.

So, it will take a few days to look further into the avenues brought up here. Thanks again to everyone who contributed.

Phil

[Martin_fr]

I use the width to determine where the right arrow would go, choosing to place it just inside the right edge of the frame rather than at the end of the tabs.

I found it recommended to change over to Align = alClient, it was alNone. Had to rejig a bit and put an OnResize into the frame (the way it had worked was the OnResize of the parent form had a call to a manual resize method). This has made the program behave rather differently and I need to re-evaluate this change

There may be another solution to your problem....

But, I do recommend to keep debugging it, for the sake of learning.

If you need to watch values/changes of a particular object, then conditional breakpoints may be useful.

E.g. if you set a breakpoint in TControl.ChangeBounds or other methods in the LCL that are used by many controls. You may just be interested in calls for a specific control (the shape displaying your arrow).
Use a watch to get the value for
   pointer(self)
Then in the breakpoint add the condition (replace the number as found by the watch)
   pointer(self) = $5101234

And the debugger will only stop if that condition is true.


Using "align" and other properties may indeed be a better way.

If you need the arrow to be at a fixed distance from the RIGHT EDGE of its parent, then you can

1) In the property Anchors, set the value akRight and remove akLeft. Then it will move with the right side of the parent

2) Better: Open the AnchorEditor (the "..." on the Anchors property)
  For the left anchor
   - UN-set Enabled
  For the right anchor
   - Set Enabled
   - select the parent as Sibling
   - select the button "Anchor right side to right side of sibling"
   - Set the distance in the spin edit

And the control will be fixed there.

You can access those values from code, e.g.
  Button1.AnchorSide[akRight].Control :=;
  Button1.AnchorSide[akRight].Side := ;
  Button1.BorderSpacing.Right :=

And then you don't need any OnResize.

If you need grid like layouts check "ChildSizing"

[old_DOS_err]

@Martin_fr thank you, again. It's stuff like that that makes me realise I've hardly even scratched the surface with Lazarus and free pascal. I hadn't thought of trying the anchors, I'd got so into the mindset of fixing everything manually. I think that may solve the positioning problem with the right arrow. I still need the resize, as my tabs aren't straightforward (now there's a surprise), so they are redisplayed at every change.

Good news is I have plenty of time at the moment, bad news is due to a major health issue, I don't have the stamina I used to. Anyway, back to the mill whilst my brain is half working.