Leaderboard

I've found it, and used, in official page of 7Zip: https://7-zip.org/sdk.html https://www.birtles.org.uk/programming/ It is old, true, but I use it to compress and send data over TCP server/client and works fine for my projects. There is also a, I guess 9.2 version, at: https://github.com/TetzkatLipHoka/LZMA/tree/main

For .\assets\internal\ on Android, this is incorrect. If a file exists, it will not be overwritten, regardless of whether or not the file is newer.

It turns out that the workaround for the second issue is quite simple: procedure TCustomSynEdit.ReadState(Reader: TReader); // If the component is inherited from another form, ReadState will be called // more than once. We only clear the collections if it is the first call // i.e. when reading the base form. begin if not FStateRead then begin FScrollbarAnnotations.Clear; FStateRead := True; end; inherited ReadState(Reader); end; Thanks to @Uwe Raabe for giving me the idea.

Indeed! Probably no one at Embarcadero is going to change a that old behavior, because no one can say for sure what the consequences would be for existing code. Asking here only reaches a small part of the existing Delphi developers, from which some may not even know whether their code relies on the current implementation or not. I second Anders view of better using a workaround. Besides his suggestion, you can also write a sentinel value as the only collection item, which is removed after reading. Candidates for interception can be the ReadState/WriteState methods of the component. In WriteState add the sentinel when the collection is empty before calling inherited and in ReadState remove the sentinel if found after calling inherited.

Keep it simple - create a class helper for TMemo and add an Assign method and just set the props you need. This will be quicker and easier than messing with RTTI (which can be a bit of a rabbit hole with some property types).

You mentioned it later, though:

I wouldn't bother. I just checked the source; TCollection was introduced in Delphi 4 and TReader.ReadCollection hasn't been changed since then. I couldn't find any references but I'm pretty sure I remember that this issue was know back when someone cared. I also can't really see what they could do without breaking backward compatibility. Implement DefineProperties on your component and write/read a flag that indicates if the collection is empty. Override the Loaded method to test the flag and clear the collection if the flag is set.

As been said elsewhere, most of us have a stable IDE environment. As long as the Delphi IDE executes code that is written by a third-party, there will be a chance that a third-party component or expert is the cause of instability. And in some cases, the user is the cause. I've written components that were buggy and caused instability until I took the time to find the defect and correct it.

The only way to avoid buffer overflow problems is to write code that doesn't overflow buffers. That won't change with a 64-bit IDE.

I wish the IDE would work! - I wish word searches would not crash the IDE and cause my unsaved work to be lost. - I wish the IDE would not freeze for no apparent reason and cause my work to be lost - I wish Code Insight would finally work - I wish the IDE would not go out of memory after using it for a while To sum up: I want a stable IDE that doesn't waste my time and finally fixes the bugs that have been around for years! am I asking too much?

Without to use 7z.dll there is a pure pascal implementation that I've used and works fine: LZMA.442b.7z

7-Zip with using the *.7z format is able to produce compressed files larger than 2GB and can be integrated into Delphi app as well, by using the 7z.dll. I think 7-Zip with using the *.zip format also stops at 2GB, but I haven't checked this with recent versions.

Well, if you come to Pasadena, you can visit and see it running beautifully 😀 We have a bank of 5 servers. Each one is 24 cores and 200GB of ram. They each run about 75 headless windows machines each in a citrix environment. We have 4000 visual tests that are run multiple times per day and it takes about 1.5 hours to complete a full run on that bank. The key is that we wrote our own GUI automation over the years. All we do is send keystrokes and mouseclicks to the UI. However, there are several caveats that we have developed over the years to make it work. 1. the test case NEVER contains screen coordinates. We have methods like ClickOnMenu(aMenu:TMenu,'File|Open'). That method queries the TMenu and finds coordinates of the 'file' menu item, clicks on it and finds coordinates of the open menu item, then clicks on it. Similar is ClickOnControl(form:TForm;control:TControl). The testing system finds the open form, finds the control. finds the coordindates and then sends a mouse click in the middle of the control. There are other variants if you dont exactly want to click in the middle. So in the test is says ClickOnControl(form1, form1.button1). That way, if the developer changes the form, i.e. moves button1 around, then the test is fine. If they delete button1, the test stops compiling. That being said, we wrote tons of these types of methods that are specific for the controls we use, to accommodate their oddities, like virtual string tree etc. It did not happen overnight. 2. We have a small delay after every input except certain cases. This small delay is generally enough. We also have hooked into the idle processing of the program so after sending a mouseclick / keyboard press it waits for the onIdle so the program is not processing more messages. There are a few more tricks as well. However, the upshot is that we rarely have a problem with timing any longer. For really variable processes, we have our GUI automation thread wait on a TEvent in the program and the program triggers the TEvent when the process is done so that the test knows to continue. But that is rare. Not so similar from an end user, that just sits there waiting for the screen to refresh. So, the upshot is that it was a lot of work, and likely only worth it if you are going to maintain the same program for a long time. But it can be done and today, new developers in our company have no idea the hard work that went into it and they just write scripts in a fairly high level way and the infrastructure does the rest. The test cases find the problem they are designed to test, about 50% of the time. The rest of the failures are because of bugs that are involved in things the test was doing to get to the point where it was trying to test. The other upshot is that we very, very rarely have regressions. The vast, vast majority of bugs that make it to production are in new features that have not (in hindsight) been sufficiently testing.