Remy Lebeau

According to my notes, assigning explicit ordinal values to enums has been supported since D6. I haven't tested it in earlier versions, though.

Recursion, or multi-threading.

The only time this should make any real difference is if Search() is re-entrant. If it is not, then don't worry about this, use whatever style you are comfortable with. But if it is, then you can't use class members, as they could get overwritten during one Search() while another Search() is still running.

I really wish Delphi would stop mimicking DotNet. Delphi IS NOT DotNet!

Yeah. They should really rename either System.TMonitor or Vcl.Forms.TMonitor to avoid that conflict. Frankly, I never understood why the System one was named TMonitor to begin with. Since it is inherently tied to TObject, maybe something more like TObjectLock, TObjectSync, TObjectMonitor, etc would have made more sense. Of course, on the flip side, for the Vcl.Forms one, maybe something more like TDisplayMonitor, TScreenMonitor, etc would have made more sense. Oh well, too late now, I guess.

What is the actual problem you are having? What does your code actually look like? Which SMTP component/library are you using? You need to be more specific.

There are some 3rd-party INC files like that already. But different vendors have different requirements for different feature use-cases. I can only speak for myself, but I don't like using monolithic INC files that define lots of things that I'm not actually using. That is why authors typically use their own INC files to tailor for their particular requirements. What we really need is a compiler-level feature detection system instead. C++ has had something like that standardized for awhile now: https://en.cppreference.com/w/cpp/feature_test https://en.cppreference.com/w/User:D41D8CD98F/feature_testing_macros

Which version of Delphi are you using? Recent versions have better support for DPI. Have a look at things like the TForm.Monitor.PixelsPerInch property and the TControl.ScaleForPPI() method. Try something like this: Height := MulDiv(iDesiredHeight, Monitor.PixelsPerInch, 96); Or this: Height := iDesiredHeight ScaleForPPI(Monitor.PixelsPerInch); I don't know if these are actually correct or not. I don't design UIs for multi-DPI systems.

This is the way Indy does it. Then the conditional is defined only for D2006+ (and FPC), and only for release builds.

Are you really using a relative path to the file? Do you have the same problem when using an absolute path?

You can download it from the current pull request on GitHub: https://github.com/IndySockets/Indy/pull/299 It has not been merged into Indy's main codebase yet.

Show() is non-blocking, so your example would reach myForm.Free() before the Form's window is actually shown to the user. It is perfectly safe to use caFree with a modal Form. The Form object remains alive until after ShowModal() exits and control returns to the main message loop, THEN the Form is destroyed. If you want to get results from the Form, you just have to do so immediately after ShowModal() exits, which is the best time to get the results anyway. If you need the results at a later time, save them somewhere that you can get them back when needed. So, you would either: -auto-create a Form and then Show()/Hide() it when needed. Let the TApplication handle destroying the Form during app shutdown. - Create() and Show() the Form, then Free() it when you don't need it anymore, or use OnClose to caFree it. - Create() and ShowModal() the Form, and then Free() it (directly or via caFree) after ShowModal() has exited.

Then they likely weren't being owned properly to begin with. Yes. No. In fact, that even makes it more complex, because a Parent also destroys its child controls when itself is destroyed, outside of TComponent ownership. destructor TWinControl.Destroy; var I: Integer; Instance: TControl; begin ... I := ControlCount; while I <> 0 do begin Instance := Controls[I - 1]; Remove(Instance); Instance.Destroy; // <-- HERE I := ControlCount; end; ... end; I have VCL sources going back to Delphi/BCB 5. Here is the TComponent destructor in D5: destructor TComponent.Destroy; var I: Integer; begin Destroying; if FFreeNotifies <> nil then begin for I := FFreeNotifies.Count - 1 downto 0 do begin TComponent(FFreeNotifies[I]).Notification(Self, opRemove); if FFreeNotifies = nil then Break; end; FFreeNotifies.Free; FFreeNotifies := nil; end; DestroyComponents; if FOwner <> nil then FOwner.RemoveComponent(Self); // <-- HERE inherited Destroy; end; IIRC, there was not much in the way of sweeping changes between D1 to D5, so I agree with Uwe that TComponent ownership likely dates back all the way to D1, when the VCL was first introduced.

If it is owned, it is destroyed when its Owner is destroyed. Otherwise, it is leaked and not destroyed at all. When the process exits, the OS will reclaim the leaked memory. Using Action=caFree in the OnClose event is the correct way to do that. Whether or not the Form has an Owner is irrelevant. An owned object can be destroyed at any time, even before its Owner is destroyed. If the object is destroyed first, it will simply remove itself from its Owner so that that Owner does not try to destroy it again.

Works fine for me just now.