Anders Melander

Stack tracing is very expensive and not all exceptions are errors.

Don't. You aren't improving anything by abbreviating control names.

It sounds to me like you have a quality problem if you have that many exceptions. In the applications that I work on (users in the hundreds), every single exception that are caught by the outer exception handler (madExcept in our case) is treated as a must-fix bug. On the average I would say we get one or two a month if we've been sloppy with the QA. The madExcept bug reports are usually either mailed to us by the madExcept UI, or retrieved from the customer's system by our supporters, and attached to a JIRA issue. It is extremely rare that we need to compare call stacks to detect a duplicate. AFAIK madExcept can do so automatically via a hash or something but we've never used that feature. So the only advice I can offer is: fix your bugs before release 😉

Useless.

That's assignments. OP is asking for a type declaration.

Yes, that's correct; There no need. But I don't see a problem with saving a direct reference somewhere else, for convenience, performance, or readability. In Delphi, I would do something like this: // Create layer var Layer := Image.Layers.Add<TBitmapLayer>; // Set initial layerproperties Layer.Scaled := True; Layer.Bitmap.LoadFromFile('foo.png'); ... or interface type TMyForm = class(TForm) private FBitmapLayer: TBitmapLayer; ... public constructor Create(AOwner: TComponent); override; end; implementation constructor TMyForm.Create(AOwner: TComponent); begin inherited; FBitmapLayer := Image.Layers.Add<TBitmapLayer>; FBitmapLayer.Scaled := True; end; procedure TMyForm.SomeMethod; begin FBitmapLayer.Bitmap.LoadFromFile('foo.png'); ... end;

Having two list think they "own" the same object would be a very bad idea; The layers are already owned and managed by a layer collection.

My debugger requires DevExpress but DWScript itself has no external dependencies. I chose to use DevExpress mainly because I wanted a docked layout and from prior experience I know that the VCL's docking suuuucks. It should be possible to replace it with something else, if one wanted to. I also have a DWScript RTL that uses DevExpress controls for the GUI stuff but you don't need to use my RTL; DWScript comes with its own non-UI RTL that covers the basic stuff. Actually, AFAIK, I'm the only one doing UI with DWScript. At least I haven't seen anyone else do it. Yes.

I have used DWScript as a scripting system in several products. Used either to provide business rules (no UI, just logic) or as a app/plugin (with UI). The OP language support and performance is excellent. The learning curve is extremely high (no documentation, few examples). Here's an IDE/debugger I wrote for it: DWScriptStudio FWIW, https://www.beginend.net is powered by DWScript.

It's been like that since Delphi 2. Why do you need to open a form in Delphi 11 that has been saved with Delphi 12? Regardless of this problem, you should always "be careful what you commit"; Review your changes and cherry pick the ones that are relevant so the important changes aren't drowned out by the noise.

Order incoming... Now we just need to get the EV-vetting process completed.

It also tells which layer produced the error. For example, was it the DB server, the DB client library, or FireDAC itself. It's technical info that provides important context to the developer/supporter. It's not meant to be presented to the user.

Sure, that'd work. Not a small task though.

It is. There is zero benefit in memory mapping a bitmap file. None. Zip.

You haven't thought this through. Try it - at least on paper.

There's no point in sizing the bitmap just before you load something into it. Instead of loading into a TBitmap and then copying that into TImage, load directly into the destination bitmap. but this isn't the cause of you problems. Your source images are compressed PNGs. Once they are loaded into a TBitmap they have been decompressed so they will use a lot more memory that what their size is on disk. The images probably also have a resolution higher that what you can display. So instead of displaying the image in their original size/resolution, resize (resample is the correct term) them on load to fit the destination viewport. Keep the resized bitmap in memory and discard the original (from memory that is. You still have it wherever you loaded it from). So you are basically displaying thumbnails of the original images.

Unless you actually know how to do this I don't think you should offer it as a possible solution. Assuming the image file is uncompressed, you would need to at least load the header. Then you would need to locate and load the partial image rows and then you would need to reassemble this into something that can be processed as a bitmap and then that would need to be scaled to fit the viewport. I doubt this would improve the performance. If the image is compressed then it will have to be decompressed into memory before it can be displayed. The RAM has already been allocated; Game over. Is that a serious question? Google Maps, and other GIS systems, display tiles because that is how their data is organized. As far as I can tell we are not dealing with tiled image data in this case. Anyway, back to memory mapping; If anything, using memory mapped files would increase the RAM usage, so I still fail to see how that would improve the situation.

Why would making an image file memory mapped reduce RAM usage? Do you understand what mapping a file into memory does?

Sure, you can if you want to. The layer will remove itself from the layer collection when it's destroyed so the layer will not be destroyed twice.

This isn't necessary in this particular case; The TImage32 owns the layers and will automatically destroy them.

...and FWIW your old SuperLemmix repo on BitBucket appears to be gone. Now I only see the NeoLemmix repo.

I can't follow your description above and I can't make it match with what I see on your repos. I suggest you: Ditch BitBucket - it sucks. Use your repo on github instead. Ditch SourceTree - see above. Install Fork. If you tell me what the source and target branches are I can tell you how to do it.

Well, that would certainly explain the symptoms we're seeing.

Are you saying that you get an exception when compiling the code? I think you mean when running the code. Going back and looking at your screenshots, I can see that the exception probably occurs in some paint code. That's why you get the cascading errors. A repaint causes an error which triggers a new repaint which causes an error, etc. etc. If you can reduce the project to the smallest possible case that reproduces the problem and post the code in a zip file, then maybe some of those here that actually use C++ (I don't) can have a go at it. For example, if you remove all the 3rd party stuff (including Graphics32), can you still reproduce the problem? No.

...or the slightly less hacky method: EnumDynamicTimeZoneInformation and friends.