A.M. Hoornweg

In Delphi 12 I get "F2084 Internal Error L902" all the time if I have code inlining control set to ON and it disappears when I set it to OFF. I haven't tested D13 yet.

He just told me it was because brcc32 doesn't support 256x256 png-format icons and because cgrc was simply the next option that Finalbuilder offered in the action "Embarcadero Resource Compiler". "Resinator" isn't an option yet in Finalbuilder, I hope @Vincent Parrett reads this post... it's one of the three pre-defined

About UIAutomationCore.dll, ChatGPT says the following: "Windows XP and earlier versions do not include this file by default. They relied mainly on MSAA. However, UIAutomation could be installed on Windows XP by installing the .NET Framework 3.0/3.5 (which backported parts of the API and the DLL)".

Hi Remy, the current SDK is installed, or course, and we even manually appended the directory where rc.exe is located to the system path. If I type "rc.exe" in the command line, it is found and executes without problems. The problem is that a Finalbuilder script of one of my coworkers calls Embarcadero's cgrc.exe resource compiler, I'm not certain why he uses that. That executable seems to depend on rc.exe being in the same directory - it's not sufficient if rc.exe can be found through the PATH.

Yes! (prior versions don't support Delphi 13). The error is output by Embarcadero's cgrc.exe, not by FB.

I think I've found a bug: We have a Finalbuilder 8 compilation script that fails with Delphi 13 (not 12) because the resource compiler cgrc.exe throws an error message "unable to execute rc.exe". This file is indeed missing in the directory "...Embarcadero\Studio\37.0\bin". After manually copying this file from the Windows SDK, the Finalbuilder script works.

When large numbers of fields are accessed by name, the legibility of a CASE is much better than if/then. I used this technique recently to evaluate a recordset of +/- 150 fields where I had to go by name rather than ordinal number (the routine had to be able to handle multiple versions of the database - the sql query had to be rather a-specific).

A case statement for strings can be created using generics. Not the fastest (it does a linear probe) but quite practical sometimes. Var s:String; begin s:='three'; CASE tarray.Indexof<string> (tarray<string>.create( 'zero', 'one', 'two', 'three', 'four'), s) of 0:writeln('zero'); 1:writeln('one'); 2:writeln('two'); 3:writeln('three'); 4:writeln('four'); end; end;

May I suggest "fluent interfaces" as an alternative to nested calls. Instead of using a record like a dumb data store that is only manipulated from the outside, you can put the methods that fiddle with the record's contents directly into the record itself and thus keep the code and the data closely together. Also, this enables one to use a so-called "fluent interface". Example: This is an example of a record that contains just one integer member, "data". In real life, you can make the record as complex as you want. type pMyrecord=^tMyRecord; tMyRecord=Record data:integer; Function Reset:pMyrecord; Function Add (x:integer):pMyrecord; Function Multiply (x:integer):pMyrecord; Function Divide (x:integer):pMyrecord; End; As you can see, all the methods in this record return a pointer, which simply points to the record itself. That is the "secret sauce" one needs to implement fluent interfaces. function tMyRecord.Add(x: integer): pMyrecord; begin data:=data+x; result:=@self; end; function tMyRecord.Divide(x: integer): pMyrecord; begin data:=data div x; result:=@self; end; function tMyRecord.Multiply(x: integer): pMyrecord; begin data:=data*x; result:=@self; end; function tMyRecord.Reset: pMyrecord; begin data:=0; result:=@self; end; Now the cool thing: All these methods can be concatenated and will be processed left-to-right. This produces very legible and compact code: procedure Test; var x:tmyrecord; begin x.reset.add(12).multiply(4).divide(2); end; (edit) Note that I didn't do a single heap allocation here, never manually passed the record as a parameter and never did a nested call. The data lives on the stack. If the record contains managed objects such as strings, these are disposed of automatically.

It would be nice if the IDE would let me use CTRL plus the mouse wheel to change the font size. But what I crave the most is to have a way to have source code and remarks side by side in different text columns. On modern computer screens, we have tons of horizontal space and far too little vertical space (of which 50% is whitespace). Having lines of code interspersed with remarks unfortunately has the side effect that less source code is visible on the screen. It would be sooo lovely to have remarks and explanations *alongside* the source code instead of *inside* the source code. The code would be nice and tight and the remarks can finally become eloquent without getting into each other's way.

There is a relatively simple way to do it. SetDllDirectoryA() also works for child processes spawned by the program. OP (Mark) could write a trivial loader process that first calls SetDLLDirectoryA() and subsequently executes the "real" program.

The bitmap is created like this, the 32-bits is just for alignment (speed) reasons: ResultBitmap := tbitmap.Create; ResultBitmap.pixelformat := pf32bit; ResultBitmap.Alphaformat := TAlphaFormat.afIgnored; and function TSkBitmapHelper.ToSkImage (found in Unit vcl.skia) explicitly handles that 32bit/afIgnored case, so there's probably a bug there somewhere: if PixelFormat = TPixelFormat.pf32bit then begin case AlphaFormat of TAlphaFormat.afIgnored: LAlphaType := TSkAlphaType.Opaque; TAlphaFormat.afDefined: LAlphaType := TSkAlphaType.Unpremul; TAlphaFormat.afPremultiplied: LAlphaType := TSkAlphaType.Premul; else LAlphaType := TSkAlphaType.Unknown; end; ...... Saving the tBitmap to a stream and then creating the tSkImage from that stream works, but this still seems a bug to me.

I have a workaround that works: procedure SaveAsWebP(aBitmap: tbitmap; aOutputfilename: string; Compressionfactor: integer; out MimeContentType: string); var lStream: tMemorystream; skimage: iSkImage; begin lStream := tMemorystream.Create; try aBitmap.SaveToStream(lStream); lStream.Position := 0; skimage := tskimage.MakeFromEncodedStream(lStream); skimage.encodetofile(aOutputfilename, tskEncodedImageFormat.WebP, Compressionfactor); MimeContentType := 'image/webp'; finally lStream.Free; end; end; So it appears that it is really the following code that is broken: var skimage:=aBitmap.ToSKImage;

Hello all, I have a 32-bit Windows application (it is an Intraweb based ISAPI dll) and I try to write images in losslessly compressed webp format. The bitmap that I want to convert to webp is a 32-bit tBitmap containing some 2-D graphics. My problem: The generated output image is totally broken when I use Delphi 12's SKIA routines for the conversion. Graphics programs render it only partially, then give up. This is the code that I wrote; The compression factor that I pass is 100. Did I do anything wrong? ... uses system.skia, vcl.skia; procedure SaveAsWebP(aBitmap: tbitmap; aOutputfilename: string; Compressionfactor: integer;Out MimeContentType:String); begin var skimage:=aBitmap.ToSKImage; skimage.encodetofile(aOutputfilename, tskEncodedImageFormat.WebP, compressionfactor); MimeContentType:='image/webp'; end ; broken_webpfile.webp

Smart Setup is a unified tool for installing and building Delphi packages, whether they come from TMS or elsewhere. See: https://www.tmssoftware.com/site/blog.asp?post=1360