Uwe Raabe

You need to give way more information about your components and their properties. F.i. setting Direct in a TFDBatchMoveDataSetWriter will probably not call Append and thus OnNewRecord is not called. Also using an TFDBatchMoveSQLWriter will not call OnNewRecord either.

If the source table doesn't provide a value for that column, you need to do that yourself, which implies that you know which value has to be written to that field. Depending on your batch move architecture, that might be done in OnNewRecord of the target dataset or OnWriteRecord of TBatchMove.

It could be even shorter: Result := MyStr.Remove(MyStr.IndexOf('<')).Trim; No need to check for existence as the internally called _UStrDelete already handles that case pretty well.

It is a long time flaw in the TMS package naming to neglect the LIBSUFFIX approach, which ever so often leads to such problems. That's why I have made my own packages using LIBSUFFIX in conjunction with a manual install process. It comes with the task to synchronize the DPR files contains clause for each update - a small price I am happy to pay.

Better or not often is a matter of preference and personal needs. I for myself already gave a hint before: The availability of a stand alone and command line tool are a big plus for me. Side note: I have licenses for and actually worked with both, which helps to make a less biased comparison.

Saving the form will add an entry to the history, which can be reverted to later.

My last comparison was a few years ago. At that time they were almost on par. Personally I prefer Pascal Expert, but mostly because it works similar to its companion Pascal Analyzer, which also provides a command line tool usable for build integration.

Indeed, compared to the history for Peganza Pascal Expert it looks a little bit behind.

If all else fails - plug it in.

IMHO, last month doesn't really qualify for no activity. It is side project for someone with a full-time job at last.

In MMX properties - Pascal - Sorting - Format unit uses clauses make sure that Group and sort uses is checked.

As that is a very personal preference, a similar feature is implemented on personal request in UsesCleaner branch FlixEngineering. It is available in the public repository for all those having individual formatting requests. Note that MMX will most likely not contain these for the near future.

Better remove the trailing dots in Frame and Form. Plain group names get that automatically appended when looking for a match. F.i. a simple entry like Form matches unit names Form, Form.Tools and Form.Test, but not FormTest. Assuming that the x stands for the obfuscated parts in your screenshot, I get the following results with this Groups: Winapi System.Win System Vcl Data FireDAC cx DM x x.Tools Frame Form uses System.Classes, System.SysUtils, System.Variants, System.Generics.Collections, System.Generics.Defaults, System.DateUtils, System.Math, System.StrUtils, Vcl.Imaging.pngimage, Data.DB, FireDAC.Stan.Param, FireDAC.Stan.Option, FireDAC.Comp.Client, FireDAC.Comp.Script, x.Classes.Common, x.Classes.Base, x.Classes.Data, x.Constants, x.Types, x.Database.Common, x.Preferences, x.Tools.Mapping, x.Tools.DateTime, x.Tools.TryFinally, x.Tools.Json, x.Tools.Regex, x.Tools.IO, x.Tools.BitMask, DataModuleTextConstants;

And for completeness: What are the defined groups?

That's default.

Not yet. It is. All units not matching a group are placed after the grouped units.

Brackets denote a list of unit names forming a group. I use it f.i. for keeping the ToolsApi units together: (ToolsApi,DesignIntf,DCCStrs,DockForm,TabDock) The example shows a glitch in the TMS unit naming: Adv* followed by (BaseGrid) keeps the TMS Grids unit together. The other example (ZipForge) is used when a group consists of a single unit name only. Omitting the brackets would take it as a unit scope name instead.

With Premium you get early beta access, while an active subscription entitles you to participate in the public beta. In most cases the latter should be sufficient.

Unfortunately not - and it would be quite difficult to implement that with reasonable effort. Wildcards are handled by TMask.Matches and that has a hardcoded Upcase in its implementation.

I didn't try it.

Now it is.

The Migration Tool has a special mode for migrating to a newer version, which requires to select the appropriate settings. Did you follow these when migrating? If yes and it didn't work, you should file a bug report.

This is fixed in Delphi 12.

Unfortunately that is by design as comments in uses clauses are considered not clean. Background: It is pretty hard to connect the comment to one of the used units - there is too much convention involved with this. Also, line end comments don't play well with grouping and line wrapping. There are non plans to change this any time soon.

Can you reproduce on a minimal project? I just copied that uses clause into a fresh VCL project and everything works as expected.