A common pattern seen in Delphi code is the “code inside an event handler” syndrome. Lines and lines of code are placed inside an event handler. Not enough, these event handlers are often called directly from other places in the code – just because the code inside it needs to be executed. Take that as a big sign of code smell!
You know what? The event handler is not the right place for that code.
Extract it into a separate method – or probably more of them. Name those methods so that the name describes what the code executed is supposed to do. (It is probably not doing that, but that is a case for debugging.)
You can give some extended description in a comment to the method. If you have Document Insight (you should have the Express version with any recent Delphi), use it to display this comment wherever you hover the mouse over that method name.
Place the method calls into the event handlers. May be, you can write a little comment that explains why you are calling these methods. Don’t reword the method names here.
Remember: The event handler names tell you when that code is executed, the method names tell you what is executed and the comments tell you why it is executed.
BTW: Don’t try to be clever and rename the event handler so that its name resembles the what. You will have a hard time to find out the when! It would only be stored in the event wiring of the DFM and needs the Object Inspector to see it. It only makes the code harder to read. Keep the event handler names as given when possible. In case it is wired to multiple events, name it according to its usage (like DataSetsAfterPost), not its purpose.
Show Build Groups Pane inside the Project Manager. This will attach a new window inside the Project Manager where you can manage your build groups.
, enter a decent name and you end up with a list of all available projects from the current project group. By default each project comes with its current build configuration and platform.
