A.M. Hoornweg

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

If you want to store either integers or objects into your grid, just declare a simple class that contains an integer. That way you can consistently store objects in the grid and treat everything alike. And you can simply test if the object is an integer or something else: "(if Obj IS tInteger then ...)" Type tInteger=Class protected fValue:Integer; public Constructor Create(const aValue:Integer); Property Value: Integer read fValue write fValue; end; Constructor tInteger.Value (const aValue:integer); begin fValue:=aValue; end;

If the problem is just that the cdecl function needs to be in an external module, maybe it's possible to work around that. It may sound counter-intuitive, but it's perfectly possible to export a function contained in an *.exe project and then call it from a DLL loaded by the executable. I see no reason why the executable shouldn't be allowed to import a function that it exports itself. Program test; uses windows; function somefunction:integer; cdecl; export; begin result:=1; outputdebugstring(pchar('Hello World')); end; Exports somefunction; end;

One advantage is that it's way less work server-side. If anything goes wrong, you need not worry too much about how to inform the client because that information is already contained in the exception that was thrown by whatever action failed. The stack is unrolled automatically just like in regular Delphi apps and the exception information is automatically propagated to the client. Client-side, a remote procedure call is used like any other Delphi call. In the case of an error, you use structured exception handling and use the exception type as a criterium for how the client should proceed. try server.executequery(query) except on e:exception do begin if e is eCommsError then //did the internet connection fail? If so, client should try again later. ... else if e is eDatabaseError then showmessage(format('The server really didn''t like this query, this is wrong with it: (%s) "%s"',[e.classname, e.message])) else ... end; end;

The disadvantage of that is that it doesn't tell you in detail what went wrong on the server. It is also tedious, the server needs to CATCH exceptions and convert them into something meaningful (an error code?) to pass back to the client, hopefully yielding sufficient information. If the framework itself is designed in such a way that it can pass exceptions back from server to client, the client will re-raise the same exception type (eOverflow, eConvertError, eInOutError, eListError...) with (hopefully) the server's error address in the error message so you can easily find the root cause. It also simplifies server-side development enormously; if something goes wrong on the server, it can simply raise an exception and it will be passed back to the client.

I use Remobjects Remoting SDK as a middleware and that is perfectly capable of passing an exception that happens in a remote procedure call back to the client without hanging. The exception is then raised in the client.

Thank you very much!