Leaderboard

@Cristian Peța That looks like a perfect candidate for the Visitor explained in this article: The Visitor Pattern – Part 4 avoiding all the is type calls and type casting. The above code would break down to implementing a TTranslator class like this: type TTranslator = class(TVisitor) protected procedure IterateComponents(Instance: TComponent); public procedure VisitAction(Instance: TAction); procedure VisitComponent(Instance: TComponent); procedure VisitControl(Instance: TControl); procedure VisitCustomForm(Instance: TCustomForm); procedure VisitCustomFrame(Instance: TCustomFrame); procedure VisitMenuItem(Instance: TMenuItem); end; procedure TTranslator.IterateComponents(Instance: TComponent); var I: Integer; begin for I := 0 to Instance.ComponentCount - 1 do Visit(Instance.Components[I]); end; procedure TTranslator.VisitAction(Instance: TAction); begin end; procedure TTranslator.VisitComponent(Instance: TComponent); begin IterateComponents(Instance); end; procedure TTranslator.VisitControl(Instance: TControl); begin if Instance.Action = nil then begin end; end; procedure TTranslator.VisitCustomForm(Instance: TCustomForm); begin { translate form parts ... } { translate components } IterateComponents(Instance); end; procedure TTranslator.VisitCustomFrame(Instance: TCustomFrame); begin { translate frame parts ... } { translate components } IterateComponents(Instance); end; procedure TTranslator.VisitMenuItem(Instance: TMenuItem); begin if Instance.Action = nil then begin end; end; Instead of calling TranslateForm(MyForm) you would call Translator.Visit(MyForm)

Yes but don't ask me why - I've been told that some of the optimizations slow down compile time even more than already happening on LLVM based compilers compared to the classic ones but fwiw I would not care for longer compile time on release config.

It does. The reason it's not supported is because Delphi Interfaces are COM based which restricts this. A generic type parameter on a method is just that: a parameter - but resolved at compiletime to provide type safety. You probably have never used any language where interfaces easily support methods with generic type parameters - otherwise you would not have this opinion. FWIW this is one of the reasons I so strongly wish for interface helpers because then it would be possible to add such methods via helper - the COM based interface itself is not affected but you can easily augment them with such methods. In 2014 I wrote some code that shows how such interface helper methods could be invoked similar to record helpers: https://pastebin.com/acp2i645

@Dokkie Thanks for reporting. I uploaded build 2345 with a fix for that.

Well, at least that is a specific requirement. It is just that I would never be in that state (i.e. MMX not open), thus I didn't even consider this case before. You can disable that feature in General - Delphi Editor - Options - Auto toggle Object Inspector and Code Explorer, but then it will never be shown with F12.

Hello, if I disable the Theming in the Registry, then the MainMenu is shwon corrctly. best regards Torsten

When it happens, on my 4k monitor, I find there is a tiny slice of the red X which still works to close the IDE, if you hover the mouse at the edge. Going out of full screen, then back, restores the missing strip.

This is a known incompatibility between design packages and experts compiled with 10.3.2 when used with 10.3 or 10.3.1. Currently there is no workaround for that besides having two separate DLLs. I'd rather avoid that due to the build and setup nightmare that is causing. Nevertheless I am confident that Embarcadero will provide a hotfix addressing that problem pretty soon. In the mean time MMX 15 for Rio can only be used with 10.3.2, sorry about that.

Hi Uwe, I get this error on 10.3.1 rio while startup. All in 15 version build.

I think you need something like this procedure. And every unit with a form will use the unit where this procedure is located. Every form will use this procedure directly or will register itself for later translation. procedure TranslateForm(Form: TForm); var i, j: Integer; Frame: TFrame; begin for i := 0 to Form.ComponentCount - 1 do begin if (Form.Components[i] is TFrame) then begin Frame := TFrame(Form.Components[i]); for j := 0 to Frame.ComponentCount - 1 do begin if (Frame.Components[j] is TControl) and (TControl(Frame.Components[j]).Action = nil) then TranslateTControl(TControl(Frame.Components[j])) else if (Frame.Components[j] is TAction) then TranslateTAction(TAction(Frame.Components[j])); end; end else if (Form.Components[i] is TControl) and (TControl(Form.Components[i]).Action = nil) then TranslateTControl(TControl(Form.Components[i])) else if (Form.Components[i] is TMenuItem) and (TMenuItem(Form.Components[i]).Action = nil) then TranslateTMenuItem(TMenuItem(Form.Components[i])) else if (Form.Components[i] is TAction) then TranslateTAction(TAction(Form.Components[i])); end; end;

That is not breaking cycles, but actually creating them. Cyclic dependencies in the interface simply don't even compile. Therefore cyclic dependencies are only possible in the implementation section.

There is a new beta drop (build 2344): https://www.mmx-delphi.de/downloads/download-info/mmx-beta-build/

How easy does it seem right now?

You are still using connection pooling with this approach. Connection pooling doesn't pool TFDConnection but TPhysConnections which can be accessed by TFDConnection.ConnectionIntf.

[OT] 1068 Hints 1937 Warnings How do you see anything ...the most important things. [/OT]

Hi David, I'm certainly not an expert in this field. Over the years I've seen various speed benchmarks that suggest Delphi's Windows compiler produces executables that are significantly slower than those produced by the top C++ compilers (e.g. Intel). In the chess world (where I am an expert) the rule of thumb is a Delphi version of a chess engine will run about 30% slower than the C++ equivalent code bases (Critter is the engine that was developed in two parallel code bases). Let's face it, there doesn't seem to have been any work done on optimizing the code created by the Delphi compiler in the last 20 years. I'm just hoping the new backend will be better. Thanks, Steve

We have noticed that Documentation Insight was broken in the latest Delphi 10.3.2 update. Here is the hotfix: http://www.devjetsoftware.com/downloads Thanks for your support!