Leaderboard

I'd like to advertise the Sempare Template Engine for Delphi. The Sempare Template Engine for Delphi allows for flexible text manipulation. It can be used for generating email, html, source code, xml, configuration, etc. It is available on github via https://github.com/sempare/sempare-delphi-template-engine It is also available via Delphinus (https://github.com/Memnarch/Delphinus) Simply add the 'src' directory to the search path to get started. Sample usage: program Example; uses Sempare.Template; type TInformation = record name: string; favourite_sport : string; end; begin var tpl := Template.parse('My name is <% name %>. My favourite sport is <% favourite_sport %>.'); var information : TInformation; information.name := 'conrad'; information.favourite_sport := 'ultimate'; writeln(Template.eval(tpl, information)); end. Features include: statements if, elif, else statements for and while statements include statement with statement function/method calls expressions simple expression evaluation (logical, numerical and string) variable definition functions and methods calls dereference records, classes, arrays, JSON objects, TDataSet descendants and dynamic arrays ternary operator safety max run-time protection customisation custom script token replacement add custom functions strip recurring spaces and new lines lazy template resolution parse time evaluation of expressions/statements allow use of custom encoding (UTF-8 with BOM, UTF-8 without BOM, ASCII, etc) extensible RTTI interface to easily dereference classes and interfaces (current customisations for ITemplateVariables, TDictionary, TJsonObject) There are numerous unit tests that can be reviewed as to how to use the various features. Happy for all to play with it. Released under GPL and Commercial License. Any feedback welcome.

FinalBuilder is a fully featured automated build tool, which supports Delphi 3 to 10.4, along with C++Builder 4 or later. FinalBuilder makes it simple to automate your entire build process, from compiling your Delphi projects to compiling and uploading installers, creating ISO's. There are over 600 built in actions, with support for Git, Mercurial, Perforce, Subversion, TFS and many other version control systems. Unlike xml or batch file based systems, with FinalBuilder you can easily debug your build process, with breakpoints, step over, step into etc. Of course FinalBuilder also integrates with Continua CI - our continuous integration server product, and with other CI servers such as Jenkins. Thousands of Software Developers rely on FinalBuilder to automate the build, test and release process. If you are not using FinalBuilder to automate your builds, you are missing out. Download a fully functional 30 day trial version today.

We are delighted to announce the Release of Continua CI 1.9.2. We have added the following new features: Export and Import: You can now export one or more configurations to a file and import them back from the file into Continua CI. Requeuing Stages: Requeue a failing stage without restarting the build. Multiple Daily Cleanup Rules: Each type of build by-product can now have a different shelf life. https://www.finalbuilder.com/resources/blogs/introducing-the-release-of-continua-ci-version-192 Continua CI is a low cost, easy to use Continuous Integration Server which includes first class support for Delphi (using FinalBuilder or MSBuild) and version control integration with Git, Mercurial, Subversion and more. https://www.finalbuilder.com/resources/blogs/building-delphi-projects-with-continua-ci

@David Heffernan , come out of @Stefan Glienke body! Now both Delphi reference guys have enabled their internal Technical English Compiler (tm) in paranoid mode! 😄

Can you be precise about the types here. At the moment all we know is the name of the variables.

Binary compatible, in that they have the same memory layout, yes. But you can't pass a TBytes to a 'var TIdBytes' function parameter, and vice versa, unless you use a type-cast, eg: type PIdBytes = ^TIdBytes; var Bytes: TBytes; SetLength(Bytes, 6 + Buffersize); CopyTIdString('Audio1', PIdBytes(@Bytes)^, 0); CopyTIdBytes(RawToBytes(Buffer^, Buffersize), 0, PIdBytes(@Bytes)^, 6, Buffersize); Or maybe just: var Bytes: TBytes; SetLength(Bytes, 6 + Buffersize); CopyTIdString('Audio1', TIdBytes(Bytes), 0); CopyTIdBytes(RawToBytes(Buffer^, Buffersize), 0, TIdBytes(Bytes), 6, Buffersize);

