Uwe Raabe

That may depend on the actual case. The Windows scaling is fine as long as you have images that look ok when enlarged significantly. Usually you have not. Also CAD like applications are not so good candidates.

You might be forced to reconsider this statement when your customers are more and more using high dpi configurations and criticize the visual quality of your application. While the IDE ist still not ready for prime time in 10.3.3, most of the applications can be tweaked to behave well in these situations. The upcoming 10.4 may be right better with that. Laying out this transition now may give you some advantage when demands are rising and management expects a quick fix (No, problem. You can have your Delphi update, but we have to deliver next week!).

Due to the sluggish behavior of the themed IDE in some of the later versions I decided to buy a new PC. It turned out that the overall power consumption of the new PC is lower than that of the previous one even with a significantly better performance.

Experience shows that this usually never happens - and if, it will not happen in the expected time frame, cost and functionality. The first barrier is usually the lack of documentation what the Delphi software does, how it does it and why it does it that way. I personally have seen a couple of such endeavors going down the drain. They could as well have burned the money in the first place.

Unfortunately the problem is still present. The good thing is, that I now have the environment to investigate it. May take some time though...

Interestingly that was my first thought, too. Unfortunately I couldn't find any directory implementation described there.

I finally got hit by the problem myself and did some deeper investigation. It turned out that the freeze happens when System.pas was parsed in the background. It contains some constructs with conditional defines that are not handled well by the internal parser. Adding System to the list of excluded files avoids that. Then I made a complete scan over the available Delphi source files (at least those present on my development machine - alas, some platforms are missing) and found two other source files with the same problem: IdThreadSafe.pas and IdGlobal.pas. It would be great if those people affected by this problem can test this workaround and add System, IdGlobal and IdThreadSafe to the Excluded list.

It is still part of RAD Studio in Enterprise and Architect editions, but not in Community and Professional editions. Unfortunately there is no Add-On available anymore to extend a Professional edition. The only way is to upgrade to the Enterprise edition.

Just a note to your article TStringList vs. THashedStringList vs. TDictionary: In Delphi 10.3.3 THashedStringLIst is not used to speed up TMemInifile anymore. AFAIK it is not used anywhere in the standard libraries and probably only there to stay compatible. Btw, I agree that it is poorly implemented.

The error message is misleading. It doesn't mean that the module CodeSiteLoggingPkg_Design260.bpl cannot be found, but rather another module required by the design module cannot be found. Most likely that will be the corresponding runtime package. The tip given by David should fix that.

That can fire back in some cases where the inherited constructor calls a virtual method that is overridden in TMyClass and relies on the existence of FSomeInstance. In that case it is required to assign it before calling inherited Create. This also holds true if FSomething is going to be created in TMyClass.Create. One has to inspect that carefully for each case. More than once I have been bitten by that when I introduced an override method.

The Delphi IDE stores the currently open files when this is activated in the IDE option settings (auto save - project desktop). If you see files closed in a previous session that option is most likely disabled and the last saved project desktop (<projectname>.dsk) is loaded.

If the TMyClass.Destroy is even called when an exception is raised inside TMyClass.Create, you could as well assign FSomeInstance before calling inherited Create. That should make sure that FSomething is freed inside TMyClass.Destroy in all cases. That would make the outer try-finally obsolete. Or are there situations where TMyClass.Destroy is not called?

How can you be sure?

Yes, but it comes with the Delphi installation and thus doesn't need to be maintained externally. I also have customers avoiding additional libraries. Each new one has to be justified to someone, which often turns out to be a tedious process. Not everyone has the power to decide on its own.

Quoted from Webinar Replay: Simplify Data Change Tracking with InterBase

AFAIK, that has been true for Windows 95. According to the WinApi SetTimer function, which is internally used by a VCL TTimer, the minimum value for Interval is 10 ms:

Same here. That's why MMX development is actually stalled - unfortunately. Otherwise the beta version would have long been finished.

Regarding compiler directives you can give the above sources a try. Although there might still be cases where it fails, they should do a better job than the official MMX version does.

Yes, there is always room for improvement.

The code used in MMX Code Explorer is almost identical to what I attached above. The command line application allows targeting multiple units in one go, while as you noticed MMX only works on the uses clause the cursor is positioned in the current unit.

I have written a tool including that functionality some time ago. Although I didn't find the time to polish it up before going public, it basically does what it is supposed to. Expanding unit scope names is only part of the whole process, which consists of resolve all unit aliases expand unit scope names group units compress uses clause Taking your example above it will convert uses sysutils, stdctrls; into uses System.SysUtils, Vcl.StdCtrls; Feel free to adjust the sources to your needs. UsesCleanerSource.zip

It is probably related to this code in System.Classes.ThreadProc: try Thread.Execute; except Thread.FFatalException := AcquireExceptionObject; end; You should be able to get any exception in the threads OnTerminate handler reading its FatalException property. See also http://docwiki.embarcadero.com/Libraries/Rio/en/System.Classes.TThread.FatalException

Indeed! You would write it this way: begin ... begin // do something with ref and thing var ref := Some.Array[Index1].Reference; var thing := Function(Index1).Thing if ref.Value <> thing.Value then begin ... end; end; // ref and thing are not present ... end;

The filter "Reported by me" yields different results for everyone - obviously.