Leaderboard

The DDevExtensions 2.85 and the DFMCheck 1.6 are now available for Delphi 10.3 Rio. DDevExtensions Changelog Added: Support for Delphi 10.3 Rio Added: Use Unit dialog option “Every unit on a single line” Improved: UnitSelector Dialog in Delphi 2009 opens much faster Fixed: Structure-View search dropdown had a max height of 2 items Downloads

There are still 6 patches collections (about 30 function patches) that I have to reimplement. At least the Win64 compiler doesn't crash anymore. So it will still take a lot of time to get a usable release version.

Please fix IDE bugs! We have new icons Please fix IDE bugs! There is barely working dark theme Please fix IDE bugs!!! Now light IDE theme is broken too. I don't mind UI improvements, but IMO this were the wrong ones. I should probably say - I would not have anything against visual UI changes as long as they work properly. Visual changes are (should be) easier to implement than fixing some deeper IDE issues. But, currently IDE is falling apart left and right. Just because it looks better (depending on how you define better - my eyes cannot stand bluish theme for more than 10 minutes) it does not mean that it works better or is more usable.

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.

Because, in its infinite wisdom, IDE decided you need to brush up your debugging skills 😎

Did you know that you can edit binary files inside the IDE? Just open a binary file in the IDE and you get a simple HEX editor.

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’s time for a gift to all Delphi developers, a new Release of GExperts. Happy Holidays! (But do spend some time with your family rather than testing GExperts. 😉 ) I blogged about the new features already. There were also several bug fixes. ... https://blog.dummzeuch.de/2018/12/22/gexperts-1-3-12-experimental-twm-2018-12-22-released/

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!

Unless you use the external compiler, the compiler runs in the main thread and every time it updates the progress dialog it "pauses" the compilation. IDE Fix Pack reduces the slowdown a little bit by only updating the UI after a certain time interval or a filename change, thus not every "compiled lines" update repaints the UI. There are changes in the 64 bit compiler (e.g. some loop unrolling)

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.

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.

GExperts has recently gained a few new features: Two new experts to start/stop recording and to replay a keyboard macro. These are minimal experts which allow you to add additional keyboard shortcuts to the existing IDE functionality. The idea and the code were contributed by Dejan M. Goto Previous / Next modification Editor Experts. These again ... https://blog.dummzeuch.de/2018/12/15/new-features-in-gexperts/

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

This release addresses problems with disabled IDE themes and Delphi 10.2 Tokyo releases below 10.2.3 (and some smaller bugs): https://www.mmx-delphi.de/2018/12/31/bugfix-release-for-mmx-code-explorer/

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().

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.

Hello, An interesting feature (IMO): add a popup menu item to the source indexer to show a file in a Windows Explorer window (Much like you have in Delphi project manager). Regards,

Hey guys! I wanted to share my matrix library with you basically it contains tons of function for matrix manipulation (add, sub, mult, inverse) and higher order functions (SVD, CCA, PLS and tons more) The library is highly optimized (handoptimized assembler, AVX, SSE, FMA support) and can be multithreaded. Check out the repository on https://github.com/mikerabat/mrmath and check some tiny examples on: http://www.mrsoft.org/home/downloads.html hope you have fun with that ;) kind regards Mike

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: