Leaderboard

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.

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.

I believe the authentication POST problem was mainly a simple literal, if FOutsideFlag and (not (hoAllowOutsideRoot in FOptions)) then Flags := hg403 else Flags := hg404; where hg404 should be hgSendDoc. But something else is going on I'm still tracking, RequestDone should be called for a 401 error to reset the state machine, but is not, although it still seems to work. The biggest problem is our samples test all the authentication variations for virtual and normal pages, but not for template pages or POST pages, so that all had to be added first. I always test server fixes on my public servers for a day or two, so the changes won't be in SVN until later in the week. Angus

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.

I understand that you have concerns regarding the reliability of .NET for projects with long investment horizons. From my experience, it is important to note that support for any given version of .NET typically ends within approximately three years. For instance, long-term support for .NET 8 is scheduled until November 10, 2026. This may not be ideal for projects that require stability over time, considering operating system compatibility and security updates. https://dotnet.microsoft.com/en-us/download/dotnet If you plan to move to production quickly, you will have approximately one year before needing to migrate to the next version. Additionally, it is worth noting that native compilation, such as converting .NET IL to native code using tools like the native AoT c++ copiler, can pose some problems you will not be able to fix like loose all meaningfull stack on a exception. This approach can be problematic given how many NuGet packages and elements of the .NET technology stack rely heavily on reflection. Currently, no UI framework supports Ahead-of-Time (AoT) compilation, and most complex code does not function cross-platform. Moreover, utilizing third-party code can be beneficial, but it often requires significant effort to maintain, and performing risk analysis on such code can be challenging. Additionally, ensuring service level agreements (SLA) when the implementation correctness of the code is uncertain can be difficult. Based on my personal experience managing 22 NuGet packages with over 17 million downloads, maintaining them feels like a full-time job. As a result, we are currently transitioning from .NET to Delphi and creating wrapper classes to interface with the original C# code while ensuring that nothing breaks for my users during the process. If you need more convincing have a look at the security updates, I know as I reported several of them that are still not resolved. You can check out the .NET 8.0 Downloads page. https://dotnet.microsoft.com/en-us/download/dotnet/8.0

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.

Again? What was old is new again - except my jokes.

That is not correct. Technically, the path component is allowed to be empty in any url, per RFC 3986 sections 3 and 3.3: URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] hier-part = "//" authority path-abempty / path-absolute / path-rootless / path-empty path-abempty = *( "/" segment ) path-absolute = "/" [ segment-nz *( "/" segment ) ] path-noscheme = segment-nz-nc *( "/" segment ) path-rootless = segment-nz *( "/" segment ) path-empty = 0<pchar> RFC 2616 section 3.2.2 tried to restrict an HTTP url to require a non-empty absolute path if the query component is present: http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]] But, RFC 2616 section 5.1.2 does allow the path in an HTTP url to be empty: RFC 7230 sections 2.7.1 and 2.7.2 loosen the restriction to allow the path in HTTP and HTTPS urls to be empty: http-URI = "http:" "//" authority path-abempty [ "?" query ] [ "#" fragment ] https-URI = "https:" "//" authority path-abempty [ "?" query ] [ "#" fragment ] Why would you an inefficient "Pos" check instead of using something like StartsText() instead? Or simply: "if (FPath = '') or (FPath[1] <> '/')" ?

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.

Finally got some time to get back to my project and completed the goal. Thanks for the hints @Remy Lebeau. Here are the results if anyone needs the hack without modifying TSSLWSocketServer class: procedure TMainForm.SSLServerClientCreate(Sender: TObject; Client: TWSocketClient); var mConn: TClient; begin mConn := Client as TClient; mConn.OnDataAvailable := SSLServerDataAvailable; mConn.mTest := False; end; procedure TMainForm.SSLServerClientConnect(Sender: TObject; Client: TWSocketClient; Error: Word); var mConn: TClient; begin mConn := Client as TClient; mConn.SSLEnable := False; end; procedure TMainForm.SSLServerDataAvailable(Sender: TObject; ErrCode: Word); var mConn: TClient; mPeek: TBytes; mData: String; begin mConn := Sender as TClient; if not mConn.mTest then begin // first read SetLength(mPeek, 2); mConn.PeekData(mPeek, 2); mConn.mTest := True; if (mPeek[0] = 22) and (mPeek[1] = 3) then begin // client hello SetLength(mPeek, 0); mConn.SSLEnable := True; mConn.SSLContext := SSLContext; mConn.AcceptSSLHandshake; Exit; end; SetLength(mPeek, 0); end; mData := mConn.ReceiveStr; end; The only thing I'm worried about is memory leak due to not reading connected socket after data available call. At some point I had experience of that issue in another project. Regards.