Lars Fosdal

@Anders Melander: I may have been tooting the MS party line on MDI, without having read an actual deprecation statement, https://docs.microsoft.com/en-us/windows/win32/winmsg/multiple-document-interface "[Many new and intermediate users find it difficult to learn to use MDI applications. Therefore, you should consider other models for your user interface. However, you can use MDI for applications which do not easily fit into an existing model.]" However, this thread by Joel Spolsky from 2002 (!) accentuates how long ago MS started pushing that party line... https://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixpost=2748 Basic functionality seems to be there, even with Per Monitor V2 - but I only gave it a cursory glance. I think I was on 1809 the last time I checked and at the time it was definitively borked. Currently on 1909.

The last time I checked, I got transparent client areas and border areas.

MDI has been deprecated for years and is severely broken under Windows 10. Seems that a lot of messages no longer are sent or passed down to children.

Does the DLL itself try to load a second DLL which cannot be found or is the wrong bit-ness?

Do you get error 193 in your 64-bit application? Is the DLL 64-bit?

Unless you need multi-pass processing, or you have logic for conditional processing further down.

I'd go for the C# approach instead of fiddling with an ancient Delphi.

Absolutely. The Law of Demeter is something I usually follow quite strictly. However, in the above example - Session.Progress.Truck.Required ( & alike), Session has already been validated and Progress is an object where all the fields are always populated. I actually did make this structure instead of having a buttload of local variables. I have to figure out if a value has been given, and if it is given, it is valid, and if not - if it is a required value, and so forth, and some login types may need only some of the parameters.

A "modern" way of handing conditions is to do early exit on condition fail. In the above case it is pointless, but for more complex sequences it can make sense. Here is an example from a piece of JsonRPC handling code I wrote. In this case I don't do exits - since there is stuff that happens after the validation. Imagine this code if I had used nested if/then... // Handle login progress errors if Result and Session.Progress.Device.Required then begin if Session.Progress.Device.FailAsError then Response.SetError(Session.Progress.Device); Response.SetHint(Session.Progress.Device.Message); Response.SelectNextStep(S01_Login); Result := False; end; if Result and Session.Progress.User.Required then begin if Session.Progress.User.FailAsError then Response.SetError(Session.Progress.User); Response.SetHint(Session.Progress.User.Message); Response.SelectNextStep(S02_SelectUser); Result := False; end; if Result and Session.Progress.Mission.Required then begin if Session.Progress.Mission.FailAsError then Response.SetError(Session.Progress.Mission); Response.SetHint(Session.Progress.Mission.Message); Response.SelectNextStep(S03_SelectMission); Result := False; end; if Result and Session.Progress.Truck.Required then begin if Session.Progress.Truck.FailAsError then Response.SetError(Session.Progress.Truck); Response.SetHint(Session.Progress.Truck.Message); Response.SelectNextStep(TPGStep.S04_SelectVehicle); Result := False; end; if Result and Session.Progress.Area.Required then begin if Session.Progress.Area.FailAsError then Response.SetError(Session.Progress.Area); Response.SetHint(Session.Progress.Area.Message); Response.SelectNextStep(TPGStep.S05_SelectArea); Result := False; end;

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.