Uwe Raabe

In MMX Code Explorer properties look in General-Searching and History.

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.

What is the exact error you get? When clicking on the link I get this:

I can reproduce with 12.1 here.

Please file a bug report at https://qp.embarcadero.com/

Which is actually six chars less than the with version. I can see no benefit in such with-V2 syntax. Local begin-end blocks without with, for or while have been part of the language since the beginning. With the advent of inline variables they may get some more use cases now. I would not call that fake in the first place.

Let's hope that it is not just that tool currently in action...

No, it has been mentioned in a private channel.

They are aware of it and working to get it right again.

Version V15.0.37 of MMX Code Explorer introduces Structured Difference Viewer (former available as a separate product). It is registered as an External Difference Viewer in the IDE and can be used as an alternative way to compare source files.

I can reproduce that. Please file a bug report at https://qp.embarcadero.com/

That would break compatibility with older Delphi versions. Either these changes have to be wrapped in some IFDEF directives or one has to specify at least Vcl.Imaging in Unit Scope Names of the project using the library.

The supported platform names can be found in PlatformConst.pas. It is what GetAllPlatforms returns.

Project Magician has an option for that:

pngimage.pas should never be compiled in 10.4.2. It is not even part of PngComponents as it already exists as Vcl.Imaging.pngimage.dcu in the Delphi library path. You should delete that pngimage.pas and probably pnglang.pas, too.

Just those have been identified as a potential source of problems recently.

Indeed, the OnChanging event would be a better place. Unfortunately it is triggered at least twice when AllowChange is set to False, even with the checks shown above.

If no one posts a solution there simply probably is none.

Not sure if I get you right, as managing the file version information is usually done in Project Options: https://docwiki.embarcadero.com/RADStudio/Athens/en/Version_Info

No, the actual components don't have to be derived from TSelectionEditor. That would probably be near to impossible, as it would require to use design-time code in the application. Instead you need to register a TSelectionEditor descendant for each of these components and implement the RequiresUnits as appropriate.

I'd like to ask for more details about the term early in this context. Is this targeting the initialization sections of some units or more the code in the dpr begin end section? I admit that I often fell into the trap to put too much code into the initialization section, but I found that it heavily reduces the possibility to tweak the behavior based on a configuration or on a per project basis in case these units were used in several projects. That was a driving force for the invention of Cmon.Initializing. While it is still a long way to get all (probably better most of) my projects suffering from the above drawback, this approach is almost mandatory for new projects now. As a couple of units of CmonLib make use of this, one can find some hints for usage in the examples (still successfully procrastinating the CmonLib documentation, I know). Let me show a simple example from Cmon.Messaging.Dialogs.Vcl. This is how it would be written the old way: var Instance: TDlgMessageHandlerVcl = nil; initialization Instance := TDlgMessageHandlerVcl.Create; finalization Instance.Free; end. As a result, simply using this unit will create the instance, which registers itself catching the corresponding messages. And this how it looks making use of Cmon.Initializing: var Instance: TDlgMessageHandlerVcl = nil; { will be called in Application.Initialize after all other initialization code has been executed } procedure InitHandler; begin if TDlgMessage.AutoRegisterHandler and TDlgMessageHandlerVcl.AutoRegisterHandler then Instance := TDlgMessageHandlerVcl.Create; end; initialization TDlgMessageHandlerVcl.AutoRegisterHandler := True; TInitialize.AddInitProc(InitHandler); finalization Instance.Free; end. Now creating the instance will take place during Application.Initialize, which allows us to write some code tweak the behavior. As of my personal preference I put all this pre-initialize code in s similar named procedure, called immediately before: program DialogsDemoVCL; uses Vcl.Forms, Cmon.Messaging.Dialogs.Vcl, Main.VclForm in 'Main.VclForm.pas' {MainForm}, Utilities in 'Utilities.pas'; {$R *.res} procedure PreInitialize; begin { Per default using Cmon.Messaging.Dialogs.Vcl will automatically register the containing message handler during Application.Initialize. To optionally disable auto registering of all DlgMessage handlers this is one place to do. You need to add Cmon.Messaging to the uses to make it compile. } // TDlgMessage.AutoRegisterHandler := False; { You can as well disable automatic registration of indivudual handlers. That implies to leave the corresponding setting above at True of course. } // TDlgMessageHandlerVcl.AutoRegisterHandler := False; end; begin PreInitialize; Application.Initialize; Application.MainFormOnTaskbar := True; Application.CreateForm(TMainForm, MainForm); Application.Run; end. You can find a similar approach in Cmon.Messaging.Logging.TextFile

Can you compare the dsk files for the group and the single projects? Can you spot something fishy?

Can you show some code - even when ugly?

What hinders you to declare your own types for that? Then you can write your event handler methods just like before. type TFooProtocol = TCustomProtocol<TFooMsg>; TBarProtocol = TCustomProtocol<TBarMsg>;

There are some constants declared in System.pas telling the history: OlderLocaleOverrideKey = 'Software\Borland\Delphi\Locales'; // do not localize OldLocaleOverrideKey = 'Software\Borland\Locales'; // do not localize NewLocaleOverrideKey = 'Software\CodeGear\Locales'; // do not localize NewerLocaleOverrideKey = 'Software\Embarcadero\Locales'; // do not localize