Leaderboard

Typically, any Delphi app runs smoothly on Windows 11 (I've been using W11 since June). Using an application with native Windows Style, the main differences I found are visible in this form: The window and even the menu have rounded corners The menuitem selected has rounded corners and a smaller area of drawing The major problem is visible in the selected cell of a DbGrid: a strange rectangular and a rounded focused box: very bad to see. If an edit has Ctl3D it works like default in W11: only the bottom border is visible (and colored): when the input receive focus the bottom border gets thicker Selected RadioGroup has a colored border instead of a dot inside. Scrollbars are thiny and enlarged when focused. Buttons are rounded Using a Styled app, all of those problem disappear, but it would be useful to have styles that look like Windows 11, just as Windows 10 styles were created (I hope in the next Delphi 11 release).

If you don't want instances, then don't make it a class - this ain't Java.

Suggestion: Throw the ENoConstructException from System.SysUtils, not a regular Exception 😉

There is another way to prevent instance creation - or at least misuse - having public constructor that raises exception. TSingleton = class private class var FInstance: TSingleton; constructor CreateSingleton; class destructor ClassDestroy; public constructor Create; class function Instance: TSingleton; static; end; class destructor TSingleton.ClassDestroy; begin FInstance.Free; end; constructor TSingleton.Create; begin raise Exception.Create('Singleton instance cannot be directly constructed'); end; constructor TSingleton.CreateSingleton; begin // actual constructor end; class function TSingleton.Instance: TSingleton; begin if not Assigned(FInstance) then FInstance := TSingleton.CreateSingleton; Result := FInstance; end;

Thank you! Delphi has a method for grouping a collection of common procedures/functions together... it's called a Unit.

I am absolutely putting my bet on this. The second issue after that will most likely be a non-cache-friendly access pattern. But you don't have to guess - run the code under a profiler and it will tell you the slow parts.

Hi everyone, Following fast on my last post, I thought I'd also share another development I've started - a Console Manager for the Delphi IDE. This is a tool that allows you to spin up a cmd.exe or powershell.exe within a dockable form, localised within the Delphi IDE. Features: - It is aware of the active project, so it will open up in the directory in which the dproj is located. It is still very alpha as in it just streams stdout/stdin, and not totally pleasant on the eye, but ok for an alpha POC. - I've got a little slider that allows you to zoom in/out. - (planning) The ability to have lists of commands / saved environments that could be applied to a newly created session. This is a POC, and still have some more work to do as I want to embrace the new pseudo console api which was introduced with the new Windows Terminal drive along with the VT emulation which would support colour, repositioning of the cursor, etc. I have not released this publicly yet, but attached is a short video demonstrating how it works. If you are interested in accessing it, please send me a mail: conrad.vermeulen@gmail.com. Let me know about what IDEs versions you may be interested in. I think I can do XE8 onwards. I'll provide more information when it is officially released. Regards, Conrad

Well, he could be referring to IDLE... but that is a long shot. 😄

Looks like a compiler defect - when changing this declaration: TOnMyIntfItemSelected<T: IMyIntfItem> = procedure(AItem: IMyIntfItem) of object; the code for TMyIntfItemA<T>.Select looks like this: List.Intf.pas.82: begin 007083E4 53 push ebx List.Intf.pas.83: if Assigned(FOnItemSelected) then 007083E5 6683781200 cmp word ptr [eax+$12],$00 007083EA 7411 jz $007083fd List.Intf.pas.84: FOnItemSelected(Self); 007083EC 8BD0 mov edx,eax 007083EE 85D2 test edx,edx 007083F0 7403 jz $007083f5 007083F2 83EAE8 sub edx,-$18 // this is where it turns Self into an IMyIntfItem, $18 is the offset where the interface method table pointer sits inside the object 007083F5 8BD8 mov ebx,eax 007083F7 8B4314 mov eax,[ebx+$14] 007083FA FF5310 call dword ptr [ebx+$10] List.Intf.pas.85: end; 007083FD 5B pop ebx 007083FE C3 ret but when it has the generic T parameter it looks like this: List.Intf.pas.82: begin 007083E4 53 push ebx List.Intf.pas.83: if Assigned(FOnItemSelected) then 007083E5 6683781200 cmp word ptr [eax+$12],$00 007083EA 740A jz $007083f6 List.Intf.pas.84: FOnItemSelected(Self); 007083EC 8BD8 mov ebx,eax 007083EE 8BD0 mov edx,eax // here it simply passes Self 007083F0 8B4314 mov eax,[ebx+$14] 007083F3 FF5310 call dword ptr [ebx+$10] List.Intf.pas.85: end; 007083F6 5B pop ebx 007083F7 C3 ret To explain this a bit more: when putting an interface type as generic type constraint this means for the compiler that the type you put for the generic type argument not only has to be that interface type but also that it can be a class that implements this interface. TMyIntfItemA<T> does this and thus satisfies the compiler when passing it to the argument of that event handler. However, inside the event handler, it is being treated as an interface and due to the lacking const parameter the compiler inserted an IntfAddRef call which blows up as the parameter that was passed was not really an interface reference but an object reference. Putting the const parameter makes it blow up a bit later though, namely when accessing Caption.

The question is this: do you want to get a wide adoption rate of something you've built or do you want to get two and a half coffees paid. As for how the console is done: Visual Studio Code simply communicates via stdin/stdout/stderr - see https://vscode.readthedocs.io/en/latest/editor/integrated-terminal/

Is it really so important to disallow instance creation?

I wish the "class abstract" declaration would have prevented .Create instantiation.

I was not sure if the docking thing would be a hard or not, but decided to give it a shot... and result! Thanks for the feedback.

Just an idea... is it possible to inject a console window itself into a dockable panel? Maybe it would be easier than full terminal emulation which would lack many features anyway.

You can define the group names per project in MMX Properties - Project options: A single identifier is treated as a group prefix which has to be followed by a dot (like System, VCL, FireDAC). You can also use wildcards like Rz* for all units from Raize Components (KSVC). Unit names not covered in one of the schemes above can be listet in brackets. This is the setting for MMX itself: (ToolsApi,DesignIntf,DCCStrs,DockForm,TabDock);Winapi;System.Win;System;Xml;Vcl;VirtualTrees*;Rz*;Tb*;Png*;MMX The settings are stored in the dproj file.

I offered up a solution. It may not be ideal, but as you say, that's impossible. So, yeah, we've gotta make do with what we've got. The language purists have managed to keep stuff like this from being properly implemented forever. There are all kinds of holes and back-doors and things that can only be done with awkward work-arounds in Delphi, and I don't expect that will ever change. Everywhere I've worked has all sorts of unwritten rules about what devs can and cannot do in order to deal with this stuff, and when I dig into the code there are also lots of violations of said rules, mostly by those who made the rules up in the first place. ("Do as I say, not as I do!")