Alexander Elagin

I wonder if Sternas Stefanos (CodeTyphon, you know) considered this option. As far as I can see, his CT bundle uses FPC trunk.

NewPascal tried to be such a fork but also died because (I guess) Maciej could not do all by himself and there was nobody else to work on the code. Do you think that another fork could be more successful? Yes I clearly that the FPC compiler development came to a roadblock due to aiming strange goals (I like "More OS/2 support" and "New compiler targets: Support for the i8086-win16 (16-bit Windows) target" as the future plans ) and THAT is a real problem . Otherwise we could already have a real cross-platform VCL (LCL) combined with a pretty good compiler, while now I just cannot use advanced Delphi libraries (like Grijjy) with FPC and have to use Delphi Linux compiler with its debugging nightmare and no desktop support. And I am honestly afraid that if said Linux desktop is ever implemented it may be FMX-based which means rewriting all UI instead of going the LCL way (one common VCL-compatible layer supported by different widget sets - winapi, gtk, etc).

Why choose LLVM? Maybe GCC backend handles exceptions better?

I think it would be easier to write a brand new frontend parser from scratch and feed its output to LLVM or whatever else backend code generator because I understand what it means to have to deal with huge amounts of undocumented legacy code. Unfortunately, I highly doubt there are enough developers interested in writing such parser, let alone the absence of the formal grammar definition. And given the strange state of the FPC development where it seems that the core developers are not interested in implementing new features (closures / attributes / etc, even when there are already provided implementations for these features collecting dust in the bugtracker for years) I feel there is nobody to write another Pascal compiler. The RemObjects compiler genius Carlo Kok has already developed Oxygene and I highly doubt anybody could persuade him to develop a free fully Delphi-compatible compiler in his spare time.

Does not work here when compiled with Delphi 10.1 (Win 7 Pro x64) with the same symptoms - server hangs. But works perfectly when compiled with Delphi XE in the same environment.

In case somebody is looking for the official news: https://talk.remobjects.com/t/remoting-sdk-for-delphi-vnext-new-features/18354/5

No. I have also noted that in 10.3 toolbars sometimes start jumping from line to line even without layout switching, just by moving mouse somethere. But this is not reproducable. As I don't use 10.3 as a primary IDE, I can only say that 10.1 does not suffer from this problem (and other bugs introduced in later releases).

Unfortunately, I do not see any way to stop this endless IDE revamping trend (save bribing someone from the Embarcadero management ). I wish I could use the 10.3 compilers with the plain old XE IDE... And now "the dogs (we, the users) bark, but the caravan goes on". BTW, the DevExpress Skins library has been around longer than VCL styles but I don't remember many problems with using it or switching skins on or off, unlike the Delphi IDE which seems to be heavily rewritten to adopt theming and introducing endless bugs in the process.

And they even removed the checkbox to disable theming from the IDE settings dialog in 10.3.1. Instead of fixing the obvious problems with said dialog. There still is a registry setting (probably left unnoticed 😉 ) which disables theming but they may as well remove it in the future releases leaving us with an unusable IDE... I wish all resources spent on this theming nightmare since XE2 (? don't remember when it all began) were allocated to real bug fixing.

The DevExpress VCL roadmap has been finalized: https://community.devexpress.com/blogs/vcl/archive/2019/02/18/vcl-controls-2019-roadmap.aspx Not the best one but at least with some nice improvements promised.

I prefer Subversion as it is very easy to use (with TortoiseSVN) and easy to manage in closed environment with its centralized repository storage. Git has its nice features but they are not for everyone, and its distributed nature complicates things. Anyway, here is a very good tutorial how to install a Git server to play with, maybe it can help to make the right choice. TortoiseGIT client is also available.

Finally the Quality Central issues statuses begin to update. And what do you think? RSP-21645 (Editor tabs do not show icons) - closed. Resolution: Works As Expected 🙁 . Really, that is how they at Embarcadero see it. RSP-21636 (Active editor tab is not highlighted when IDE theming is disabled) - closed. Resolution: Won't Fix. Given this stupid attitude (and obvious intentions to further force the themed IDE despite all its glitches) I highly doubt that I'll renew my subscription when it expires this March. I thank David Millington for personally contacting me but I do not want to further waste my hard earned money for another round of cosmetic IDE changes instead of bug fixing.

Have you seen the smile in my comment? I'd never use such design myself (for modal forms I use class functions, non-modal always have their own local variables). This was just an in-situ snippet to show how to use TFormClass and polymorphism in action based on the originally posted code.

Maybe something like this? procedure AccessForm(var aForm: TForm; aClass: TFormClass; aModal: Boolean); begin if not Assigned(aForm) then aForm := aClass.Create(Application); Assert(Assigned(aForm)); // just in case :-) if aModal then aForm.ShowModal else aForm.Show; end; ..... AccessForm(Form2, TForm2, True); ....

There are at least three large components: compiler(s), RTL / component libs and IDE. Having very limited resources (as I guess) one has to concentrate on something to achieve at least visible progress in one of the components. A large group of Delphi users obviously desperately waits for compiler (language/codegen) improvements and additional platforms support. Instead we see tweaking the IDE introducing a lot of glitches/bugs/name it yourself which are obvious even after ten minutes of active usage. Was there any reason to rebuild the Options dialog probably from scratch paying no attention to bottom alignment? Or SDK manager where I could not do anything until I resized the window and saw that there are indeed buttons, invisible at first look? Component toolbar options page has fixed height - why? Every other Delphi version had it adapt to the window height. In previous versions dialogs were carefully aligned, with necessary anchors set. Now it seems that somebody had just quickly thrown a bunch of controls on the form giving no attention to how it would look in reality, and more - nobody bothered to check the result. Toolbars sometimes start to jump around by themselves - I never saw this in any other Delphi version. And so on... I do not doubt that a lot of efforts was put in development, but it looks like they were mostly wasted reinventing the wheel (i.e. modifying IDE breaking it functionality) instead of focusing on, say, compiler. This is a question of targeting the right aim. Or we are starting to see the result of outsourcing the development (when was the core Delphi R&D team fired? A year or two ago?)