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.

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.

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.

I want to say a big Thank You to Daniel for providing a dedicated place for the MMX Code Explorer Community. This is much more that I would have been able to create by myself. Besides the website https://www.mmx-delphi.de/ this will be the most prominent place to announce new versions, answer questions and discuss new features.

I have just uploaded the sources for the Code Coverage Plugin shown during my session at EKON 22 on Monday. Besides its functionality it may also give some guidance on writing IDE plugins in general. https://bitbucket.org/uweraabe/codecoveragemagician Tested only on Delphi 10.2.3 Tokyo!

Who hasn't seen this before: A bunch of controls and actions are linked to an ImageList with an ImageIndex, but as soon as you sort this ImageList to give it a sensible order all controls immediately start to show the wrong images. Wouldn't it be cool if instead a cryptic number as ImageIndex you could specify a descriptive name at the control? Thus the order of images inside the ImageList wouldn't matter at all. Of course, the ImageList has to support names in the first place. TPngImageList from PngComponents does that right from the beginning. So what about implementing that feature based on TPngImageList? Can't be that hard, can it? Well, it turned out to be a bit more complex than I anticipated, but that's probably because I had set my goals pretty high. So I expected to have a selection from image names for the ImageIndex properties of the control and thus a display of the image name instead of just a number. Also this scheme should be extendable to other controls and especially to other ImageLists supporting names. From this the ImageIndexMapper was born. A non-visual component to be placed on a form or datamodule, that when activated takes care of the image names. You just have to call one method to resolve those names to the actual corresponding number values. The attached ZIP file contains all the sources and files for the component and design time support as well as a sample project (currently for Delphi 10.2 Tokyo only). As a prerequisite you have to use PngComponents from the above source. I suggest to use the recent version V1.5.0 with direct ImageIndexMapper support. Older versions require the contained PNG Support Package to be installed and add the corresponding unit to your uses clause somewhere in your project. Version 1.5.0 makes this obsolete, Presumably there is much room for improvement. Whoever finds some time to test this component - please forward any encountered bug to me. Here is a short GIF showing the switch from TPngImageList to TImageList (without name support) in the Object Inspector: https://www.screencast.com/t/4MbJkygjFR ImageIndexMapper.zip Cross Post: https://www.delphipraxis.net/198212-imagename-statt-imageindex.html#post1415709

More info here: http://community.idera.com/developer-tools/b/blog/posts/new-in-rad-studio-10-3-options-dialog-improvements

MMX Code Explorer shows "Related Classes". When called from inside an interface it shows the implementing classes with navigation on click.

Google+ used to be a great place for the international Delphi-community. But it will be shut down next year, so there was a need for a new home. The German speaking community “Delphi-PRAXiS” exists since 2002 and became one of the most important Delphi-communities in Germany, Austria and Switzerland. Now we want to make the next step: We created an English community parallel to our existing German community. We all wish that this community will experience a similar success as our German community. If you already are a German speaking Delphi-PRAXiS user, you can use your existing account, but you have to reset your password. Please visit the following page and follow the instructions: https://www.delphipraxis.net/pages/clone_account.html

Now that Delphi 10.3 Rio is out, we had to ensure that our little mORMot would run with this revision. Since we don't make any commercial software with Delphi any more (we switched to FPC), I downloaded the Community Edition. We disabled the Error Insight feature, which seems not very stable especially with our mORMot complex units - as with previous Delphi versions. In respect to the previous "Starter" editions, this CE version includes everything you expect for good work: Win32 + Win64 + OSX + mobile compilers, and even the source code of the RTL and enabled command-line compilers! The IDE seems really refreshed with its new layout. You feel at home and with some modern and fresh air! Great work Embarcadero! Of course, the "Pro" and "Architect" features are missing (like FireDAC, DataSnap or RADServer). But mORMot is self-contained even for the database access, so with the CE you can write full-features REST/SOA client-servers and MVC web applications, with a simple ORM and high-performance OleDB/ODBC database access to SQlite3, MSSQL, Oracle, Firebird, MySQL and others (by-passing the TDataSet class for better performance) and even NoSQL like MongoDB. Ensure you follow the Embarcadero license terms when you use mORMot with the Community Edition. With Rio, the main breaking change was that the PCRE API switched from an UTF-8 to UTF-16, and did hide the UTF-8 function calls. But after a small patch, now everything works as expected - at least for our regression tests. See http://blog.synopse.info/post/2018/11/24/mORMot-running-on-Delphi-10.3-Rio

