Anders Melander

Nice! To bad that there's no chance in hell that the Delphi compiler can compile it branchless. It could be hand-coded in asm but then the call to the comparer can't be inlined, making the whole thing pointless.

Fair enough, but I'm guessing that if you made the consequences of their choice clear to them they might reconsider. Remember to offer more than two choices: The bad choice, the right choice, and the super deluxe, over-the-top, choice. That way they can feel that they have a say in the matter 🙂

Yeah, but nobody ever asked me to implement the easy solution. For some reason, they all want the hard stuff.

Any classes that need to know what's going on with other classes, state changes, etc. I basically only implement classic events if I have a component that needs design-time event hookup via the object inspector. For everything else, it's notifications via interfaces (i.e. multicast). It has a higher cost up-front in terms of writing the code but down the line, it saves me when inevitably I need more than one notification receiver. @dummzeuch gave a real-world example. Yes, it can be solved in multiple ways. He solved it with a delegate chain (very fragile). You solved it by having the event source not use the event slot, but that still leaves you with a single-cast event. What if you have a form with multiple frames that all need to know when the state changes? With multi-cast you don't need to worry about if you will ever need to have more than one event consumer. With interfaces there's the added benefit of separation and, if you design things for it, no dependencies between the different parts.

The solution seems obvious... Don't use the OnClose event. Have the form broadcast a notification that it is closing and have the frames subscribe to this notification. eAsY.

Are you sure? It's the observer pattern. I use it literally all the time, like daily, but I must admit that even though it would be much easier to implement as delegates, so far I have always implemented it via interfaces: type IMyNotification = interface [...GUID...] procedure MyNotification(...params...); end; TSomeClass = class private FSubscriptions: TList<IMyNotification>; protected procedure Notify(...params...); public destructor Destroy; override; procedure Subscribe(const Subscriber: IMyNotification); procedure Unsubscribe(const Subscriber: IMyNotification); end; destructor TSomeClass.Destroy; begin FSubscriptions.Free; inherited; end; procedure TSomeClass.Notify(...params...); begin if (FSubscriptions <> nil) then for var Subscriber in FSubscriptions do Subscriber.MyNotification(...params...); end; procedure TSomeClass.Subscribe(const Subscriber: IMyNotification); begin if (FSubscriptions = nil) then FSubscriptions := TList<IMyNotification>.Create; FSubscriptions.Add(Subscriber); end; procedure TSomeClass.Unsubscribe(const Subscriber: IMyNotification); begin if (FSubscriptions <> nil) then FSubscriptions.Remove(Subscriber); end; versus type TMyNotification = procedure(...params...); TSomeClass = class private FMyEvent: TDelegate<TMyNotification>; protected procedure Notify(...params...); public property MyEvent: IDelegate<TMyNotification> read GetMyEvent; end; function TSomeClass.GetMyEvent: IDelegate<TMyNotification>; begin Result := FMyEvent; end; procedure TSomeClass.Notify(...params...); begin for var Delegate in FMyEvent do Delegate(...params...); end;

For older versions there's always this one: Multicast Delegates - An amazingly simple and elegant solution and, as far as I can tell, even more versatile.

No. It shows that there's some problem. It doesn't show that the bug is still there. Btw, I guess it's this one: RSP-27825 (status: Closed, resolution: Fixed, fixed version: 10.4.1). Or they could step on yours. 🙂

I don't think it is, but... ...since the TWICImage constructor calls CoCreateInstance you need to have COM initialized before that happens. As you've observed CoInitialize/CoInitializeEx does that. Remember though to check the result of CoInitialize(Ex); It will return an error code (it's not an error as such) if COM has already been initialized (on the calling thread). You should only call CoUninitialize if the call to CoInitialize(Ex) succeeded. If you search here I'm guessing the how and why has been explained many times.

Yes, div 2^n is compiled to an arithmetic shift (sar instruction) while shr n is compiled to a logical shift (shr instruction). Even if that would have been possible it wouldn't magically have become faster. The calculation of the index into the table is a (implicit) multiplication too so you would just be trading one integer multiplication for another - and adding a memory access.

I wish they would just deprecate AlphaFormat. It's an abomination that was supposed to make it easy to draw a 32-bit TBitmap with alpha. I guess it did that but what it also did was make it almost impossible to do anything beyond the single use case they could think of.

What about it? So it used to be shareware. That doesn't mean that it still is. As far as I have been able to determine the author, Graham Knight, has either vanished from the internet or he is the owner of that Github repository.

I suggest you install the components and run the Source Analyzer example. Then you can see exactly what information an Outlook drop contains. I would be very surprised if Outlook didn't offer the image as a file with a name (real or synthesized).

Only empty, published methods are removed. Are you saying that you manually add published event handlers?

I can't see why not. You haven't stated if your application is the drop source or the drop target, but if you can drop to/from Outlook from/to the desktop, then you can do the same from/to your own application.

It's always been this way. It would actually annoy me if they spent time fixing this instead of some of the more important stuff. Defeatism, I know.

procedure TFormFooBar.FormClick(Sender: TObject); begin end; { this comment prevents FormClick from being automatically removed } procedure TFormFooBar.FormCreate(Sender: TObject); begin // Blah end;

Don't sweat it. Take your time. Look at some code and try to understand what it does and how it does it. Don't rush it and eventually, it'll come to you.

Apart from this line... Result := TColor32(Integer(Result) + (aDiff.RAdj * $10000) + (aDiff.GAdj * $100) + (aDiff.BAdj)); ...it looks ok. The above doesn't take overflow in the individual color components into account so I'm guessing that what's happening is that the overflow causes the alpha to overflow from 255 to 0 (or some very small value). Do this instead: Result := HSVToRGB(H, S, V, TColor32Entry(aBase).A); TColor32Entry(Result).R := Max(255, TColor32Entry(Result).R + aDiff.RAdj); TColor32Entry(Result).G := Max(255, TColor32Entry(Result).G + aDiff.GAdj); TColor32Entry(Result).B := Max(255, TColor32Entry(Result).B + aDiff.BAdj);

Can you show us what ApplyColorShift looks like?

Please tag your post "Graphics32" or otherwise mention that's what you're using. My first guess would be that you forgot to set the ALpha pixel value in ApplyColorShift, but then I realized that you aren't drawing the ScrollerText bitmap anywhere... So, is it correct that you aren't getting any text even without the call to ApplyColorShift?

Always? I haven't done my own benchmarking but I thought arrays also outperformed linked lists for the simple search+insert/delete case: https://kjellkod.wordpress.com/2012/08/08/java-galore-linkedlist-vs-arraylist-vs-dynamicintarray/ (yes, I know it's about Java. potato, potato...) I mostly use linked lists for stuff like MRU/LRU caches, and only because I haven't bothered learning a more suitable structure (for caches, that is).

If I understand you correctly then you could just set ScreenImg.Bitmap.BitmapAlign=baTile and then display the other stuff on top of that with a TBitmapLayer.

It looks like you're using a Graphics32 TImage32 control to display the bitmap. You should have stated that as otherwise your code makes no sense. I don't really understand what it is you are trying to do. Would you mind posting a picture/mockup of your desired output and another of the experienced output?

Note that in Graphics32 I had to revert the change of the Box filter radius from 0.5 back to the original radius of 1. See: https://github.com/graphics32/graphics32/issues/209 Since you're using a radius of 0.5 you might have the same issue.