Leaderboard

Just to inform anyone looking for an OpenAPI client code generator, that I just made a new one, for both Delphi and FPC. It seems to be more advanced than Wagner's generator (e.g. it converts errors, enums and allOf/oneOf attributes), and is fully Open Source. https://blog.synopse.info/?post/2024/09/06/Swagger/OpenAPI-Client-Generator-for-Delphi-and-FPC Here are the top features of this OpenAPI client code generator for Delphi and FPC: Use high-level pascal records and dynamic arrays for "object" DTOs Use high-level pascal enumerations and sets for "enum" values Translate HTTP status error codes into high-level pascal Exceptions Recognize similar "properties" or "enum" to reuse the same pascal type Support of nested "$ref" for objects, parameters or types Support "allOf" attribute, with proper properties inheritance/overloading Support "oneOf" attribute, for strings or alternate record types Support of "in":"header" and "in":"cookie" parameter attributes Fallback to variant pascal type for "oneOf" or "anyOf" JSON values Each method execution is thread-safe and blocking, for safety Generated source code units are very small and easy to use, read and debug Can generate very detailed comment documentation in the unit source code Tunable engine, with plenty of generation options (e.g. about verbosity) Leverage the mORMot RTTI and JSON kernel for its internal plumbing Compatible with FPC and oldest Delphi (7-2009) Tested with several Swagger 2 and OpenAPI 3 reference content, but your input is welcome, because it is not fully compliant! Hoping you may find it interesting. The blog article has several example of the actual output of the generator, from several sources. It is the kind of information I would have wanted to see with other libraries. Use the source, Luke!

Hi All I created a Delphi implementation of UUIDv7 - RFC 9562 UUIDv7 values are time-sortable, which means you can sort them in increasing order based on when they were generated. https://github.com/VSoftTechnologies/VSoft.UUIDv7 Should work with XE2=12.x Win32/Win64 and all platforms on 11.3 or later. Usage : var guid : TGuid; begin guid := TUUIDv7Helper.CreateV7; writeln(guid.ToString); end;

Same here. I was so excited when I upgraded to 12, thinking there would finally be something amazing, but when I checked it out, bleh. I’d rather not.

Personally I see advantage in using them as simple "SmartPointers", already now in uncritical situations, avoiding any further complexity like Default(T). That should be fair enough, although I still hesitate to use them, until perhaps more positive feedback occurs. It is a pity that such a basic and useful feature cannot be used out-of-the-box, without a bad feeling. Unfortunately, it may take 2-3 update versions until the hard corners and edges have been sanded down a little.

@Kas Ob. yes, but the code has not changed in a long while AFAICT. On practical approach might be for EMBT to "officially" allow FMX.Context.XXX open-source forks. This would allow reimplementation projects to be kickstarted, and after a few iterations, there would probably be little left from the original EMBT source code anyway (at least from what I can see in the TDX11Context). The OpenGL context seems less "private", but it still has a lot of private vars in key areas. One of the first things forks would do would probably be to turn those private vars into fields, and support multiple contexts (and eventually multiple threads)

program Project1104; {$APPTYPE CONSOLE} {$R *.res} uses System.SysUtils, System.Classes, System.Types, Winapi.D3D11, FMX.Types3D, FMX.Context.DX11; type TDX11Context = class(TCustomDX11Context) private class var FResources: IInterfaceList; FVSSlot: ID3D11Buffer; FPSSlot: ID3D11Buffer; FVSSlotModified, FPSSlotModified: Boolean; FVSBuf, FPSBuf: array of Byte; FInputLayout: ID3D11InputLayout; FResourceViews: array [0..16] of ID3D11ShaderResourceView; FSampleStates: array [0..16] of ID3D11SamplerState; FBlendDesc: TD3D11_BLEND_DESC; FBlendState: ID3D11BlendState; FBlendStateModified: Boolean; FRasterizerDesc: TD3D11_RASTERIZER_DESC; FRasterizerState: ID3D11RasterizerState; FRasterizerStateModified: Boolean; FDepthStencilDesc: TD3D11_DEPTH_STENCIL_DESC; FDepthStencilState: ID3D11DepthStencilState; FDepthStencilModified: Boolean; FStencilRef: Integer; FBufferSize: TSize; end; TDX11ContextClass = class of TDX11Context; begin try RegisterContextClasses; if TContextManager.DefaultContextClass.ClassNameIs('TDX11Context') then Writeln(Length(TDX11ContextClass(TContextManager.DefaultContextClass).FVSBuf)) else Writeln('Oops!'); except on E: Exception do Writeln(E.ClassName, ': ', E.Message); end; ReadLn; end.

This seems to be fixed in the latest version, 1.3.25 build 4298.

I rely on TGUID.NewGuid to generate the random parts - under the hood it uses CoCreateGuid which uses windows cryptographic apis - which are far more random than Delphi's Random function (and faster).

Byte[7] is filled at array initialization with random values.

Already reported in 2021