For the record, this also works in gdb (and front-ends such as ddd): ignore <k> <n> where <k> is the breakpoint number and <n> is the number of times to ignore it. -- Kurt On Tuesday, July 2nd, 2024 at 12:41 AM, Mike Kaganski <mikekaganski@xxxxxxxxxxx> wrote: > On 01.07.2024 23:42, Sahil Gautam wrote: > > > Hi, I successfully built libreoffice on windows using LODE. The problem > > is that I cannot see stdout on the terminal, or in vscode's terminal. I > > rely on that for checking if opening this dialog trips this breakpoint > > or not, and how many times does it do so. using a debugger seems a good > > choice, but it's a hassle considering that UI can trigger a function > > changing colors n times, and I don't want to press F5 n times, it's not > > feasible. Is there any way to get the stdout on the terminal? > > > Since you develop on Windows, a natural choice would be using Visual > Studio for debugging. And it allows setting a special kind of > breakpoints, which outputs a string (maybe with different variables > values), and continued execution. This is in a sense superior to printf, > because it doesn't need a modification and compilation, but you can do > it at the runtime, changing the output dynamically, enabling and > disabling the breakpoints. The downside is its lower performance; so > e.g. putting such a breakpoint to e.g. OUString constructor would make > your debugging session crawl and last for days :-) > > In a reply to another mail, I mention that there is a proper console > mode on Windows since version 6.3. However, Cygwin's mintty has never > beed affected by the problem, so if you run from mintty, it should > output properly, even if you run soffice.exe. In Windows' cmd.exe, > calling soffice without an extension runs soffice.com automatically, and > also should give the proper console output. But of course, this is all > general considerations, and to advise something concrete, specifics of > your problem are required. > > -- > Best regards, > Mike Kaganski