Lazarus

Using the Lazarus IDE => Debugger => Topic started by: d7_2_laz on July 20, 2021, 03:08:25 pm

Title: 2.2 RC1 Windows, with GDB is there an option to reanimate OutputDebugString?
Post by: d7_2_laz on July 20, 2021, 03:08:25 pm

Wirh 2.2 RC1 / Windows x64 / i'm missing the "OutputDebugString" funmctionality as a small and handy means for to write some infos to the event log without needing to have additinal includes or further steps to go.
Remark: it's not in the FpDebug yet, but maybe still when using gdb.

I was told by avra that it could be reactivated by debugger setting via:
Lazarus / Tools / Options / Debugger / EventLog / Messages" configuration dialogue, Debug Output window, or something else?
I set the Debugger backend to gdb, and this is assumingly the translated equicalent:
Lazarus Menu item "Werkzeuge" (Tools) > Einstellungen (Options" > Debugger > "Ereignisprotokoll" (Event log).

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

1. EventLog / Messages you check Output checkbox, OutputDebugString('<<<<< It works ! >>>>>') outputs to Debug Output window

Cannot see anything about OutputDebugstring here, see screenshot attached.

Title: Re: 2.2 RC1 Windows, with GDB is there an option to reanimate OutputDebugString?
Post by: Martin_fr on July 20, 2021, 03:37:21 pm

It is: "Ausgabe"

It has been added to fpdebug after the rc1. (at least on 64bit win / 32 bit awaits testing).

It did not work for gdb for me now. Gdb seems fine.
Please report as a bug on mantis

Title: Re: 2.2 RC1 Windows, with GDB is there an option to reanimate OutputDebugString?
Post by: d7_2_laz on July 20, 2021, 04:24:25 pm

Martin, if it would work with gdb, then i would have used that temporarely.
if - apparently - not, but added to FpDebug after the rc1, that's fine anyhow though, so i*ll wait for that.
- Clarified

Besides that: upto 2.0.12 the default was gdb i think (i ever used the default).
I can say definitely that it had worked here / Windows x64  ("worked" does mean: it really generated output for the event log).
You really still suggest to report it as a bug in mantis (gdb related)? Then i could do that.
Thank you!

Title: Re: 2.2 RC1 Windows, with GDB is there an option to reanimate OutputDebugString?
Post by: Martin_fr on July 20, 2021, 05:52:10 pm

Yes report a bug.

It should still work with gdb (and the new gdb.exe seems to report it, so it's the IDE)

Title: Re: 2.2 RC1 Windows, with GDB is there an option to reanimate OutputDebugString?
Post by: avra on July 21, 2021, 12:22:39 am

Quote from: Martin_fr on July 20, 2021, 03:37:21 pm

It is: "Ausgabe"

Yes, that is "Output" in English IDE version. Now all you need is to include Windows unit and use "OutputDebugString('<<<<< It works ! >>>>>')" command in code. If you do not see "Debug Output" window then go to "Lazarus / View / IDE Internals / Debug Output".

Title: Re: 2.2 RC1 Windows, with GDB is there an option to reanimate OutputDebugString?
Post by: Martin_fr on July 21, 2021, 12:32:52 am

Quote from: avra on July 21, 2021, 12:22:39 am

If you do not see "Debug Output" window then go to "Lazarus / View / IDE Internals / Debug Output".

Ah, but it should be in "event log" window.

"Debug Output" is low level internal.

Title: Re: 2.2 RC1 Windows, with GDB is there an option to reanimate OutputDebugString?
Post by: Martin_fr on July 21, 2021, 12:50:09 am

Fixed in trunk and fixes branch

Title: Re: 2.2 RC1 Windows, with GDB is there an option to reanimate OutputDebugString?
Post by: avra on July 21, 2021, 08:26:24 am

Quote from: Martin_fr on July 21, 2021, 12:50:09 am

Fixed in trunk and fixes branch

Even better. Thanks!

Title: Re: 2.2 RC1 Windows, with GDB is there an option to reanimate OutputDebugString?
Post by: d7_2_laz on July 21, 2021, 11:12:51 am

@Martin_fr. here's the suggested bug report against ..
https://bugs.freepascal.org/view.php?id=39278

Title: Re: 2.2 RC1 Windows, with GDB is there an option to reanimate OutputDebugString?
Post by: Martin_fr on July 21, 2021, 02:27:04 pm

Quote from: d7_2_laz on July 21, 2021, 11:12:51 am

@Martin_fr. here's the suggested bug report against ..
https://bugs.freepascal.org/view.php?id=39278

That overlapped. Though I hadn't been clear either.

I hadn't been sure when I will fix it. And if it had been later, then the report makes sure it is not forgotten.

Since I did fix it in the meantime, the need for the report was gone.

Though, as I said, I hadn't been clear.
Sometimes a report should be done even if the fix is already there. In complicated cases, the report might serve as an explanation why something was changed (if one later looks at the commit, and needs to find out why).

Anyway, no harm.