Anders Melander

Bad idea IMO. Sharing DCUs among projects only leads to problems in my experience. When I do a clean build I want everything built from scratch, with the options I have enabled at that time. I don't want the compiler to link in some old DCUs that were compiled with god knows what options. You don't need to (as I explained) but it's cleaner design to separate design-time code from run-time code.

MadExcept has an option to compile with memory overrun/underrun checks enabled. It makes heap allocation really slow and add a lot of overhead but it's good if you suspect a memory overwrite and have no clue about where the problem originates. I don't know if Eurekalog has something similar.

Waitamoment! You can't make a 64-bit design-time package. The Delphi IDE is 32-bit so design-time packages needs to be 32-bit. Edit: Okay I need pay better attention. I can see you've already figured this out. If you already have all the components registered in the original (design- and run-time) package then why are you even bothering with creating a new package? Are you actually using run-time packages? It sounds more like your project is misconfigured if it needs precompiled dcus (e.g. from compiling a package) in order to compile.

Yes it's normal that it compiles. RegisterComponents is a regular function located in the classes unit and if you couldn't use classes.pas from a run-time package then you couldn't do much at all. You don't necessarily need to have both a run- and design-time package (yes, there are different opinions on that) but if you have decided to split the packages into run- and design-time then I guess you should move the RegisterComponents into separate registration units and place those in the design time package.

Since FQueueLock is instantiated in the TThreadedQueue constructor and destroyed in the destructor my guess would be that you are calling PushItem on a TThreadedQueue instance that has been destroyed - or not yet instantiatred. If you can reproduce in the debugger, try placing a breakpoint on the place where you create the TThreadedQueue and one on the place where you destroy it. This way you should be able to verify that things are called in the order you expect.

RAM disks... Didn't we stop using those along with DOS and Windows 95? Of course a dedicated physical RAM disk device will always be faster than an SSD but if you're allocating main system memory for use as a virtual RAM disk device then I think it would be better to let the OS manage the memory. It will use the memory to cache files when the memory isn't needed elsewhere.

Not even the part that's wrong?

And there's a lesson in that.

That doesn't answer the question. The overall category is "Delphi" and the Q doesn't have anything to do with Delphi. You have a better chance of getting a usable answer to stuff like this on stackoverflow.

What does this have to do with Delphi?

I thought you said that you didn't read books... 🙂

As Davis said it really depends on the level of security you need. Since the users will presumably have unlimited access to the client binaries the best you can hope for is security through obscurity. Once you accept that your choice depends on the value (to the user) of the assets you are trying to protect. You just need to make circumventing your protection sufficiently costly (in time) for the user that they won't bother. Since I don't know any of those metrics I can't really recommend a solution. Yes. Everyone can setup a domain controller and name is anything they want.

It's not secure at all. Nothing prevents someone from setting up a local PC, or even a VM, with the same config as one on your domain.

My build server runs all builds in parallel. I don't do it locally as I don't need to build more than one project at a time there.

So don't use shared dcu output folders. You shouldn't be doing that anyway.

Build them in parallel.

It's obvious that you, at some point in your pipeline, have the bitmaps in a TBitmap, but it's not obvious if this is actually necessary. If you don't have a requirement that the bitmaps need to be represented as a TBitmap then you can avoid the whole GDI overhead by simply loading the bitmaps as a memory stream and accessing the pixel data directly in memory. BMP is a fairly simple and well defined format so it's not that hard. You can also use something like Graphics32 to do this for you since this seems to be about 32-bit bitmaps exclusively.

Your TRGB32 type is identical to TRGBQuad. Why have you declared the TRGB32Array array packed? It serves no purpose. Why do you use TWICImage but also explicitly reference the Jpeg unit? One thing that I don't think you've mentioned, or at least I can't remember, is if you actually need to use TBitmap at all. Where does your bitmap data originate? A disk file, a stream, something else?

Yes but it's a nasty mess. Better than nothing I guess.

To use alpha transparency you need to set Transparent=False. Here's what it looks like (Delphi 10.3):

If you're using Delphi 7 then you will have to use 3rd party components. For example Graphics32 - and better hurry because I plan to drop support for Delphi 7 in Graphics32 the first chance I get.

Works fine for me. Here's a form with two TImage controls, one overlapping the other. The top one contains a 32-bit bitmap with alpha, the bottom a PNG. I have set Image1.Transpartent=False and Image1.Picture.Bitmap.AlphaFormat=afDefined (at run-time) for the bitmap.

I solve most of my problems in the shower. Eureka!

Yes, they're designed to be nested. I have no idea about why it doesn't work though. Maybe TCanvas gets confused when the HDC is modified outside its control.

In newer versions of Delphi there's an project option "Output resource string .drc file" but I don't believe that it's there in Delphi 5. Since Delphi 5 was the first version to include the ITE and the ITE uses DRC files it must be possible somehow. I have the Delphi 5 files on my system but I'm afraid I don't have it installed so I can't run it to find out. Maybe try to compile with the "detailed map file" linker option enabled and see if that makes a difference.