Remy Lebeau

If the component does not have extra design-time functionality that directly interacts with IDE APIs (property/component editors, OpenTools plugin, etc), then you do not need to make a separate design-time package. You can create 1 package and mark it as being BOTH a runtime package AND a design-time package. That will work just fine.

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.

Works fine for me just now.

Setting Action=caFree in the OnClose event is a DEFERRED destruction. It does not free the Form right away, it postpones the actual destruction until control flow returns to the calling thread's message loop, THEN the Form is freed when it is safe to do so (ie, no other messages are being processed). So it doesn't matter if the Form is owned or not. If the Form is owned, and the Owner destroys the Form before the caFree request is processed, then the request will simply get ignored since there is nothing to Free anymore.

Be sure to file these issues to Quality Portal so Embarcadero sees them for future updates.

Depends on your needs. You could use GetLastInputInfo() in a loop/timer. Or you could use SetWindowsHookEx() or RegisterRawInputDevices() to receive real-time events from the mouse/keyboard directly.

OK. But my point still stands. Other non-OpenSSL libraries can be plugged into Indy with a little work.

Put the PNG TImage on top of another TImage, or a TPanel, or whatever you want, that has the desired background image.

I would use PWord: function SomeFunction(segment_ptr: Pointer; segment_count: Integer ): TSmallintArray; var i: Integer; p : PWord {absolute segment_ptr}; begin SetLength(Result, segment_count); p := PWord(segment_ptr); for i := 0 to segment_count-1 do begin Result[i] := SwapInt16(p[i]); // or, if POINTER_MATH is not available on PWord: // Result[i] := SwapInt16(p^); Inc(p); end; end;

Technically speaking, Indy DOES NOT depend on OpenSSL specifically. Indy uses a plugin model so that any SSL/TLS library can be used, all you need is a TIdSSLIOHandlerSocketBase-derived class to wrap the library's API. It is just that Indy provides a DEFAULT class which uses OpenSSL (TIdSSLIOHandlerSocketOpenSSL), since OpenSSL is portable to multiple platforms. But Indy as a whole doesn't care which SSL/TLS library you actually use at runtime. For example, Eldos SecureBlackbox provides an Indy SSLIOHandler for its own SSL/TLS implementation. And eventually I would like to provide an SChannel SSLIOHandler as a replacement for OpenSSL on Windows.

GetTopWindow() returns the CHILD window that is at the top of the z-order of a specified PARENT window. GetActiveWindow() returns the currently active window belonging to the CALLING THREAD (or another thread that is assigned to the message queue of the calling thread). Neither of those are well-suited for finding the active window of ANOTHER app. Have a look at GetForegroundWindow() instead.