pyscripter

The Windows imaging Component contains a wealth of useful features for manipulating images in different formats. Delphi partially encapsulates this functionality into the TWICImage class of Vcl.Graphics which is a TGraphics descendent. The following code resizes pf32bit bitmaps with transparency using TWICImage, at a much better quality than can be achieved with StretchDraw for example or anything else I have tried.. Uses Winapi.Wincodec, Vcl.Graphics; procedure ResizeBitmap(Bitmap: TBitmap; const NewWidth, NewHeight: integer); var Factory: IWICImagingFactory; Scaler: IWICBitmapScaler; Source : TWICImage; begin Bitmap.AlphaFormat := afDefined; Source := TWICImage.Create; try Factory := TWICImage.ImagingFactory; Source.Assign(Bitmap); Factory.CreateBitmapScaler(Scaler); Scaler.Initialize(Source.Handle, NewWidth, NewHeight, WICBitmapInterpolationModeHighQualityCubic); Source.Handle := IWICBitmap(Scaler); Bitmap.Assign(Source); Scaler := nil; Factory := nil; finally Source.Free; end; end; Some key points: Setting the AlphaFormat to alDefined is crucial for maintaining the transparency. If you do not release the ImageFactory before you destroy the TWICImage you will get access violations next time you call this procedure. (Have a look at TWICImage .Destroy).

Please note that there is a bug in Vcl.Graphics which affects the code above.

@Stefan GlienkeWould this approach work with classes derived from TFoo? Wouldn't you have to patch the VMT of derived classes?

The extended Rtti, available since Delphi XE, is great and has many uses, including serialization and exposing Delphi object to scripting languages. There have been many discussions about whether you should keep a global RttiContext or not and whether you should call TRttiContext Create and Free every time you access extended Rtti. For example this article suggests that keeping it in a global variable is a "very bad idea". However there is a huge performance penalty if you do not do that. For example in the following code Test1 runs about 100 times slower than Test2. The reason is that in Test1, hundreds of Rtti objects are created and destroyed every time you access the rtti. program Project1; {$APPTYPE CONSOLE} {$R *.res} uses System.SysUtils, System.Classes, System.Diagnostics, System.Rtti; Const Iterations = 10000; var SL : TStringList; procedure Test1Inner; begin var RttiContext := TRttiContext.Create; var RttiMethod := RttiContext.GetType(SL.ClassType).GetMethod('Clear'); RttiMethod.Invoke(SL, []); RttiContext.Free; end; Procedure Test1; begin for var I := 1 to Iterations do begin Test1Inner; end; end; Procedure Test2; begin var RttiContext := TRttiContext.Create; for var I := 1 to Iterations do begin var RttiMethod := RttiContext.GetType(SL.ClassType).GetMethod('Clear'); RttiMethod.Invoke(SL, []); end; RttiContext.Free; end; begin SL := TStringList.Create; try var SW := TStopwatch.StartNew; Test1; SW.Stop; WriteLn(SW.ElapsedMilliseconds.ToString); SW := TStopwatch.StartNew; Test2; SW.Stop; WriteLn(SW.ElapsedMilliseconds.ToString); finally SL.Free; end; ReadLn; end. There is a middle-of-the-road solution to the performance issue, once you realize that there can be many Rtti Contexts but there is just one Rtti Pool as @Stefan Glienke points out at the bottom of this Stackoverflow topic. (By the way, the bug discussed in this question was fixed in Delphi Rio). So instead of having a global RttiContext you can instead insert the following code at the bottom of one of your units. Var _RttiContext: TRttiContext; procedure _InitRttiPool; begin _RttiContext := TRttiContext.Create; _RttiContext.FindType(''); end; initialization _InitRttiPool; finalization _RttiContext.Free(); Note that _RttiContext is not used anywhere else, but this is enough to keep the rtti pool alive and prevent the performance penalty involved in creating and freeing the RttiContext. @David Heffernan suggests something similar in the StackOverflow topic mentioned above but for a different reason. The downside of course is the memory overhead involved in keeping all these rtti objects alive for the lifetime of the application. Any comments?

I could reproduce the problem. However I would suggest that you do not auto-create dialog forms. In Project, Options, Forms remove the OKRightDlg from the list of auto-created forms (move it to the right). Replace TForm1.Button1Click with something like this: procedure TForm1.Button1Click(Sender: TObject); begin with TOKRightDlg.Create(Self) do begin PopupParent := Self; ShowModal; Release; end; end;

I do not see this issue with Delphi applications created with Delphi Rio. Application.MainFormOnTaskbar := True; is called before the creation of the main form in the dpr file.

Works fine here. Are you using the latest versions from GitHub? Are you following the instructions at https://github.com/project-jedi/jcl and https://github.com/project-jedi/jvcl?

@David Heffernan http://docwiki.embarcadero.com/Libraries/Rio/en/System.UCS4String Your were spot on.

http://docwiki.embarcadero.com/RADStudio/Rio/en/Methods_(Delphi)#Class_Static_Methods I think it follows from the fact that static methods have no Self parameter. How could then display polymorphic behaviour?

Form serialization has been changed to become faster. Maybe the changes introduced bug(s).

I don't get the access violation with GExperts and Delphi 10.3.2. GExperts worked smoothly. But I am using GExperts 1.3.12.66 Experimental.

