Leaderboard

I have been working on my stripe library recently as I’ve integrated it into our own software. I can’t remember removing it from GitHub, weird... I’ll re-upload it to GitHub later today. It’s really easy to use so might be of use to you.

I would not put the behavior change regarding of $R+ setting. Your library should better be consistent and never need a re-compilation if you need to change e.g. from DEBUG to RELEASE mode. My idea would be to raise an exception in case of out of bounds error - just like TStringList/TList. It is what most users expect, and will be confident and pleased with. In mORMot, the trick is that I also give direct access (as a field, not as a getter - even inlined) to the raw pointer of array storage. So the user can by-pass the range check if needed, e.g. by using a local pointer variable, and proper pointer arithmetic. I document the property as low-level and raw access to the values, to be used at your own risk. Then advanced users, and other parts of your own library which is safely written and tested, could be able to bypass the range check, by accessing directly the pointer values.

There, I've fixed it for you. 😉

In the process of development on the level of the subject area you want to see the problem at the moment of its occurrence. Memory destruction from outside the array may be detected too late. In complicated cases, it may take several hours of your life to find such an error. Do you need to optimize your program? And if necessary, for the program code more than adhere to the principle of Pareto 80/20 (here you probably need to amplify by 10 times) 98% of the time takes 2% of the code. You need to optimize this 2%, and even if it is critical for you. Even when I was programming microprocessors where the average execution time of one instruction was 3-10 µs LSI-11 and only 8-16k memory I was not saving on safety. I programmed in Pascal with all the checks included. And yet my program code was more functional and faster than the programs of my colleagues who programmed on Assembler. I usually had a better program due to better Pascal code control. When I was still young and green, immediately after graduating from the Radio Engineering Department of the university, with no specialized training in programming, I tried to detect a repeating code and to extract it to a parameterized subprogram. I had my favorite book, "Algorithms and Data Structures", by Niklaus Wirth, Mir Publishing House, 1985 which is always next to me, although it already has a double glued cover and some pages are already scattered from use. If my developed algorithm will work correctly for data in some value domain, I will add a check of this condition. Unlike some of my colleagues who honor my uniform and think that the appearance of an error message is a bad tone. Some of them do not show any errors or even close the error output. I know what the mistake is and exactly where it happened. I will also try to react quickly and preferably close the problem by the evening and post an extraordinary release. As a result, I don't have problems with my programs' support for a long time already. As a result of this approach, I am mainly engaged in extending the functionality of my programs, rather than closing holes in them. Rarely is 100% code coverage by tests in real projects. And even 100% code coverage by tests does not guarantee absence of errors in the code. If the logic is complex, there is no guarantee that every variant of a passing branch has been tested. A test can detect an error, but tests do not guarantee that there are no errors in code. In principle, an effectively implemented iterator could provide a fast and safety iteration of array elements. For me it would be best if the iterator returned the element address. it is possible to check the fields of the element and change something in it if necessary. The fastest way to search is with sentinel, when we only compare values and do not check the element index. To do this we add sentinel to the list at the end of the list and set the key value in sentinel. p := List.First; List.Sentinel.Key := x; while p.key <> x do Inc(p, Itemsize); if p <> List.Sentinel then ... At the end of the list we check which element we have reached if it means that the sentinel is not looking for it. The structures with sentinel are not only a list. The current version of the Delphi iterator is not quite perfect, it requires the call of two methods. It would be better if the iterator or list executed the code until it said "I did what I wanted". DoSomething: TEnumFunc; list.Enumerate(DoSomething);

Thanks to the overloads for AddBody that is not a big challenge: { as Json string } Request.AddBody(TJSON.ObjectToJsonString(aMsg, [joIgnoreEmptyStrings, joIgnoreEmptyArrays, joDateIsUTC, joDateFormatISO8601])); { or as TJsonObject } Request.AddBody(TJSON.ObjectToJsonObject(aMsg, [joIgnoreEmptyStrings, joIgnoreEmptyArrays, joDateIsUTC, joDateFormatISO8601]), ooREST);