CopyTIdBytes() is just a Move() from one TIdBytes to another, using starting source/target indexes and a byte length: procedure CopyTIdBytes(const ASource: TIdBytes; const ASourceIndex: Integer; var VDest: TIdBytes; const ADestIndex: Integer; const ALength: Integer); {$IFDEF USE_INLINE}inline;{$ENDIF} begin {$IFDEF DOTNET} System.array.Copy(ASource, ASourceIndex, VDest, ADestIndex, ALength); {$ELSE} //if these asserts fail, then it indicates an attempted buffer overrun. Assert(ASourceIndex >= 0); Assert((ASourceIndex+ALength) <= Length(ASource)); Move(ASource[ASourceIndex], VDest[ADestIndex], ALength); {$ENDIF} end; CopyTIdString(), on the other hand, is a little more involved, as it first has to convert the input String to bytes in a specified encoding, and then it moves those bytes into the target TIdBytes where specified: procedure CopyTIdString(const ASource: String; var VDest: TIdBytes; const ADestIndex: Integer; const ALength: Integer = -1; ADestEncoding: IIdTextEncoding = nil {$IFDEF STRING_IS_ANSI}; ASrcEncoding: IIdTextEncoding = nil{$ENDIF} ); overload; {$IFDEF USE_INLINE}inline;{$ENDIF} begin CopyTIdString(ASource, 1, VDest, ADestIndex, ALength, ADestEncoding {$IFDEF STRING_IS_ANSI}, ASrcEncoding{$ENDIF} ); end; procedure CopyTIdString(const ASource: String; const ASourceIndex: Integer; var VDest: TIdBytes; const ADestIndex: Integer; const ALength: Integer = -1; ADestEncoding: IIdTextEncoding = nil {$IFDEF STRING_IS_ANSI}; ASrcEncoding: IIdTextEncoding = nil{$ENDIF} ); overload; {$IFDEF USE_INLINE}inline;{$ENDIF} var LLength: Integer; {$IFDEF STRING_IS_ANSI} LTmp: TIdWideChars; {$ENDIF} begin {$IFDEF STRING_IS_ANSI} LTmp := nil; // keep the compiler happy {$ENDIF} LLength := IndyLength(ASource, ALength, ASourceIndex); if LLength > 0 then begin EnsureEncoding(ADestEncoding); {$IFDEF STRING_IS_UNICODE} ADestEncoding.GetBytes(ASource, ASourceIndex, LLength, VDest, ADestIndex); {$ELSE} EnsureEncoding(ASrcEncoding, encOSDefault); LTmp := ASrcEncoding.GetChars(RawToBytes(ASource[ASourceIndex], LLength)); // convert to Unicode ADestEncoding.GetBytes(LTmp, 0, Length(LTmp), VDest, ADestIndex); {$ENDIF} end; end; So, given your example, the simplest translation to TBytes would look like this: var Bytes: TBytes; SetLength(Bytes, 6 + Buffersize); TEncoding.Default.GetBytes('Audio1', 1, 6, Bytes, 0); Move(Buffer^, Bytes[6], Buffersize);

TEventHandler<T> ? TObservable<T> ? Just my 2 cents, never used them, but it's a good base to start the conversation.

There are several factors - RTTI is one of them, another is generics, in combination they can be quite terrible. Example: A class is using a TList<something> as a field - TList<T> has RTTI enabled which causes all code for that TList<something> to reside inside the binary even though calls to Add, Delete and alike are inlined and go directly to those non generic TListHelper methods. Now multiply that with all lists and dictionaries in RTL/VCL and your code and you have the issue. Having said that - this is just one case which I was working on as author of a library that makes extensive use of generics and I don't want to be a big contributor to that issue. Putting {$WEAKLINKRTTI ON} into the project file can reduce the bloat a bit because this enables the linker to remove all methods that are not being used. An empty FMX application on Win32 is 8.5MB in release config and contains way over 2MB just from System.Generics.*. With that option you can at least reduce this to 7.4MB (numbers from Delphi 10.1). How that option affects your code depends on your code. During the development of Spring4D I rigorously have used {$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])}{$ENDIF} in a lot of units to at least reduce any bloat from my code but without recompiling the RTL/VCL/FMX you cannot do that for the Delphi code.

Yep, that's the main reason we added the feature for, we find uploading to chocolatey fails occasionally - it's so nice to be able to just try again - we've been dogfooding this feature for a while here and I've had to use it a few times now. Yes, you can certainly edit the exported file. It will be checked for validity when imported - that happens before the change is committed (the import is done in a transaction), so if there are errors in the file nothing bad should happen (this is why this feature took so long to develop!).

I looked at the fix and setting the percent to 100% will not fix the problem. Messing with the percentage in Regedit, it appears the magic value is 93%. At 95%, I get the same window as shown in my original report, plus the toolbar across the top, but nothing else. At 93%, the toolbar shows, as well as the splitter appearing at the top of the window. At that point, I can use the splitter to resize the sections and see everything again.

Cristian was the first to spot the blog article: https://blogs.embarcadero.com/delphi-compiler-and-lsp-patch-for-rad-studio-10-4-1/

Presumably it's because of your RTTI settings, which by default allow public methods to be called from RTTI, but not private.

const STX=#$02; isn't the same as const STX='#$02';