Anders Melander

https://www.sourcetrail.com/blog/open_source/ Also Wow. Bold move and I hope it turns out good for them. I can't help but think of Borland who went for the exact opposite solution (remember Inprise?) and almost killed Delphi in the process. And we're still paying the price for that fiasco - literally.

You need to examine the call stack of all the threads. When you break the call stack is just shown for the currently active thread which is rarely the one you're interested in. P.S. I can see from your video that you have DropBox installed...

If you can reproduce the problem then simply run the application in the debugger, break when the problem occurs and examine the callstacks. ...however; My usual advice when people experience this kind of progressive or periodic slowdown/lockup is to uninstall the various cloud storage services they have running (ITunes, Google Drive, OneDrive, etc.). Solves the problem in 9 out of 10 cases.

I've been using it since the first version (which AFAIR was before XE) with no major problems. Maybe because my style is pretty standard (aka the One True Style ). One thing I've never gotten to work though is formatting a block of text: It always formats the whole file. No biggie. It's usually the first step I do when I'm brought in to fix other peoples code.

To paraphrase David Heffernan: That is utter nonsense and it doesn't appear that your Professor Lee has much practical knowledge about how to work safely with threads. Or maybe he's just using hyperbole to get a point across. Under any circumstances, Quoting academia? To disprove the opinions of a professional, highly skilled and experienced developer? Really? How about some arguments based on your own knowledge and experience... Many of us use threads on a daily basis and do so without wreaking havoc in the universe. If you understand the pitfalls of multi threading, know how to protect your resources, synchronize execution, understand race conditions, etc. etc., then threads are just another tool in the box. If you don't understand threading then yes, it will hurt you in a gazzilion ways you literally (and I use that word in the European sense) didn't think possible.

Actually it might. One of my grieves with the Refactor menu item is that if you accidentally move the mouse over the menu item (e.g. on the way to the View or Project menu item) then there's a noticeable delay (very noticeable on low end systems) as the IDE loads the refactor stuff (among it the J# run time I suspect) in order to populate the sub menu. Agree, but I don't think I'll have more to contribute on the subject.

Yes but that also removes the stuff I use and which actually works (mostly): "Find References" and "Rename".

Oh... This is the GExperts sub forum... I didn't notice that so I actually thought you meant the IDE main menu (which is what I was talking about). Well then, pls ignore what I said.

They can start by getting rid of the Refactor menu - and that might also improve the stability of the IDE.

Then the thread will be killed when the application terminates. The point is that it's better to forget about the thread, report a timeout and continue as if the thread had been forcefully terminated. Of course if the thread has allocated or is blocking resources then that solution might not work.

I'm assuming the above is just an example to explain what you need - since if you can kill the thread from within the thread, then the thread isn't frozen and you could just exit it the normal way. I completely agree. Just don't do it. What you could do is signal the thread (use an event, a boolean, whatever) that it has become thread-non-grata and then just forget about it. If the blocking call ever returns then your thread can check the signal and terminate. E.g. something like this in your TThread.Execute procedure TMyThread.Execute; begin while (not Terminated) do begin CallStuffThatMightBlockForever; if (FNotInterestedAnymore) then break; end; end;

Additionally, RegSaveKey doesn't save in .reg format but in registry hive format. There is no API for saving in .reg format.

I'm afraid I can't answer that. Supposedly there used to be a registry key that could do the trick (HKCU\Software\Embarcadero\BDS\19.0\FormDesign\DefaultFont) but that didn't work with the embedded form designer and as far as I can tell it no longer work with the detached designer either. I guess you could create an IDE plugin that modifies the form designer but that's probably more work than it's worth. Maybe just a design time package that modifies Application.DefaultFont like above will do the trick, but that will affect the whole IDE. FWIW I understand the OCD in you that wants the form to use SegoeUI at design time but it shouldn't really matter. If you have designed it "properly" then the form should be able to display correctly with both SegoeUI and Tahoma. After all you don't know what font the end-user will be using.

I guess it's a matter of perspective. If you didn't expect the thread to start until after the constructor then I can see how the behavior would be seen as a bug. I never expected it to behave any other way so to me it was just an annoyance. A bit like FreeOnTerminate. A pretty good way to shoot one self in the foot.

That must have been around the time when I stopped reading the documentation 🙂 I can't see why it would be classed as a bug though.