Nice! Any reason why you didn't make use of TRestClient instead of the Indy component? That would not only avoid the dependence on the OpenSSL libraries, but make it also work on other target platforms. unit O365WebHook; // Lars Fosdal, 2020 OCT 16 // Simple example without error handling interface uses System.Classes, System.SysUtils, REST.Json, REST.Client, REST.Types; type TWebHookMessage = class end; /// <summary> See https://docs.microsoft.com/en-us/microsoftteams/platform/webhooks-and-connectors/how-to/connectors-using /// for examples of how to structure the json for creating advanced formats</summary> TSimpleText = class(TWebHookMessage) private FText: String; public property Text: String read FText write FText; constructor Create(const aText: string); end; type TWebHook = class private FClient: TRESTClient; FRequest: TCustomRESTRequest; FURL: string; protected property Client: TRESTClient read FClient; property Request: TCustomRESTRequest read FRequest; public constructor Create(const aURL: string = ''); destructor Destroy; override; function PostMessage(const aMsg: TWebhookMessage; aOwnsMsg: Boolean = False): Boolean; property URL: string read FURL write FURL; end; implementation { TWebHook } constructor TWebHook.Create(const aURL: string); begin inherited Create; FURL := aURL; FClient := TRESTClient.Create(nil); FRequest := TCustomRESTRequest.Create(nil); FRequest.Client := FClient; end; destructor TWebHook.Destroy; begin FRequest.Free; FClient.Free; inherited; end; function TWebHook.PostMessage(const aMsg: TWebhookMessage; aOwnsMsg: Boolean = False): Boolean; begin try Request.Client.BaseURL := URL; Request.Method := rmPOST; Request.AddBody(aMsg); Request.Execute; Result := Request.Response.Status.Success; finally if aOwnsMsg then aMsg.Free; end; end; { TSimpleText } constructor TSimpleText.Create(const aText: string); begin inherited Create; FText := aText; end; end.

That feeling when guys are proudly announcing updating a software that you've never heard about.

OverbyteIcsWSocket: ~25500 lines 😄 😞 OverbyteIcsWSocket is not a main unit. And it includes 18 other units (not counting the standard Delphi units). The first code line is line 4800. There are THOUSANDS of comment lines. The rest is what is really necessary to have a significant socket class which serves as the base for higher protocols. The first version of OverbyteIcsWSocket is dated April 1996. Probably today, 24 years later, I would not write it the same way. I gained some experience during all those years after all.

I cleaned up one project (40K lines of code, ca. 80 units, depends on 21 projects). I cleared the 'Unit Scope Names' from the Project Options to be empty. I had to fix many compile errors (in 47 units) by using the full scoped name (e.g: System.SysUtils, instead of just SysUtils). Delphi Rio 10.3.3 (WITH IDEFixPack) Before the changes this project compiled in ca. 8 seconds After the changes it improved slightly to: ca. 7.7 seconds Delphi 10.4.1 Before the changes: ca. 11.5 seconds. After the changes: 8.7 seconds. Delphi Rio 10.3.3 (WITHOUT IDEFixPack) Before the changes: 18.1 seconds After the changes: 14.5 seconds Ideally you should always use the fully scoped names. I would have never had thought that this would have such an impact on compile time...

What is on the Cards exactly? When a UI has to display a lot of elements that start hindering performance, that is when I start considering either redesigning the UI to use different higher-performant controls, or switching to owner-drawing as much as possible to reduce resource usage.

Are there anyout out there that knows why it has not popped up a version of DDevExtensions for Delphi 10.4.1 ? Link: Andreas Hausladen DDevExtensions I use it most for having "Explicit" removed from the DFM-files.

I know I am late to the party, but you might try the attached package for Delphi 10.4.1. It uses the hooking code from Andreas Hausladen's VclFixPack v1.4 to patch the TControl.DefineProperties method to a modified code, which does not write those Explicit* properties to the DFM file. Unpack the zip archive, open DControlsFix.dpk in Delphi 10.4.1, compile & install. There is nothing to customize. If this package is installed, the patch is active. If you like to get the default behaviour back, just uninstall the package. Use at your own risk 😉 DControlsFix.zip