Anders Melander

By "3rd party" I mean 3rd party libraries. They seem to have all abandoned WinUI3. Likely because there isn't any demand from their customers. Come on. That document is 6 years old but even if it was written yesterday it wouldn't make WinUI3 any more relevant. Try harder. How does the existence of XAML Islands "prove" a demand? Do you understand that "prove" implies that "proof" exists? My mention of Clipper was in reference to your hyperbolic claim that "Embarcadero has been a leader in wrapping and integrating native APIs". If anything they have been known for lacking behind their peers, such as C++, C# and Java in this regard, so how can they be a leader? Delphi is very good at wrapping native APIs but the potential future existence of these wrappings doesn't make it a leader. They have to actually exist. Anyway, I've already spent more time on this topic than I care. Peace Out.

I think your arguments are all over the place but ignoring that, IMO they will not, and should not, waste resources on WinUI3. It's DOA and has no 3rd party support. Move on. LOL. Compared to what? Clipper?

Yes. Both of them. Very dedicated. If they wanted it fixed I'm sure it would get fixed. It's just a question of resources and priorities. They haven't got them so they've prioritized something else. I have consistently been able to get the IDE hung beyond recovery since Delphi 10. I know exactly what to do, and therefore I also know what not to do. It's pretty much muscle-memory by now. But I haven't reported it because it's no longer a problem for me and I would rather they use their limited resources on something that I can't work around. Improving the compiler, for example.

It's not a progress bar; It's a marquee. Thanks but I think I'll take OP's words over your interpretation of "his needs".

TProgressBar with Style=pbstMarquee. Update it by calling TProgressBar.StepIt.

If you're using TImage then you need to set Transparent=True: The help for TImage.Transparent incorrectly states that the property only applies if TImage.Picture.Graphic is a TBitmap.

If you look at the IDE form designer, you can see that that is also what it does; The client size stays the same between the two Delphi versions. Yes; It's missing the whole <compatibility> section so it basically gets the Windows XP treatment.

I wouldn't mind if they just released it as a technology preview (which is what it is) - on the side. But then what is this release exactly? Sure there are a bunch of bug fixes but have we been paying maintenance all this time to just get a major release (and this is a major release regardless of their silly numbering scheme game) with nothing but fixes for bugs that we already worked around long ago? Will we have to wait another year for something substantial? Two years? Maybe the roadmap can tell us - oh, wait; There's no roadmap, because stupid excuses that nobody ever believed anyway. I asked my manager today if we shouldn't just cancel our Delphi maintenance and gamble on nothing of substance being released the next 3 years (which is the break-even point). The last time we did this (XE3-XE8) we saved a bunch and didn't miss a thing.

The manifest of Delphi 10 and 11+ are probably different so Delphi 10 gets the XP window style, while 11+ gets the current window style. I don't have Delphi 10 installed anymore but if you can post its manifest then we can verify. Apart from that, if you rely on Form.Width/Height this will not only be a problem in the IDE but also at run-time where your application will use whatever windows style the host OS dictate. Use Form.ClientWidth/ClientHeight instead; Then you don't have to worry about the border width.

Wasn't rxLib abandoned in the nineties and merged into JEDI?

AFAIR this is a bug in TPNGImage. I believe it's already been reported but I could be wrong. What happens (and I'm doing this from memory), when you add a PNG to an imagelist (which as Remy pointed out "supports only BMP and ICO" (more on that later)), is that Delphi load the PNG into a TPNGImage, converts it to a 32-bit TBitmap and then adds that bitmap to the imagelist. The bug is that the bitmap TPNGImage produces is premultiplied (all pixel colors have been multiplied with their alpha; pRGB = RGB * A / 255) while the imagelist expects the bitmap to be not-premultiplied, so to say. The result is that you get a semi-transparent 32-bit RGBA bitmap which is too dark. I believe the premultiply problem can be worked around, in code, but I'm too busy to find the solution right now. With regard to imagelist only supporting BMP and ICO: That doesn't really matter in this case. First, let's forget about the ICO support since that is only relevant if you need icons' ability to contain multiple versions (size/color depth/etc) of the same image. That leaves BMP: The imagelist doesn't really contain BMPs which is a file format. It contains DIBs and in the case of a 32-bit imagelist it contains 32-bit DIBs in RGBA format. It doesn't matter if you add a BMP, PNG, JPEG or PCX to the imagelist. Internally it will just store a DIB representation of the image.

...and AFAIR there's a registry option to use UTF-8 without BOM if one wants to make life "more interesting".

You've most like setup your imagelist to use masked transparency (which is probably what your icons are using). I think they've done their part with regard to this. Now you just need to do your part and read the documentation: https://docwiki.embarcadero.com/Libraries/Sydney/en/API:Vcl.Controls.TImageList.ColorDepth https://docwiki.embarcadero.com/Libraries/Sydney/en/Vcl.ImgList.TDrawingStyle

Maybe not in this case but when you have lists or arrays of records it is most often much more efficient to pass a pointer around than to copy the records back and forth. I just showed you exactly how it's done. If this is performance sensitive, there are a lot of entries in the list and the records are large, then an alternative is to have the data in one list and an index into the list in another list TList<integer> or array TArray<integer>. Then you use the record list to hold the data and when you need to sort the data you just sort the index list/array. To access the data in sort order you must then use the sorted index list to get the index of the data in the record list. It's very easy but a bit hard to explain without a whiteboard. Anyway, forget about that for now. If you just want to sort the list on different record fields you can do so by passing a custom comparer to the Sort method, as Peter mentioned: type TMyRecord = record Foo: integer; Bar: string; end; TMyList = TList<TMyRecord>; TMyField = (mfFoo, mfBar); procedure SortList(List: TMyList; Field: TMyField); begin var Comparer: IComparer<TMyRecord>; case Field of mfFoo: Comparer := TComparer<TMyRecord>.Construct( function(const A, B: TMyRecord): integer begin Result := (A.Foo - B.Foo); end); mfBar: Comparer := TComparer<TMyRecord>.Construct( function(const A, B: TMyRecord): integer begin Result := CompareText(A.Bar, B.Bar); end); else exit; end; List.Sort(Comparer); end; and to use the above: begin var MyList := TList<TMyRecord>.Create; ...populate the list... // Sort the list on the "Foo" field. SortList(MyList, mfFoo); // Sort the list on the "Bar" field. SortList(MyList, mfBar); ...etc... end;

Works for me, Did you get it from this post: Otherwise, here's the original articles about it (OMG, I really need to get that old site updated): http://melander.dk/articles/alphasplash http://melander.dk/articles/alphasplash2/ and the source for that is here: http://melander.dk/download/ That source was written for Delphi 2007 so it probably won't work as-is in modern Delphi versions.