@Tommi Prami That's easy: https://github.com/RomanYankovsky/DelphiAST You might want to try the version with all my patches in it: https://github.com/JBontes/DelphiAST It seems Roman Yankovsky has not had time to integrate all my issues yet. It **is** a very mature library and using it will serve you well. If you want to change the code, grokking the calls between the different parser levels does take some getting used to. I suggest first reading up on the difference between a parser and a lexer if you want to do that. PS don't be put off by the XML output, that's just a cheap trick to display the contents of the tree. You don't need it to work with DelphiAST.

Thanks to @Daniel for making this happen so fast. I hope this forum will serve as a replacement for the G+ community and the mailing list. There should be a RSS feed for it and Google (and other search engines) will index it. Please post bug reports and feature requests as tickets on source forge.

- IDE is slower than 10.2.3. For example, you can see how Project/Options window is being drawn while opening. - If you set the dark mode, then you can see how options window is first drawn white and then skinned. - Code scrolling in the editor seems bit slower. - When app is run and the closed, lots of windows resizing, flickering is going on while the IDE goes from Debug to Default layout. (The same is happening in 10.2.3 as well, only it does it much faster). - Sometimes after couple of runs Object inspector is not drawn at all until you refresh it. - 1st full recompile of the project took about 12 seconds - 2nd full recompile 40 seconds - 3rd full recompile minute and something - 4th one is still running (joke) - After couple of recompiles, the whole IDE just blurs in the background, compiler gets stuck, and then after some time everything resumes. - Code completion still isn't working in my project (It works after the 1st compile, then stops until project is cleaned). I reported it to QC and even got some response in the item, but then it stopped. When I turned the skinning off, IDE become more responsive, but some of the tool bars are drawn with non default background and when I hover over the tool bar buttons, the background for them becomes black. I'm kinda sad. Usually I install the new Delphi and very soon uninstall the previous one, as the new one is just better. Not this time 😞

I wonder, would it be nice to channel posts on QP issues to a specific sub-forum? f.x. "Delphi Bugs & Issues" Sub-titled "Reported to QualityPortal" We do get a certain amount of these, particularly around new releases.

FindFirst is definitively the slowest. It needs at least two calls (+ FindClose), and maintain some state in-between. GetFileAtributes() is the fastest under Windows, and fpaccess/euidaccess on POSIX systems. Note that a fallback to FileAge() is needed in case of sharing violation: function FileExists(const FileName: string): Boolean; {$IFDEF MSWINDOWS} // use GetFileAttributes: much faster than original, which uses FileAge=FindFirst var Attr: Integer; LastError: Cardinal; begin Attr := Integer(GetFileAttributesW(pointer(FileName))); if Attr <> -1 then Result := Attr and FILE_ATTRIBUTE_DIRECTORY = 0 else begin LastError := GetLastError; Result := (LastError <> ERROR_FILE_NOT_FOUND) and (LastError <> ERROR_PATH_NOT_FOUND) and (LastError <> ERROR_INVALID_NAME) and // (use FileAge to test SHARE_EXCLUSIVE files) ((LastError = ERROR_SHARING_VIOLATION) or (FileAge(FileName)<>-1)); end; end; {$ENDIF} {$IFDEF LINUX} begin Result := euidaccess(PChar(FileName), F_OK) = 0; end; {$ENDIF} (extracted from our Enhanced RTL source code) But the version currently included in Delphi 10.3 Rio SysUtils.pas is just as fast on Windows. On POSIX, it uses stats, which is slower than euidaccess().

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.

I just published a blog article about how to write clean code, and also high-performance code. http://blog.synopse.info/post/2018/11/12/EKON-22-Slides-and-Code These were sessions at latest EKON 22 conference in Germany: we were more than 140 Delphi developers! Hope this helps!

