Anders Melander

Why not "context: pointer" instead of "context: UIntPtr"?

What can I say? Whoosh?

The pdf appears to be 🐸-encrypted 😉

I haven't used Access in... 25 years I think, so I can't help with specifics. My guess is that you need to set up a ODBC DSN using the ODBC Data Source Admin. Once that is done I think you can configure FireDAC to connect to the ODBC DSN.

It would probably be relevant if you explained what you mean by "no success". What errors are you getting, if any? What does your FireDAC connectionstring look like, etc.?

That's why they pay us the big bucks 🙂 Here's some links that might be relevant: https://learn.microsoft.com/en-us/office/troubleshoot/access/cannot-use-odbc-or-oledb https://how-to.aimms.com/Articles/129/129-MSACCESS-32bit-64bit.html

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.

It's not clear to me what exactly you are doing but you can use TList<T>.List to get access to the internal dynamic array of TList<T>. From there you can create a pointer to the individual elements in the array: type TMyRecord = record Foo: integer; Bar: string; end; PMyRecord = ^TMyRecord; begin var MyList := TList<TMyRecord>.Create; ... // Get a reference to the internal dynamic array. // Note that this reference, and any pointers to the elements in // it, are only valid as long as the list size remains static; // Once you clear the list or add items to it, the references are // stale becuase the internal array can be reallocated. var Items := MyList.List; // Get a pointer to an element in the array var SomeItem: PMyRecord := @Items[0]; // Clear the element SomeItem^ := Default(TMyRecord); // Modify the element SomeItem.Foo := 42; SomeItem.Bar := 'Hello world'; end; I assume your bubble sort is just an example. Otherwise, use TList<T>.Sort to sort the list.

Interesting but... TLDR; the "50x faster" only applies if: You are using the C++17 std::filesystem now. You are using GetFileAttributesEx now to get the attributes. In IOUtils the TFile.GetSize function is the only one using GetFileAttributes* directly. Unfortunately IOUtils defers to SysUtils for many of its function and there's widespread use of GetFileAttributes* in there. Interestingly SysUtils contains an internal GetFileAttributesExEmulated function that is implemented using FindFirstFile but unfortunately that is only used from the FileAge functions and only in case of a sharing violation.

Works for me; The GIFs load and display without problems. It's probably a problem in your code (have you remembered to reset the stream position before load?) but you don't have to pursue it for my sake. I was just curios.

Okay but do you remember what the exception was? - or if you have one of the GIFs I can try for myself. I'm just curious because AFAIK there no known bugs in the GIF reader (and I wrote the original TGIFImage code back in... 1997).