Dave Millington (personal)

Thankyou 🙂

Answer: Yes. This is awesome. Did you ever publish it anywhere? I have lots of questions - things like, are you using the editor painting API to paint? This is my personal DelphiPraxis account, but you could email me at david.millington@embarcadero.com -- I'd love to chat about it.

Idera is looking for a German-speaking sales engineer, who would work with C++Builder and Delphi. I suspect the ideal person would know Delphi/CB, be a dynamic outgoing energetic salesperson, etc. The job post has the description. This isn't an official forum post from me; I just want to share the ad so as many people see it as possible. If someone could translate it to German and post on the main forum I'd really appreciate it! 🙂 This is the job link -- know anyone who'd like to work for the German sales team? https://idera.applytojob.com/apply/N79e9IEp2J/EMEA-Sales-Engineer-Embarcadero

With this plugin, it will still pause in the same place (it won't wait for execution to move) but if there is a call stack entry which is in your source, which calls the code that is in, eg, Windows, it will show you that line. Ie it tries to show you the bit of your app you have control over when you pause. This plugin handles this too - unless there is a reason to pause and make a non-main-thread thread the current thread (eg an exception was thrown in a thread) then when you pause, it will show you the main thread by default. You can control this: it's called the 'thread of interest', which is the thread that will become the current thread when the process is paused. It just defaults to the main thread if it hasn't been set another way. Each thread's call stack has its own pause button, and clicking that makes that thread the thread of interest when pausing - ie, the function is "pause in this thread". Super, super cool. I agree, difficult to implement. I can think of a couple of ways - run until return in a loop, until the top call stack entry is in your source; or examining the stack and placing a breakpoint where it returns (hard, because you have to figure out where it will return to, ie the next instruction.) It is worth thought. Thanks for the suggestion.

More issues fixed, I would hope! We've actually found and already fixed or plan to fix several already, which were found by this plugin.

Thanks Lars. That sentence was meant for @Stéphane Wierzbicki, to ask for a QP entry with the same info as in the comment. This is what I usually try to do. Years ago, there was the "crash fast, crash early" concept. I worked on software built like that and the idea was, if anything was wrong, bail and it would be fixed as a bugfix. Lovely concept, but it made the software seem really unstable to users. In practice, many things can be caught and either worked around, or at least shown as an error message or raised some other way, and slowly over time we changed the software to work like that. It functioned just as well and customers were happier. Personally I think the debugger here, as a service invoked by the ToolsAPI, should never show UI but should exit safely and return an error that the invoker can handle as it sees fit.

I suppose bug reports had to start arriving at some point...! Asserts in production code is not a good practice. This, unfortunately, is in the debugger itself. I agree re asserts - I brought this up with the debugger team once, I will need to revisit. In terms of fixing it, since it's a debugger bug, the main way is to work around it in the plugin. I have code already to do this for some areas. Could you create a QP report with the full call stack at the time of the assert, please? One reason you might not have seen it before, even it being a debugger bug, is that the plugin uses the debugger a lot more than the IDE does by default - the IDE looks at a single thread at a time; this plugin scales debugger usage by the number of threads every single time you pause, step, etc. So a rare debugger bug may become more visible. Luckily we can work around many. Can you enter a QP with that call stack please? As it is, it doesn't look like it's in the plugin itself. The comment I wrote above to Lars about seeing debugger issues may apply here.

Thanks Mike! I hope the editor markup makes the editor more pleasant / modern to use, even if you don't use multithreading. This GIF shows it: https://i1.wp.com/blogs.embarcadero.com/wp-content/uploads/2020/12/editor-before-and-after-7862533.gif?ssl=1 (Note for that to really shine, you need to edit your editor colour scheme to turn off solid backgrounds - just check the 'Use default' checkbox for each element, like a breakpoint, that changes the background colour.)

A new IDE plugin aimed at helped debugging multithreaded apps! https://blogs.embarcadero.com/new-ide-plugin-parnassus-parallel-debugger/ The plugin: Displays all thread call stacks next to each other Lets you step over, run, etc a thread by itself, not the whole process Shows CPU usage by thread Editor integration to see where threads are executing, so you can easily see what other threads are in the same area of code and more... This has taken me five years to write! That said, most of that was downtime due to working too much time to spend time on this - this release is the result of working weekends since August. It's version 1, and I plan to add some more features over the next few months.

Hi, I've had lots of enquiries recently about when Bookmarks and Navigator will have a version available for 10.3 - they've been updated and new features added for every release until now. I'm please to say they will be available with the upcoming version of RAD Studio (10.3.1) which is coming out soon. The reason for for being included, and for the lack of news about a 10.3-compatible release in the past month, is that the plugins have been acquired by Embarcadero and so will now ship with the IDE itself. This is great news. I wrote the plugins originally to add features I wanted to the IDE, and hundreds (thousands, actually!) of developers have given great feedback. It's great to know the features will be available to everyone. In addition, due to the pressures of work, I haven't had much time to maintain or extend them recently, and so having them under Embarcadero's wing means they'll live on and be developed as part of Delphi and C++Builder itself. More info in the linked post! - David