When writing libraries you sometimes want to provide users (that is, programmers) with a flexible API. If a specific part of your library can be used in different ways, you may want to provide multiple overloaded methods accepting different combinations of parameters. For example, IOmniPipeline interface from OmniThreadLibrary implements three overloaded Stage functions. function Stage(pipelineStage: TPipelineSimpleStageDelegate; taskConfig: IOmniTaskConfig = nil): IOmniPipeline; overload; function Stage(pipelineStage: TPipelineStageDelegate; taskConfig: IOmniTaskConfig = nil): IOmniPipeline; overload; function Stage(pipelineStage: TPipelineStageDelegateEx; taskConfig: IOmniTaskConfig = nil): IOmniPipeline; overload; Delphi’s own System.Threading is even worse. In class TParallel, for example, there are 32 overloads of the &Forclass function. Thirty two! Not only it is hard to select appropriate function; it is also hard to decode something useful from the code completion tip. Check the image below – can you tell which overloaded version I’m trying to call? Me neither! Because of all that, it is usually good to minimize number of overloaded methods. We can do some work by adding default parameters, but sometimes this doesn’t help. Today I’d like to present an alternative solution – configuration records and operator overloading. To simplify things, I’ll present a mostly made-up problem. You can download it from github. An example type TConnector = class public procedure SetupBridge(const url1, url2: string); overload; procedure SetupBridge(const url1, proto2, host2, path2: string); overload; procedure SetupBridge(const proto1, host1, path1, proto2, host2, path2: string); overload; // procedure SetupBridge(const proto1, host1, path1, url2: string); overload; end; This class expects two URL parameters but allows the user to provide them in different forms – either as a full URL (for example, ‘http://www.thedelphigeek.com/index.html’) or as (protocol, host, path) triplets (for example, ‘http’, ‘www.thedelphigeek.com’, ‘index.html’). Besides the obvious problem of writing – and maintaining – four overloads this code exhibits another problem. We simply cannot provide all four alternatives to the user! The problem lies in the fact that the second and fourth (commented out) overload both contain four string parameters. Delphi doesn’t allow that – and for a good reason! If we could define both at the same time, the compiler would have absolutely no idea which method to call if we write SetupBridge(‘1’, ‘2’, ‘3’, ‘4’). Both versions would be equally valid candidates! So – strike one. We cannot even write the API that we would like to provide. Even worse – the user may get confused and may expect that we did provide the fourth version and they try to use it. Like this: conn := TConnector.Create; try conn.SetupBridge('http://www.thedelphigeek.com/index.html', 'http://bad.horse/'); conn.SetupBridge('http://www.thedelphigeek.com/index.html', 'http', 'bad.horse', ''); conn.SetupBridge('http', 'www.thedelphigeek.com', 'index.html', 'http', 'bad.horse', ''); // this compiles, ouch: conn.SetupBridge('http', 'www.thedelphigeek.com', 'index.html', 'http://bad.horse/'); finally FreeAndNil(conn); end; Although the last call to SetupBridge compiles, it does something that user doesn’t expect. The code calls the second SetupBridge overload and sets url 1 to ‘http’ and url 2 to (‘www.thedelphigeek.com’, ‘index.html’, ‘http://bad.horse/’). Strike two. The output of the program proves that (all ‘1:’ lines should be equal, as should be all ‘2:’ lines): Last but not least – the API is not very good. When we need to pass lots of configuration to a method, it is better to pack the configuration into meaningful units. So – strike three and out. Let’s rewrite the code! A solution Records are good solution for packing configuration into meaningful units. Let’s try and rewrite the API to use record-based configuration. TURL = record end; TConnector2 = class public procedure SetupBridge(const url1, url2: TURL); end; Much better. Just one overload! Still, there’s a problem of putting information inside the TURL record. I could add a bunch of properties and write: url1.Proto := 'http'; url1.Host := 'www.thedelphigeek.com'; url1.Path := 'index.html'; url2.URL := 'http://bad.horse/'; conn2.SetupBridge(url1, url2); Clumsy. I have to declare two variables and type lots of code. No. I could also create two constructors and write: conn2.SetupBridge(TURL.Create('http', 'www.thedelphigeek.com', 'index.html'), TURL.Create('http://bad.horse/')); conn2.SetupBridge(TURL.Create('http://www.thedelphigeek.com/index.html'), TURL.Create('http://bad.horse/')); That looks better, but still – in the second SetupBridge call both TURL.Create calls look completely out of place. Do I have to pull back and rewrite my API like this? TConnector = class public procedure SetupBridge(const url1, url2: string); overload; procedure SetupBridge(const url1: string; const url2: TURL); overload; procedure SetupBridge(const url1, url2: TURL); overload; procedure SetupBridge(const url1: TURL; const url2: string); overload; end; Well, yes, this is a possibility. It solves the problem of supporting all four combinations and it nicely puts related information into one unit. Still, we can do better. Operators to the rescue! I’m quite happy with the Create approach for providing an information triplet. it is the other variant – the one with just a single URL parameter – that I would like to simplify. I would just like to provide a simple string when the URL is in one piece. To support that, we only have to add an Implicit operator which converts a string into a TURL record. (Another one converting TURL into a string is also helpful as it simplifies the use of TURL inside the TConnector class.) Here is full implementation for TURL: TURL = record strict private FUrl: string; public constructor Create(const proto, host, path: string); class operator Implicit(const url: string): TURL; class operator Implicit(const url: TURL): string; end; constructor TURL.Create(const proto, host, path: string); begin FURL := proto + '://' + host + '/' + path; end; class operator TURL.Implicit(const url: string): TURL; begin Result.FURL := url; end; class operator TURL.Implicit(const url: TURL): string; begin Result := url.FURL; end; Simple, isn’t it? The implementation uses the fact that TConnector has no need to access separate URL components. It is quite happy with the concatenated version, created in the TURL.Create. This allows us to provide parameters in a way that is – at least for me – a good compromise. It allows for a (relatively) simple use and the implementation is also (relatively) simple: conn2 := TConnector2.Create; try conn2.SetupBridge('http://www.thedelphigeek.com/index.html', 'http://bad.horse/'); conn2.SetupBridge('http://www.thedelphigeek.com/index.html', TURL.Create('http', 'bad.horse', '')); conn2.SetupBridge(TURL.Create('http', 'www.thedelphigeek.com', 'index.html'), TURL.Create('http', 'bad.horse', '')); // this works as expected: conn2.SetupBridge(TURL.Create('http', 'www.thedelphigeek.com', 'index.html'), 'http://bad.horse/'); finally FreeAndNil(conn2); end; The output from the program shows that everything is OK now:

