Leaderboard

The reason is quite simple: the component is based on a Windows common control which is intended to serve as storage for small images/icons used for menu items, buttons, listview items. To reduce the consumption of GDI handles the control merges all added bitmaps into one large bitmap for storage. That's the reason all bitmaps added are forced to the same size, this way the imagelist can calculate where on the combined bitmap each image resides and then paint that part to the target location. There is a maximum size to a GDI bitmap, so this puts limits on the size and number of the images you can put into a TImagelist. Looks like the control is simply not suitable for your task.

TThread.Synchronize() is not limited to just GUI work, though that is what it is commonly used for. It just serializes threads to run code though the main UI thread, nothing more. TThread.ForceQueue() is meant to be used in the main UI thread only, worker threads should use TThread.Queue() (or TThread.Synchronize()) instead. TThread.Synchronize() and TThread.Queue() bypass the internal queue when they are called in the main UI thread. TThread.ForceQueue() was added so the main UI thread can queue things up, too. Or, simply wrap the variable behind a thread-synchronization object, such as TCriticalSection, TEvent, TConditionalVariableCS, TMREWSync, TInterlock, etc. Many different ways to protect a variable from concurrent access across multiple threads. Not really. Android runs on top of Linux, so its base threading is pretty similar to other platforms. However, there are restrictions on what can and cannot be executed on the UI thread, for instance, but that is artificially enforced by Android's implementation of Java, not Linux itself.

Sometimes, when entering new areas of knowledge, you might not even know what to expect. Hence, a guiding hand can go a long way. Most people appreciate those that offer help without conditions.

Sure, I could have sugar coated it better. The point was really that when the expectations turns out not to match reality then one should question the expectations first.

IMO, that was not very helpful. If you are a new user, you may need to be guided on how to do it right, not just be told that you are doing it wrong.

Isn't that what Build is for (in contrast to Compile)? AFAIK, these Internal Errors happens because the compiler doesn't clean up properly. I doubt that this can be fixed by just adding an option to do so.

It was a request to change the exception to a proper message before Embarcadero included it in D12. Unfortunately the answer was it is a known limitation of Delphi.

Well, I havent made any further attempts to create á custom classes.dex since my original issue (the missing android-support-v4.jar) hasn't been solved. I just attempted to use the XCScanner-libray by including the .jar file in the project. I was afraid the init method might be the issue here, and judging by what you say the solution will not be trivial. Given the fact that this is not a pressing issue right now and the customer will use the hardware buttons on the device to trigger the barcode reader anyway I think I'll park the issue for now. Thanks for your help and insights!

Yes, although more of a helper. Removes the with identifier do [and begin/end statements if present] and copies "identifier." to the clipboard so you can easily paste it where needed. It does not automatically determine which fields need the "identifier." added. Very simple example: Before: with Form1 do begin Left := 200; Top := 100; end; Invoke MMX Convert with: After: Left := 200; Top := 100; And "Form1." is in the clipboard to be manually pasted where needed.

Hopefully not with Shift-Alt-W (MMX Convert with statement) is a good friend of mine when "migrating" legacy Delphi code.

Pretty much any programming language that lets you do bitwhacking can do this. Just like anybody can walk on their hands or ride a unicycle with some practice. The question is, "Why?" Just because you can? Most people would argue that C is far better for this sort of thing. Sure, Delphi already does this, but I don't see it being used as a language of choice by devs who do a lot of bitwhacking, like gamers. But at some point, this becomes a circular argument: Why doesn't Dephi support language features that most contemporary languages now include? Because nobody uses Delphi for that purpose. Why is that? Because it's too inefficient without the built-in language support. As if that's going to encourage the Powers That Be to take an "Add it and they will come" attitude... I want to see enhancements that make the language safer, and make it easier to use with less verbiage for things that other languages now routinely support. Constantly offering-up verbose and unsafe workarounds is not encouraging to anybody.

Maybe you should think a bit more about that. Ideally until it is no longer a mystery. What possible reason could there be for that limit? The 16x16 default is a big clue...

Your TImageList seems to contain 16x16 pixels images. That's why it is pixelated. Use the same size - in pixels - as the source image.

I've searched 2 hours long for an answer: - What is the main difference between OpenSSL 3.0.x / 3.1.x / 3.2.x / 3.3.x ? Here is what I've found: The main difference is the support time vs. speed issues vs. new features. 3.0 was reported to be slow, but it will get the longest support (LTS): 2026-09-07 3.1 is a "middle solution", much faster but shorter support: 2025-03-14 3.2 is currently the recommended version, (but it has shorter support time than the LTS): 2025-11-23 1.1.1, 1.1.0, 1.0.2, 1.0.0 and 0.9.8 are now out of support and should not be used 3.3 is only at alpha state yet.