Lars Fosdal

If the same logic is used in multiple places, that shouts for generalization. function UserCanDeleteDocument(const aUser: TUser; const aDoc: TDoc): boolean; begin // can delete if Result := (aUser.Username = aDoc.Owner) // aUser owns ADoc or aUser.Administrator // or aUser has admin rights end; begin if UserCanDeleteDocument(aUser, aDoc) then begin // do the deletion end else ShowMessage('You are not allowed to delete this document'); end;

My argument comes from the goal of reducing code clutter and sanitizing conditions to be easy to read. Original code if aUser.Username<>aDocument.Owner then begin // If user is not an administrator if aUser.Administrator=false then begin showmessage('You are not allowed to delete this document'); exit; end; end; A boolean is by definition either true or false. An if condition takes a boolean argument, and if the argument is true, the following statement is executed. I don't need to check if BoolVar = true or BoolVar = false - only checking BoolVar or not BoolVar is enough. To have readable code, avoiding negations is a good thing, hence I would probably write the above something like this if (aUser.Username = aDocument.Owner) or aUser.Administrator then begin // do the deletion end else ShowMessage('You are not allowed to delete this document'); Naturally, there is no single right way of doing conditions - but explicitly comparing a boolean variable to a boolean value is unnecessary.

I have to admit that I cringe whenever I see a boolean compared to true or false.

Does the behavior change if you write If not aUser.Administrator then?

We are still on the TMS Component Pack 9.0.3, but not using any of the data-aware components.

Anyways - this is just guesswork. You'll have to turn every stone to solve this.

In case you have home-grown components, I assume you have done basic leak checking on those. Not freeing stuff after use can quickly escalate memory usage for database objects. Learned that the hard way.

Using Process Hacker can give some insight into which modules are loaded and what kind of allocations are done. .

Does any of the forms open potentially really large amounts of data?

Well, the point here is not disabling RAD as such - but to try to determine where the memory goes. That said - I stopped doing RAD years ago and swear by setting things up in code. Got fed up with lost property values and event handlers after code merge blunders.

Is it mission impossible to disable the data links on forms when not working on them? It would probably mean that you need to add code to activate the connectivity at run-time.

Are there a lot of forms that have design-time data connections?

When BDS reaches 1.5Gb - you are usually in an out-of-memory situation, and BDS will behave erratically or most likely not at all. The question then is - what is eating your memory? Are you building multiple projects in a project group?

Are there any files in your projects that are on a network drive?

https://docs.microsoft.com/en-us/cpp/build/reference/utf-8-set-source-and-executable-character-sets-to-utf-8?view=vs-2019

This could use a QP to expose it in the regular Options dialogs.

What about setting Owner/Parent of the children to nil? (I am just throwing pasta at the wall here now)

One alternative could be to have an permanently invisible main form, so that the perceived mainform also is a child?

I am trying to remember if I've seen this done in any app before, but I am coming up short? What happens to child windows if main window is set invisible, I wonder?

Have anyone done an article on the current pitfalls of inline variables?

The point of making a second class was to enable one of the features that Mike was looking for, i.e. hiding implementation details. The single set field was a single property of the single example Mike initially gave. He later pointed out there are at least four different methods of operation, even adding three-way comparison/merges, meaning you need a third file parameter. You can put these classes in separate units and have a factory method or class that instantiate the specific inner classes, and completely isolate the inner workings from the outer use, offering f.x. two compare methods. function Compare(const aFileName1, aFileName2: string; const aMerge: Boolean = False):TResultType; overload; function Compare(const aFileName1, aFileName2, aFileName3: string; const aMerge: Boolean = False):TResultType; overload; Again, just a simple example based on the limited insight into all the possible variations of parameterization. There is more than one way to solve such a challenge. I chose to use polymorphism and encapsulation.

Please elaborate. How is it worse? How would you solve it?

I like streamable objects. That makes it impractical with params to the constructor. Hence, I try to avoid them.

Having arguments to the constructor is something I try to avoid. TINIComparer = class private fINIFileName1: string; fINIFileName2: string; protected procedure LoadINIFiles; procedure CompareINIFiles; virtual; public constructor Create; virtual; procedure Compare(const aINIFileName1, aINIFileName2: string); end; TIniComparer2Way = Class(TIniComparer) protected procedure CompareINIFiles; override; // if necessary public constructor Create; override; end; constructor TINIComparer.Create; begin Inherited; end; constructor TINIComparer.Compare(const aINIFileName1, aINIFileName2: string); begin fINIFileName1 := aINIFileName1; fINIFileName2 := aINIFileName2; LoadINIFiles; CompareINIFiles; end; constructor TINIComparer2Way.Create; begin Inherited; fCompareType := cmt2WayCompare; end; // from main form: fINIComparer := TINIComparer2Way.Create; fIniComparer.Compare(edtINIFilename1.Text, edtINIFilename2.Text)

There are various ClearXxx methods for TFDMemTable, but it is not obvious which one(s) to call, or in which order, and if they actually reset the whole thing. The above suggestions, on the other hand, are solid.