Create or extend a file named UserTools.proj in %APPDATA%\Embarcadero\BDS\19.0 (for 10.2 Tokyo) with the following code: <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> <PropertyGroup> <DCC_Define>FrameWork_$(FrameworkType);$(DCC_Define)</DCC_Define> </PropertyGroup> </Project> Now you can check for the project framework with {$IFDEF FrameWork_VCL} and {$IFDEF FrameWork_FMX}.

Not sure this fits perfectly in this forum (more of a non-tech let's fight topic, 😉 ) but here it goes. I just blogged about the plans for 10.3 and beyond around ARC in Delphi. See for more info http://blog.marcocantu.com/blog/2018-october-Delphi-ARC-directions.html Honestly interested in feedback, suggestions and ideas. Less in "I told you" comments...

Using that feature in code that also needs to compile in versions before 10.3 makes no sense - however once we migrate to a version that has this feature I will use it in company source code with great joy.

When using the </> button in the text editor, it always defaults to HTML syntax highlighting. Can this be changed to Pascal by default?

I have been waiting for that reply ever since I first used that nick in an other forum back in 2000. 18 years...wow!

If you haven't watched this before it might make it a bit clearer what it means to have modern compiler architecture and what benefits you get from it (like not having to implement everything twice for compiling itself and for tooling):

Thank you, Daniel, for opening the International Delphi-PRAXiS forums for the G+ Delphi Developer refugees! In my opinion, this is the best possible outcome from having to leave G+. We strengthen as a community, and get access to a properly managed, fast, independent, ad-free forum with proper formatting of source code, RSS support, good UI and that actually works well on mobile too! I am a happy coder today!