Leaderboard

There is an unofficial download available for MMX Code Explorer with Delphi 10.3 Rio support. Unofficial because it didn't have had much testing yet due to some incompatibilities found during the beta phase. One of this results in the loss of the MMX editor context menu entry. Another big change ist that MMX version 14.x only supports Delphi 10 Seattle and higher. For that, version 13 will still be available for download and installations for older Delphi versions should keep working. I had to make this cut to avoid wasting too much time just to make it work and test it on those older versions. Nevertheless there are some features and bug fixes: Unit Dependency Analyzer is now dockable (so you can see immediately when you introduce cyclic dependencies) New settings page Project Options (currently contains only the setting for Uses Clause Sorting). These settings are stored per project in a separate section of the dproj file. Uses Clause Sorting accepts lists like (ToolsApi,DesignIntf) as one group. This only affects grouping, so the order inside this list is not relevant. Uses Clause Sorting accepts wildcards like Rz* (for Raize Components) or Id* (for Indy) to better handle non-dotted unit names New sorting options "group class members" - keeps the class methods together fix: Wrong result when renaming parameter during Extract Method fix: Add Local Variable now also works with For-In clause fix: Hard coded string scan check for min length works correct now fix: Paste Interface in empty class just works now fix: Consolidated behavior of selected file in Open/Use Unit dialog fix: Creational Wizard follows static/non-static when suggesting destructors Some work has been done for supporting themes, but that is still a long road to go. Please report any bugs and problems found either here or via support@mmx-delphi.de.

Usually in this scenario one would prefer to get on with the job rather than spend time explaining the issues. I'm sure that if @dummzeuch would like some help he know how to ask.

Just wanted to share my last blog post on changes to the Delphi language in 10.3: http://blog.marcocantu.com/blog/2018-november-custom-managed-records-delphi.html Still a bit rough in some details, but a very handy feature overall.

… but I am working on it. I have already installed the new version and it compiles on my machine. But don’t hold your breath, there are some issues. Until then you can always download the sources and compile your own DLL. https://blog.dummzeuch.de/2018/11/22/before-you-ask-gexperts-for-delphi-10-3-is-not-ready/

And historically, some pretty bad parts, it seems.

You just have to extend the code to bring itself out of the tray as you say. Although strictly speaking it isn't in the tray and in fact the tray isn't even called that. It's a notification icon in the notification area. What you mean by being in the tray is that the main form is hidden, Visible is false. So you just need to show it. Presumably you already do that when the notification icon handles being clicked.

Thanks, I hope that will help me find the problem. I already suspected the Favorites-Menu, but your unformation confirms that. (I'm busy otherwise right now, this won't happen before the weekend.)

Application Error in SynTextDrawer.pas occurred after each closing Rad Studio IDE 10.2.3. After that AV message window displayed. This error start from revision 2421 26.10.2018 "IsFavMenuVisible now gets persisted" and exist in last revision 2436 still

Just a quick note - last OTL release compiles and works fine in Rio. here will be a new release with some bugfixes and official Rio support in few days.

The process of updating GetIt packages is just too clumsy to keep pace with new releases.

Unigui is good solution, it will make things easier because you don't have write code in two projects, one for backend and one for frontend. It's combine with power of Delphi in the RAD way with the most rich JS library (Ext JS). Here's sample of one of dashboard we made with Unigui: another sample from unigui forums: PS: I'm just happy unigui customer.

Hi All We have released FinalBuilder 8.0.0.2496 with support for Delphi and C++Builder 10.3 This page shows what's new/changed in this update : FinalBuilder version history You can download a fully functional 30 day trial version of FinalBuilder here. FinalBuilder is an award winning Automated Build Tool, with support for Delphi, C++Builder, Visual Studio and many other tools (over 600 individual actions). Regards Vincent Parrett VSoft Technologies https://www.finalbuilder.com

@Arnaud Bouchez I know you like to deal with low level stuff but being able to be more declarative about loops and other language constructs is a benefit imo. That var passing of the loop variable is bad, but Primoz wrote that just for fun and advised not to use it. I guess every Delphi developer knows how a while or repeat loop works but I have seen enough off by one errors caused by counting the loop variable wrong, messing up the loop condition or other stuff which could just be eliminated if the language itself could treat it right without the need to put extra abstractions ontop that just make code slower. Another thing that just applies to 10.3 though is that only in a for loop you can inline declare the variable to only be valid in the loop scope and not outside.

You can also consider handling the application wide WM_ACTIVATEAPP where WParam = 0 when you lose focus and 1 when you get focus- and then explicitly hide/restore your floating forms.

The Owner is not necessarily the form. Sometimes the owner is a TFrame descendant or may even be nil. Iterating the Parent until a TCustomForm is found is usually the way to get the required form instance. Perhaps iterating until Parent is nil is another valid approach. That would also cover the case where one form is parented into another one.

It will not get them more customers just because it's 64bit and runs out of memory later because all the instabilities and the compiler getting into a bad state because of compile errors or what not crashing the IDE will still be there as will the poor code tooling. Going the easy/cheap way every time is what puts Delphi and the IDE into the current situation of constantly having to react to external factors and tinker around edges. Sometimes I really have a hard time believing that or you just avoid certain features or have subconsciously developed a certain habit to do things differently. Or you just use it to prepare demos.

Yeah, then the IDE can more excessively waste memory left and right until your RAM is used up instead of crash early, brilliant idea... Throwing more memory at an application that does not know how to properly manage memory is not the solution. Oh, please, no excuses about the compiler leaking memory because of LLVM, if you know that then don't load it into the IDE process. Ah, that has to be done to use it for IDE tooling, like code completion and all kinds of source related things. Now you see why other languages and IDEs go the way of separating this and using a language service to provide such information

Tokyo is pretty good, but if I switch between a lot of projects to build - I still eventually run out of memory. I wouldn't mind a 64-bit IDE down the road.