Leaderboard

Yes, there is - use the TThread.OnTerminate event to signal your waiting code, such as via a TEvent object. Just know that the event handler is called in the main thread, so if that will cause a sync issue, you can always override the TThread.DoTerminate() method to call the OnTerminate handler directly (or do anything else) without syncing it, as DoTerminate() is called in the worker thread and calls the OnTerminate handle via TThread.Synchronize() by default.

As far as I can see, the TMS SmartSetup tool goes a long way towards bringing Delphi into a more modern system of being able to deploy packages rapidly and efficiently. It needs some more examples at the moment to make it accessible, but it seems to be competitive with tools that have been in Python, .Net etc for decades already that we are missing.

Not only that I don't agree, I recommend the opposite and for a good reason:🙂 Scenario Imagine you have Project1 that uses Library1 (Spring4Delphi or something else). 1. If you give your project to someone else and you have the DCU paths (for Library1) in the DPROJ file, you FORCE that person to install the dependent library (Library1) in exactly same place as you have it on your computer. If the user already has Library1 installed in his computer, he will have to change project's options. So, it is clear that this way of using paths is not portable. 2. If you use the IDE "Library paths" then the the information about the Library1 is not included in your project. If the user receiving your project already has Library1 installed (and he was smart enough to use IDE "Library Paths") then Project1 will compile in his computer without any modifications. This is the exact purpose of "Library paths": to keep the external libraries/dependencies separated from your projects!!!! - Delphi's help: Spring4D is a package! _ This is exactly what Delphi does: when you create a new project you don't have to specify where Vcl.Dialogs or System.SysUtils DCUs are for that project. The project can already find them because they are in the Library Paths. Why reinventing the wheel? _____________________________________________ This could also be bad advice if you have truly large projects. Why adding another few seconds to your already-2-minutes-long-compilation-time when you could use precompiled DCUs? Again, this would be counter-Delphi-way: When you start a new project in Delphi, you don't compile the Vcl.Dialogs.pas or System.SysUtils.pas. Your project will find and use the precompiled DCUs. _____________________________________________ I think paths are one of the least understood parts of Delphi, and therefore the most abused. I upgraded several large projects to use precompiled libraries and I showed off really big amounts of times from the compilation time, with no downsides. For most of my personal programs, the project (DProj) "Search Paths" are empty. God gave use Library Paths for a good reason. Let's use them. 🙂

It would help if you can post the code example here. With threads even slight change in code can make a difference. But the example in the link shows waiting for self destroying thread and this is something which cannot be done with such thread. Hanging is expected behavior.

Ok great, it forces you to change the name in all places, at least nicely supported by compiler and CodeCompletion, thats fair enough. 👍

Actually, it has uses - limited but it has. It can be helpful when you change the name of an identifier (variable, method name, etc) at batch and your batch/refactor tool will not change it also in the string (in the error message): ShowMessage('Error in MyMethod'); With NameOf your code will not compile, so you will easily spot and replace the now outdated variable name: ShowMessage('Error in '+ NameOf(MyNewMethodName)); But the fact that it doesn't work on the name of the current method... it makes it even less useful.🙂 I wrote about this here. Actually I was praying for something like this in my early days of Delphi. Now are better ways...