Leaderboard

tbh not having IDEFixPack being available is good in the long run - with the existence of it nobody (or very few) actually cared to report issues and put some pressure on Embarcadero to address these things. Now that there is no solution available the pressure on Embarcadero has raised and I can confirm that they are working on it - will they suddenly implement all fixes and optimizations from Andreas? No, but better they do slowly than relying on the third party no matter how incredible.

https://larsfosdal.blog/2020/10/16/post-a-message-to-teams-from-delphi-using-webhooks/

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.

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.

That applies to SHFileOperation(), but not to IFileOperation. You would have to either: - call CopyItem() for each desired source file individually. - call CopyItems() for the whole list of desired files.

Thanks, Mahdi! Fixed the URL.

If your data takes a little time to load, you could delegate the loading to a background task which then again triggers another repaint on completion. That would eliminate any UI stutter due to load times.

We mostly store the ordinal value of the enumerated type variable to an int in the database. Yes, it is fragile with regards to people changing the enumeration - but we have guidelines and unit tests to avoid that. type TPSDExpeditionType = (etRetailer,etWholesaler,etRetailerDairy,etWholesalerDairy); // Do not reorder or remove - add at end TLocation = class ExpeditionType: TPSDExpeditionType; We use RTTI to export the enums to a view in the database so that we can do logic in the SQL code using the same identifiers as we use in Delphi. T-SQL doesn't do constants per se, but selecting from a flat static view is optimized by the query engine and is extremely low cost. CREATE TABLE [dbo].[t_locations]( [Id] [int] IDENTITY(1,1) NOT NULL, [ExpeditionType] [int] NOT NULL -- CREATE VIEW [dbo].[v_psd_constants] AS SELECT 0 AS etRetailer, 1 AS etWholesaler, 2 AS etRetailerDairy, 3 AS etWholesalerDairy -- SELECT * FROM v_Locations loc WHERE loc.ExpeditionType = (SELECT TOP(1) etRetailerDairy FROM v_psd_constants) This means we can handle renames and additions - but not removals or reordering. From an SQL performance perspective, this runs circles around using strings.

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

It is why textual exchange and API formats were invented. XML, JSON, YAML. It's why Microsoft replaced the binary format DOC with DOCX. Do not pass an enumeration member by its numeric value, use its name.

Not explicitly: