Leaderboard

You really want to do this in an automated way, so that you can build in a scripted fashion.

I prefer to have FormCreate, FormActivate, FormClose, FormDestroy, and related stuff at the top so I can see the main flow. One practice I've seen used in many projects is to have a static procedure at the top that's used to create the form dynamically and initialize things. Otherwise, I try to group methods that are related, so if there are several methods related to a ListView, they'll be grouped close together. Sorting alphabetically can be annoying, especially when people stick a 3-letter prefix on method names to say something about the type of control they're for.

Hi Stefan & Peter, Thanks! I'm assuming most users will have a two or four core system. But power users may have 64 cores; it was really them I was thinking about. Truth is, I need to stop optimizing at this stage and focus on the actual algorithm. Thanks again, Steve

Using threads to do thing in parallel obviously only works efficiently if the "things" do not depend on each other. As soon as a thread has to wait on the results of another the processing slows down and the chance of deadlocks goes up. Also, using more threads than the hardware has cores/cpus quickly gets you to a point of diminishing returns, since the OS has some administrative overhead to manage the threads. So, don't overdo it, especially in a scenario like a parallel for loop, where the code can only continue after the loop has finished completely it may be more efficient to split the loop into several and run each in its own thread. If the loop does not have that many iterations and executes each round fairly quickly setting up the individual tasks in a parallel for may consume more time than you gain by doing stuff in parallel. There is no substitute for thorough testing and timing in such a scenario.

It turned out it was the wildcard in the Accept header to cause this. I just pushed a fix that should also apply to your case and you may no longer need to instruct the Accept header all the times. Branch: develop, link to the commit: https://github.com/andrea-magni/MARS/commit/b8d5768b65072ff403de3c60e17688e8e95b1d9a Sincerely, Andrea

Most better ICS applications use Async methods so are fully event driven, allowing multiple connections are the same time in a single thread. So most of the code goes in various event But sync calls are easier to use from a program flow perspective and the code can either be in the event are after the sync call, although exceptions cause trouble which is why I added ResponseNoException. But sync programs are less suited to multiple connections or tasks at the same time. In event driven applications, you usually use messages from an event to start something new or a triggers in a timer event to start another connection 60 seconds later of something, I do that a lot. Angus

The Delphi IDE has the quite useful option to add custom entries to the Tools menu. These entries call external programs with some “Macros” that reference the current IDE status, e.g. the currently active project or source file and some of their properties like the output directory or the current editor column and row. GExperts already enhances the Tools Properties dialog by adding auto completion for the file name and the working directory (for Delphi 6 and 7 it also adds support for Drag and Drop, but that doesn’t work for later versions). It has always irked me that there was no easy way to port these custom tools entries from one Delphi version or installation to another. I always had to copy and paste four fields to achieve that. GExperts now adds two new buttons to export and import the current entry: Read on in my blog post https://blog.dummzeuch.de/2019/06/08/new-gexperts-ide-enhancement-export-and-import-entries-for-the-tools-menu/