Anders Melander

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.

Sounds like a good plan. But please use version numbers instead of marketing names. I have no idea what versions Athens or Alexandria refers to - nor do I care to know.

And did you replace all the Form1-> with this-> ?

Sure but the fact that it's only available via WinRT sort of confirms that it isn't, doesn't it?

Again: Not a part of the clipboard system; A layer on top of it. It is not a single global history that is managed somewhere. It is just individual services that maintain their own history. So not "the clipboard" history but "a clipboard" history.

"as short as possible" is not a usable specification. The shortest possible key is zero characters long. The longer the key, the fewer key collisions. You need to specify the exact length you want your key to be. Also, are you really sure that you want to hex encode the key? With hex encoding you are wasting half the bits by using 8 bits (i.e. an ansichar) to represent a 4 bit value (i.e. a hex digit). A more efficient encoding would be something like Base32 (5 bits per byte) or Base64 (6 bits per byte). I believe Delphi has implementations of both. Search the source (or wait for someone here to write what they are, as I'm sure they will do).

I think I can see the problem: You are referencing the Form1 global variable before it has been assigned a value; Your code is in the constructor (or more precisely: an event handler called from the constructor) and the Form1 value isn't assigned until the constructor returns. Do like this instead: void __fastcall TForm1::FormCreate(TObject *Sender) { ... for(j = 0; j < c; j++) { pLayer[j] = new TBitmapLayer(this->ImageBackground->Layers); pLayer[j]->Bitmap->DrawMode = dmBlend; pLayer[j]->Scaled=true; } ... } or simply: void __fastcall TForm1::FormCreate(TObject *Sender) { ... for(j = 0; j < c; j++) { pLayer[j] = new TBitmapLayer(ImageBackground->Layers); pLayer[j]->Bitmap->DrawMode = dmBlend; pLayer[j]->Scaled=true; } ... } Of course it would be best if you could avoid all those global variables (not Form1 but all the others). I don't know if they were just there for debugging this problem.

On my system (Windows 10) the history only contains data copied after first Win+V. Win+V starts the "Clipboard User Service" (svchost.exe -k ClipboardSvcGroup -p). The service is set to manual start. Maybe it's set to auto start on your system? Anyway, the history is not part of the clipboard system. It's just an application on top of it, no different from one that you could write yourself. Trying to access the clipboard history data when there is no public API is IMO a waste of time when you can just replicate what it does. It's not that hard.

AFAIK there's no such thing in Windows as a clipboard history. Applications, and libraries (.NET, UWP, etc.), that offer a clipboard history does so by monitoring the clipboard and making local copies of the content when stuff is copied onto the clipboard. This is why Windows' own clipboard history (WinKey+V) is always empty when you first invoke it. It needs to run in the background before it can collect data from the clipboard; Windows itself doesn't maintain a history. This is also why it is very limited what data is stored in the clipboard history; The clipboard history application doesn't support a lot of formats (mostly text and bitmaps) and some data is only valid at the time when they were copied and require that the data source is live when the data is pasted. You can use the drop target analyzer application from the Drag and Drop Component Suite to see the impact, in terms of requests made to the data source, of running the Windows clipboard history in the background. The drop source analyzer can be used to examine the difference between data copied directly from the clipboard and data that has been through the clipboard history.

I would just use F8 (Step over) but it shouldn't make a difference. Where do you assign a value to c and where is pLayer (which I assume is a dynamic array) initialized? I think you need to show us some more code so we can make sense of what you are doing - and please use the code block.

Seems reasonable; I'll go ahead with that. Even if it ends up a bit higher I wouldn't see a problem with that (for us anyway) but don't let that influence you 🙂 Thanks. Which is also the only reason we need it. Well, to be perfectly honest, although FUDscreen is annoying, I suppose it does guard against the binaries getting tampered with (e.g. infected) after install. They could have solved that another way though but we all gotta have something to do. Who said you can't survive on cutting each others hair (is that even a saying in English?). You misspelled TBD, if that was what it was supposed to say.

Well, aren't I the lucky one? I've just been tasked with finding a code signing solution for our build pipeline. So far the realistic candidates are: Use Bob's test-server PC in the closet and do it manually (Bob's not too thrilled). Use the certificate providers cloud solution and pay per transaction (not gonna happen). Some clever tool that seems to be designed just for our needs. So do you have any idea about what the price will be on this thing?