Leaderboard

ADUG is ending its archaic mailing list and moving into this century with a new web based forum, available here: https://forums.adug.org.au/ Anyone can join and discuss our favourite tools. 🙂

Enable debug info - should not change the addresses if the code and all other options are exactly the same.

Whenever you stop at some breakpoint you can use it, make sure to prepend $ when typing the address because hexadecimal

Ranges of for loop counter are calculated once loop starts and won't change later. You'll either have to add another for loop inside or use another kind of loop (while, until + manual counter check and increment)

You seem to have two main goals - do a little work after each thread completes and coordinate a bigger task once everything is done. When each thread completes you could fairly easily post a user defined windows message and have the form update the state when the message is received. For the second, more complicated synchronization issue of waiting on a varying number of threads to complete, since your total count is under 64 you could go with WaitForMultipleObjects as previously suggested. However, if your thread count might rise above that fixed limit, you may want to consider utilizing TCountDownEvent for this second task instead. Here's a blog post on it: https://www.ideasawakened.com/post/test-driving-delphi-s-tcountdownevent with corresponding example code on GitHub.

We use our https://github.com/synopse/mORMot/blob/master/SynLog.pas Open Source logging framework on server side, with sometimes dozens of threads into the same log file. It has very high performance, so logging don't slow down the process, and you can make very useful forensic and analysis if needed. Having all threads logging in the same log file is at the same time a nightmare and a blessing. It may be a nightmare since all operations are interleaved and difficult to identify. It is a blessing with the right tool, able to filter for one or several threads, then find out what is really occuring: in this case, a single log file is better than several. For instance, one of our https://livemon.com server generates TB of logs - see https://leela1.livemon.net/metrics/counters - and we can still handle it. This instance for instance is running since more than 8 months without being restarted, and with hunderths of simultaneous connections, logging incoming data every second... 🙂 We defined our simple and very usable log viewer tool - see http://blog.synopse.info/post/2011/08/20/Enhanced-Log-viewer and https://synopse.info/files/html/Synopse mORMot Framework SAD 1.18.html#TITL_103 This is the key to be able to have something usable from heavily multithreaded logs. So if you can, rather use a single log file per process, with proper thread identification and filtering.

Generuje súbor * .elp. V ich prehliadači to vyzerá takto. Mám tam málo, pretože v dpr boli chyby. Keď sa však dostanem k akýmkoľvek ladiacim očiam (napríklad k oknu CPU), keď spustím aplikovaniu anti-IDE s ladením, nie sú pripravené žiadne nastaviteľné telá prehladávača. Toto je opísané v príručke. Myslím, že je to tiež Zobrazené vo videu.