You can use a class helper to expose a private method of a parent class.

Use the magic with statement: With Self do SomeMethod This works in all version of Delphi including recent ones.

Andreas Hausladen. Obones and and a few others have been quite active in maintaining JCL/JVCL. Although, there are no recent releases the recommended installation procedure involves using the GitHub master. See https://github.com/project-jedi/jcl for details. JCL/JVCL support all Delphi versions including the most recent ones. There have been tens of commits fixing warnings and minors bugs over the last few months (https://github.com/project-jedi/jcl/commits/master) There are masses of gems in both JCL and JVCL that are still worth using in production code.

@dummzeuch Missing icon file added.

A related project, MultiInstaller, is not a package manager, but a good way to install multiple packages, directly from git repositories (e.g. Github), from zip files or from existing folders in one-step. I can start using a new version of Delphi in minutes rather than days. The project is fork of the Silverpoint MultiInstaller.

The code: var C: AnsiChar := #$0A; if C in [#$A, #$D] then Generates the following assembly code in 32 bits. Project2.dpr.26: var C: AnsiChar := #$0A; 004F9C10 C645FF0A mov byte ptr [ebp-$01],$0a Project2.dpr.41: if C in [#$A, #$D] then 004F9C14 8A45FF mov al,[ebp-$01] 004F9C17 2C0A sub al,$0a 004F9C19 7404 jz $004f9c1f 004F9C1B 2C03 sub al,$03 004F9C1D 751C jnz $004f9c3b On the other hand var C: Char := #$0A0A; if C in [#$A, #$D] then generates the following: Project2.dpr.26: var C: Char := #$0A0A; 004F9C10 66C745FE0A0A mov word ptr [ebp-$02],$0a0a Project2.dpr.41: if C in [#$A, #$D] then 004F9C16 668B45FE mov ax,[ebp-$02] 004F9C1A 6683E80A sub ax,$0a 004F9C1E 7406 jz $004f9c26 004F9C20 6683E803 sub ax,$03 004F9C24 751C jnz $004f9c42 Notice that it handles the wide char correctly. However the compiler issues the following warning: [dcc32 Warning] Project2.dpr(41): W1050 WideChar reduced to byte char in set expressions. Consider using 'CharInSet' function in 'SysUtils' unit. Question 1: Why the warning is issued, given that the generated code does not reduce the wide char to a byte? Question 2: Doesn't this mean that RSP-13141 has been resolved except for the warning? In the discussion of that issue @Arnaud Bouchez points out that the warning is misleading. In 64 bit the generated code looks much more complex: Project2.dpr.26: var C: Char := #$0A0A; 00000000005716E8 66C7452E0A0A mov word ptr [rbp+$2e],$0a0a Project2.dpr.41: if C in [#$A, #$D] then 00000000005716EE 480FB7452E movzx rax,word ptr [rbp+$2e] 00000000005716F3 6683E808 sub ax,$08 00000000005716F7 6683F807 cmp ax,$07 00000000005716FB 7718 jnbe TestCharInSet + $35 00000000005716FD B201 mov dl,$01 00000000005716FF 8BC8 mov ecx,eax 0000000000571701 80E17F and cl,$7f 0000000000571704 D3E2 shl edx,cl 0000000000571706 480FB60556000000 movzx rax,byte ptr [rel $00000056] 000000000057170E 84C2 test dl,al 0000000000571710 0F95C0 setnz al 0000000000571713 EB02 jmp TestCharInSet + $37 0000000000571715 33C0 xor eax,eax 0000000000571717 84C0 test al,al 0000000000571719 7422 jz TestCharInSet + $5D Question 3: Why is the code is so more complex in 64 bits? Please forgive my ignorance.

The help file states that "If you use the weak attribute in code compiled by one of the desktop Delphi compilers, the attribute is ignored" but this article by Marco Cantu suggests that it is supported by all platforms since Delphi Berlin. So is it available in win32/win64?

Thanks! The statement is from the help file of Delphi Rio. Topic Automatic Reference Counting in Delphi Mobile Compilers the only one you get searching on weak references.

Please provide runnable code. What is the expected result? What is the result you get?

LoadResStringW is not a Windows function. It s a function defined with the gettext unit. The THook is used to direct calls from System.LoadResString to gettext's LoadResStringW. It also redirects a bunch of other functions related to resource strings. Say for example this is your program: resourcestring Test = 'Hello" ... ShowMessage(Test); Your program will show the translation of Test, if it exists in the translated messages for the current language and if not it will show 'Hello'.

{$ifdef UNICODE} HookLoadResString:=THook.Create (@system.LoadResString, @LoadResStringW); {$else} HookLoadResString:=THook.Create (@system.LoadResString, @LoadResStringA); {$endif} The system functions are replaced with gettext versions that return translated strings. So wherever you use resource strings translated values will appear.

Automatic translation of resource strings.

@Uwe Great guess work.

@Stefan GlienkeIt does depend on what you are testing. If one claims that it takes > 1s for the first task to execute, it is sufficient to show it is not true. Also the work load on many real-life multi-threaded applications is not dissimilar. Say you fire 100 HTTP requests and you wait for the results to come, or you do asynchronous IO with memory mapped files (using overlapped events). I like this use of language: No doubt … followed by a debatable statement It is clear that … followed by an unclear statement No offence …. followed by an offensive statement etc.