Lars Fosdal

I logged in and was not asked to do deal with a captcha.

Googled a bit: https://stackoverflow.com/questions/42096402/eipabstracterror-while-creating-delphi-trestclient

Is https://limelect.com the URL you tried? The URL you use, must be the webhook URL you have configured in your Teams channel. In your MS Teams team, select the desired channel, and click on Connectors from the ••• menu. In that channel you must define an Incoming Webhook.

@limelect I removed the other post. I don't have 10.2 so I can't check if I see the same error. Did you get this error in a bare bone test project, or in a bigger project?

Make sure that any unit or resource path in the project has a relative path and/or use internal environment variable overrides. That enables you to safely copy the project folder to a new folder. If you are going to copy/paste a form from an old project to a new project - why rename the form at all? Can't the form be reused or be made to be reusable?

The interesting part is that there is still room for improvement - and if it is a significant one - it will have huge implications.

Spotted one challenge with TRESTClient. No easy way to override the flags to ObjectToJsonString.

@Anders Melander - We use Continua CI and FinalBuilder, and Continua has Teams support built in. My PS scripts also posts to Teams, but I use the PSTeams module. I still need to master how do PS Secure Vault secret keys across multiple users to avoid having the URLs in the PS script, though. Love your example of how simple it is to do Json in PowerShell! @Uwe Raabe Ignorance, I guess I've never used TRESTClient and I already was using Indy for JsonRPC. Thanks for sharing the modified version! I added it to the article. How TLS capable is the TRESTClient?

Thanks, Mahdi! Fixed the URL.

In most cases, yes 🙂

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.

Nice! 🙂

"Do you even SQL?"

You store Enums as strings in the database?

Well, it is all about littering the code with comments like "do not remove or reorder elements" 😛

Which causes problems for RTTI.

A pitfall with Enums is that they are so easy to change. Add another member in the middle of the list, and you have changed the ordinal value of the rest. This is fine if you only use the enumerated reference inside your application, but if you use the ordinal - f.x. when saving to/retrieving from a database, or when transmitting to another system - you get into trouble.

Changing NA to Nada gives same result. But - adding the "unit scope" works. CommandType := ScopedEnumsWithoutT.CommandType.NA;

Dropping the T for types in Delphi doesn't quite work for scoped types. program ScopedEnumsWithoutT; {$APPTYPE CONSOLE} {$R *.res} {$ScopedEnums ON} uses System.SysUtils; type CommandType = (NA, Whatever); type TClass = class private FCommandType: CommandType; public constructor Create; property CommandType: CommandType read FCommandType write FCommandType; end; procedure Test; begin var Instance := TClass.Create; try Instance.CommandType := CommandType.Whatever; // This is fine finally Instance.Free; end; end; { TClass } constructor TClass.Create; begin CommandType := ScopedEnumsWithoutT.CommandType.NA; // When using "unit name space" - this is fine CommandType := CommandType.NA; // [dcc32 Error] : E2018 Record, object or class type required end; begin try Test; except on E: Exception do Writeln(E.ClassName, ': ', E.Message); end; end.

All my method arguments start with a - regardless of if they are const, var or out.

A minor bug in Error Insight / Compiler messages Passing an unknown class as type parameter to a method gives multiple and slightly confusing error messages that doesn't identify the actual problem. https://quality.embarcadero.com/browse/RSP-31327

https://blogs.embarcadero.com/new-getit-web-portal The portal https://getitnow.embarcadero.com/

We could, but we have our reasons for not doing so.

There are a number of libs, such as TMS, that still do not use fully qualified unit names. We removed as many aliases as possible, but could not remove them all. As for the problem being discussed - is it the same as this one: https://quality.embarcadero.com/browse/RSP-18130?filter=-2 ? Edit: We use 10.4.1 now, and although the compilation still is sluggish - we wait a lot longer for the EurekaLog linker to complete its task than we do for the actual compiling.