Uwe Raabe

AFAIK, the plan was to make Refactoring opt-in, but it came with other regressions when not installed. So they finally made it opt-out. Anyway. It is commonly known since ages that any 0-release is not made for production. Let's wait for the first hotfix - at least.

It is deprecated because it is broken beyond repair. Better stop using it.

It is broken as it makes one assume the report is not created while actually it is. This leads to multiple duplicates, but filing a report is still possible. Just make sure to check for existence after creation before trying again to avoid these duplicates.

They found - what everyone else claimed for a long time - that it didn't keep up with the latest language enhancements. As it is based on other deprecated parts (i.e. Refactoring), they consequently marked it deprecated, too. Now they are working on or looking for replacements. Communicating that something is deprecated without having an alternative at hand is not necessarily a bad thing. People now know it advance what they can expect and rely on and what not.

It seems that the most effective incentive to use CE is: It's free.

Because a CE license is valid for one year only. After that you have to request a new CE license which will only work with the current CE version.

Not sure it is related, but there is a very inconsistent use of slash and backslash in the $env values.

Actually that looks like a reason to keep the current behavior instead of implementing the proposed one:

It would have the drawback that packages are loaded and unloaded again when the same project (or another with the same package requirements) is opened next. So the current implementation may just be some sort of performance optimization. IMHO, it is sufficient when there are no packages missing after the next project is loaded or a new one created. Can you explain what practical benefits the requested behavior would have?

I would split removing the bracketed strings and removing double blanks in separate methods. I am assuming the strings are well-formed here, which means that each opening bracket matches a closing bracket, no orphaned brackets and no nesting. Otherwise use one of the other algorithms shown above. function RemoveInBrackets(const AString: string): string; begin var arr := AString.Split(['(', ')']); for var I := High(arr) downto 0 do begin if Odd(I) then Delete(arr, I, 1); end; Result := string.Join('', arr); end; function RemoveDoubleBlanks(const AString: string): string; begin Result := string.Join(' ', AString.Split([' '], TStringSplitOptions.ExcludeEmpty)); end;

If the drawing code is too time consuming for being called in OnPaint, you might consider drawing to a bitmap when something changed and draw that bitmap in OnPaint.

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?