Anders Melander

It's really hard to understand what you are doing from your description. Please show us the code of a minimal example instead (and please use the code tag). // Like this

Nice!

In TFormSplash.UpdateBannerImage: if (Scale = 255) then PixDst^ := PixSrc^ else if (Scale = 0) then PixDst^ := PixSrc^ or $00FFFFFF // *** Change this *** else begin RGB := PixSrc^ and $00FFFFFF; RGB := RGB xor $00FFFFFF; // *** Add this *** PixDst^ := (PixSrc^ and $FF000000) or (Div255((RGB shr 16) * Scale) shl 16) or (Div255((RGB shr 8 and $FF) * Scale) shl 8) or (Div255((RGB and $FF) * Scale)); PixDst^ := PixDst^ xor $00FFFFFF; // *** Add this *** end; This isn't the most elegant solution but since the original code was a bit of a hack (which is also why the solution isn't obvious at all) I guess it doesn't matter. Anyway, what it does is invert the color of the source pixel, blend it with the (black) text, and then invert the result again.

Very nice!

Keep digging

I dunno. I think it's pointless. I mean, properties? Pfft! What's the point? Delphi is dead anyway and if there's one thing the past 30 years has shown it is that the design is flawed beyond repair but we were just too ignorant to notice. If only we had been told about this before. The shame is unbearable.

Yes, yes, we see now. How could we have been so blind? Totally different things. Totally! Now, run along.

Are you okay?

The inconsistency, as you call it, is by design and just because you want the design to be different doesn't make the design wrong. Even Windows' own modal dialog function works the same way; Internally it implements a message loop which exits once a flag has been set (by the EndDialog function).

If you use ShowModal then you are using the modal loop built into the VCL which relies on exiting the loop when ModalResult<>mrNone. If you disagree with that design then don't use ShowModal; Use Show and build your own modal handling around it. And good luck doing that without a loop which monitors some kind of state flag. I don't think you have thought this through.

That makes better sense because there was something really fishy about the prerequisites of that project. I once designed, on paper, a large enterprise support system in which one of the key components was a telekinetic interface. The goal of the design was to get fired (long story). It sounds as if these people used the same strategy.

I agree. One of the things that have helped me tremendously over the years as a software developer is my (hobby) background in first analog electronics and then digital, hardware and then software. It gives one a deep understanding of how things work and why. There was also an early phase where I ventured into chemistry but, although I got really good at blowing shit up, I don't think that particular skill set has helped me much 🙂 (and thanks 😘 )

You don't need an owner; Just specify nil as the owner in the constructor and remember that you have to destroy the object in the thread destructor (or on exiting Execute, if you create it there). Generally, the purpose of Owner is to have a TComponent destroyed automatically when the owner is destroyed, which is handy when you place stuff on a form. For dynamically created components it is better to control the lifetime (Create/Destroy) explicitly so you have complete control of what is going on and when. It also makes the code easier to understand when you don't rely on implicit behavior.

Yes. It doesn't hurt but if you are not referencing the type then you might as well delete it. I couldn't spot any obvious issues after a brief look through the source. One thing I would do though, is to move the TCommPortDriver.Create into the Execute method so it is constructed in the context of the thread, instead of the calling thread (which is supposedly the main thread).

So use an installer or zip the files. I'm not buying the argument that users can't figure out how to unzip a file or run an installer. IME, they can if they have to.

Yes it is because it trashes the page cache. If memory is low then something else has to be paged out before the exe can be extracted to memory - and then paged out.

CommPortReceiveData is a method pointer. @CommPortReceiveData is a pointer to a method pointer. You have declared TCommPortReceiveData as a "procedure of object". That makes it a method pointer so this: procedure CommPortReceiveData(Sender: TObject; DataPtr: Pointer; DataSize: Cardinal); is wrong (it's not a method; It's a procedure) while this: procedure TUploadThread.CommPortReceiveData(Sender: TObject; DataPtr: Pointer; DataSize: Cardinal); is correct. You haven't declared the method. You have declared a pointer to a method. Your declaration in TUploadThread should look like this instead: TUploadThread = class(TThread) private ...other stuff... procedure CommPortReceiveData(Sender: TObject; DataPtr: Pointer; DataSize: Cardinal); ...more stuff... end;

I wouldn't know; I'm not confused - but that shouldn't stop people from explaining if they find joy in that. It should have been obvious that I know recent Delphi versions doesn't support being installed on Windows 7, given that I've installed and run several versions on Windows 7 and of course got told by the installer that it wasn't supported. I also stated that I hadn't encountered any problem with Delphi applications running on Windows 7.

And it shouldn't; It is functionality that belongs in another layer. Keep it simple.

Trace Into = Step Into But you don't need to trace into. You can just place a breakpoint inside your square function. This is a very simple problem so I suggest you try to single-step through it "in your head" first; What happens when you call square(0), square(1), etc.

Thanks for clearing that up - or not.

Okay, but it seems it doesn't. At least I haven't encountered anything in it that did.

I don't think that list is up to date given that Delphi has complained when you tried to install it on Windows 7 since 10.3 (AFAIR). That said, I upgraded my main system from Windows 7 to 10 last year but before then I didn't have any problems with the IDE or applications not working on Win7.

Btw, you should let the TSizeableLabel own the HostedLabel so this: HostedLabel := TLabel.Create(AOwner); should be: HostedLabel := TLabel.Create(Self); - And there you have an example of when to use Self. Now since the HostedLabel is owned by the control, it will be destroyed automatically when the control is destroyed (the base class TComponent takes care of that), so you can must get rid of the HostedLabel.Free.

If you search here for "Style guide" I think you can find some good ones. Be aware though that most of them will pretend to teach the One True Style and that is obviously false because I haven't published it yet 😉 TCustomControl is probably the easiest to work with. You'll be using a window handle per handle so it's not super optimal, but I wouldn't worry about it unless you'll be using hundreds of these at the same time. With the handles as separate controls you should also be able to generalize your control so it can attach itself to any TControl instead of embedding it (like I what I thought you were doing - good thing I didn't delete the comment 🙂 ).