Leaderboard

They are only just now working on this? When CE was first introduced several years ago, they didn't think this might be a problem down the line? They've had 3 years to fix it, what are they hoping to do in a few days?

Any style that differs from the current OSes UI style and style guide, will cause an application to look and feel strangely out of place. You might want or like that, but most of the time users will feel uneasy about it as soon as the initial "wow how pretty" effect has faded to "why is the quit button green?". So in essence styles to me are just another toy where Embarcadero has wasted precious time and money, both of which are direly needed in other areas of the product.

And I still think Idera has the math all wrong. If they sold Delphi Developer at 1/3 the current price, I believe they'd more than triple their sales. As a hobby developer I'd be prepared to spend that instead of using the CE, which I'm currently using. Edit: At the very least Idera should do some market research and ask CE users what they'd be prepared to spend for the Developer edition. Heaven forbid, they might even attract some new developers instead of just bleeding their current user base.

Hi, Sherlock, I disagree with you. I don't think styles are a toy or a waste of EMB time and money. Styles are a necessary tool to allow us developers to modify our apps. I agree that massive changes are ill-advised and will confuse the user. But many modern apps (including the IDE) have a dark mode, which is what we are using styles for. We're not going to make massive changes to the UI that would confuse the user.

I develop only VCL for Windows and my target are almost exclusively Win10 e Win11 (and Win2012 server+). Windows 7 practically disappeared from my customer PCs and Windows 8 never appeared. In my scenario I'm happily using styles: with latest Alexandria 11.x EMB provide at least 4 default VCL styles HIDPI compliant 2 for Win10 and 2 for Win11 (2 = light + dark). I decide in real time the style to use based on the SysOp and the user's choice to use the light or dark theme of Windows and I get an acceptable result and an UI compliant with that of the SysOp. Without styles in VCL its impossibile to create dark apps.

Done https://sourceforge.net/p/gexperts/bugs/291/ https://sourceforge.net/p/gexperts/bugs/292/

With all this primitive tiles and simplified monochrome UI the OS vendors are enforcing, I doubt styles stuff will ever be actual again like in the times of WinAmp.

Not so much, reading good technical success stories is one of my hobbies

But when you are only a handful of trusted contributors you don't have to use the Github workflow but can have them merging (perhaps with rebase and smashing) locally and then have them push the changed branches to Github. And if you work this way with your trusted contributors you can still be open for external contributors with the Github Fork-Merge-Request-Workflow. That's really the best of both worlds. We have to face, that Delphi itself is obscure enough for younger developers. Clinging to outdated tools, hosting options and workflows nobody learns anymore isn't going to help.

Disagree. I have all my projects in Git (most of them are pretty small as they represent different util collections/libs) and contributed much to multiple Git projects with one or several developers. Nothing complex. Fork the project, pull it, make changes, commit them, push them, press "Make Pull request" button. Owner has convenient UI of reviewing changes - either divided to commits or consolidated. If everything is OK he just presses "Merge" button and that's all. Also nothing prevents several devs from direct committing & pushing a-la SVN. And how contributions are implemented in SVN? Dumb and fragile diff files? Yeah, they indeed are much simpler to review *irony*

System.Rtti contains a lesser known, but powerful class TMethodImplementation, which is basically hidden and used in TVirtualMethodInterceptor. Outside this use, it cannot be created directly and it can only be accessed by TRttiMethod.CreateImplementation. I recently discovered that Spring4d extends its use through a helper for TRttiInvokableType, so it can be used with standalone procedures and functions as well as with events. Here is a small console app showing how it can be used: program MethodImplementationTest; {$APPTYPE CONSOLE} {$R *.res} uses System.SysUtils, System.TypInfo, System.Rtti, Spring; type TSimpleProc = function(I: Integer): Integer; procedure ImplCallback(UserData: Pointer; const Args: TArray<TValue>; out Result: TValue); begin WriteLn('From Implementation'); Result := Args[0].AsInteger * 2; end; var Proc: TSimpleProc; begin ReportMemoryLeaksOnShutdown := True; try var RTTIContext := TRttiContext.Create; var RTTIType := RTTIContext.GetType(TypeInfo(TSimpleProc)); var ProcImplementation := (RTTIType as TRttiInvokableType).CreateImplementation(nil, ImplCallback); Proc := TSimpleProc(ProcImplementation.CodeAddress); WriteLn(Proc(2)); ProcImplementation.Free; except on E: Exception do Writeln(E.ClassName, ': ', E.Message); end; ReadLn; end. Output: From Implementation 4 Simple and easy. Spring4D is full of gems. I wish the above functionality was part of the standard library. I can think of many uses: Python4Delphi contains a unit MethodCallback which uses complex assembly to convert methods into stubs that can be used with external C libraries. It could be rewritten using TMethodImplementation, without assembly code. Also in Python4Delphi, the implementation of Delphi events using python code could be very much simplified and generalized using TMethodImplementation. You can create Delphi functions, procedures and methods, event handlers on the fly that are implemented by python code. Similarly functionality can be provided with other scripting languages.