Lars Fosdal

I thought this was a new problem... then I tried on the old laptop again. Guess what - it fails in the same way there as well.

The size of the project does not seem relevant. The one that fails is about 600k lines. The tiny ones works just fine, as does the larger 1100k lines one.

Line endings was wrong at first (Thanks for nothing, GitHub) - but was corrected with a setting in GitKraken. The compiler warns if there if f.x. only LF instead of CRLF - but how to guard against a lonely CR?

I can't make sense of that statement.

Opened another, larger project. 1.1+ million lines. No problems. Debugs fine. Didn't even touch the .dproj.

Switched to Release, builded, exited Delphi. Restarted Delphi, switched to Debug, builded, ran - no change. No weird characters. Opens fine in TextPad, Notepad, VS Code and IDE.

See previous posts. Files are in UTF-8 format with BOM.

Fresh checkout from Git. Compiler does not complain. Program executes fine. It just that it doesn't appear to be in debug mode.

Another app, same problem - except this time, deleting the .dproj did not solve the problem. WTF is going on?

The downside of deleting the .dproj file. Output path, search path, dcu output path, and EurekaLog needs to be reconfigured. Oh, such joy.

The plot thickens: I deleted the .dproj for a specific app. Debugging worked. I opened a project group- containing the same app. Debugging stopped working. Guess I need to rebuild that too. Strike that. I ran the wrong project ><

Deleting the .dproj did solve the problem. I compared the newly created to the old one, and there was a huge amount of crap in the old one. But, why does it work on the old installation?

Yes - started a new project. Same problem. No! I closed all projects, then tried again with a brand new project. That worked.

Yes - clean machine - clean install - no previous Delphis - and the .dproj files came from a repository also maintained with Delphi 11.1.

Word of the year in Norway: "Krympflasjon" - i.e. "Shrinkflation". A general principle where the price stays the same, but what you get for that price is less. Example: A pack of ham at 150g / $3 becomes a 120g / $3 pack. It is of course the same as inflated prices, but the businesses are trying to hide the fact. Food is more expensive, but not as bad as those US examples. Gas is up, but down from the top this spring. Electricity is ridiculously expensive, thanks to a silly guy with a stupid invasion plan further east. However - on the bright side - we need more IT people! Unfortunately, Delphi is not the most sought-after experience. But still - there are a many jobs available in IT here in Norway.

Even simple solutions can lead to complex problems.

Also - a 32-bit application cannot use more than about 2 GB of memory, regardless of the amount of RAM in the machine. Yes, there is a trick to extend that to about 3 GB - but that is only a temporary reprieve. Another memory saving trick would be to scale images to the appropriate size and quality before storing them. If you have a 12 Megapixel image that never will render bigger than 1024 x 768 - it should be scaled and compressed before storing it.

The format of the data and how they live in the application decides the memory consumption. Think about web content. Huge amounts of graphics and video in a 32-bit browser 32-bit OS, even with as little as 2Gb of memory. How does it do that? Load on demand and using temporary storage outside the browser such as file cache or direct streams. If we load a block of data from a DB - and that data has to be loaded into a stream - and then fed into an editor - we are using that memory at least three times, maybe four - depending on how the control stores the data. Divide and conquer. Instead of one blob - use a separate table to hold individual images. Explore if there are ways to load the image data on demand instead of embedding them in the control.

You have a problem. You apply RegEx to solve the problem. You now have two problems.

I read / comment here whenever I have a few minutes to spare, but I can't commit to answer personal messages for support. I prefer to do the communication here, as other may (or may not) chip in - since that is what a community is for.

I suspect it has to do with how the images are loaded into the TAdvRichEdit. Have you looked at TPictureContainer / THTMLPictureContainer that can be used to supply images to the editor?

Can you exclude the field(s) that holds the big chunk image data from the search view - and instead, when a single search item is focused - load just that field alone on demand?

The point of identity fields is to be able to do table joins without relying on unique keys in your data. You can still have other unique keys - f.x. for books, it could be the ISBN, for warehouse articles it could be the EAN code, for shipping containers it could be SSCC. All of these are supposed to be unique - but they are strings, and hence far more expensive with regards to space and computation. And - at times, those unique IDs might not be available at the time of insertion (example of unique field that allows for multiple rows with field = null). As I mentioned - the point of the identity field is to be able to create relations without involving the actual data. The value will not change for the lifetime of the row(s), even if you later change all the actual data for that record - including other columns that must be unique.

I am not sure if I understand your question?