Anders Melander

Yes. What's your point?

Every Delphi application that contains a form (or frame or datamodule) does it. That's how components and controls gets created when the form is streamed in from the DFM resource. See TReader.GetFieldClass and TReader.ReadComponent

I've just skimmed through that and it seems to me that your suggestion to use THandleStream is incorrect; I don't believe FileRead can be used on a resource handle. Apart from that I would advise against on-the-fly runtime change of resource module. There are simply too many things that doesn't work with it and the users doesn't really care about it either.

Well, the answer to his question is "yes" but since we don't really know what problem he's trying to solve it's hard to tell... 🙂

You don't need a plugin to receive items dragged from outlook. You just need to handle the correct clipboard format and any decent drag/drop library can do that for you. https://github.com/landrix/The-Drag-and-Drop-Component-Suite-for-Delphi

Pfft! Maybe you should hire an HR or Public Relations person instead.

No, I think that's about it.

Can you explain why you need to know when a drag is initiated? It's a rather unusual requirement.

You can probably use the D11 package source files from the latest revision and the other source files from the graphics32-1-9-1-fixes-r2148 revision. Make a copy of the D11 package source files (and GR32_Compiler.inc) and then revert to the revision that worked with XE2. Then copy the package source files back and rebuild the design and run time packages.

I don't think that will make a difference. The package source files just contains the references to the GR32 source files and those are the same between the different packages.

I meant the Windows search path. Look for the run-time package: GR32_RD110.bpl I think someone that knows C++ Builder will have to help you with this. It seems there's a problem with passing a string literal as a parameter but I have no clue about what to do about it.

How?

Hmmm. Could it be that you have two different versions of the Graphics32 run-time package in your path? Using the debugger, are you able to step into the call to Image321->Bitmap->LoadFromFile ?

Place a breakpoint on that line and inspect the value of Image321 and Image321->Bitmap. They should both be non-nil. If Image321 is nil then the control wasn't instantiated when the form was created. Since you appear to be using run-time packages then that will probably have something to do with it. I still need the call stack when the exception is raised. If C++ Builder is like Delphi then you can select all the lines of the IDE's Call Stack window and copy them with Ctrl+Ins (or Ctrl+C).

I don't use C++ Builder so probably not. Do you get errors at design-time or only at run-time? If you get run-time errors then what's the call stack when the exception occurs?

Stop being lazy. Properties are not there to make your job easier or make you code faster. They're there to make your code better. They enable you to better express the API of your code by encapsulating and hiding the internals of objects. It's true that they're just syntactic sugar, if we disregard the design time aspect then everything a property can do can also be done with functions and procedure, but so what? That doesn't take anything away from the cases where properties have justification.

That really depends on what you're doing. If you at least start by finding out what's in the SDK (you can probably do that online) then you will know it's there when the need arises.

If you're exclusively a high level application developer then you probably don't need the SDK, but if you plan to do anything close to the OS then you should install and familiarize yourself with the development tools that comes with the OS. Imagine if your Lamborghini mechanic didn't have the official Lamborghini tools... Would you let him/her mess with your Countach?

Unless you actually understand what and why the Windows thread scheduler does it's generally better to leave that stuff alone. It's a classic newbie mistake to think that one can make a thread run faster/better by raising its priority. https://blog.codinghorror.com/thread-priorities-are-evil/

Yeah. It's good to get a reminder of this problem once in a while since it probably won't get fixed.

Resolved. You can download the new version here: http://melander.dk/download/amTranslationManagerInstall-1.3.8055.21506.exe

Reproduced. https://bitbucket.org/anders_melander/better-translation-manager/issues/24 Reproduced. https://bitbucket.org/anders_melander/better-translation-manager/issues/23

I found this in my usenet archives about the evaluation order:

The algorithms in that link are okay. It's your implementation of them that's a problem. Just get rid of all the HSL stuff and you should be fine. The formula you call "luminosity" is using the Rec 709 coefficients for "luminance" used in HDTV video. I recommend you read these two sections: https://en.wikipedia.org/wiki/HSL_and_HSV#Lightness https://en.wikipedia.org/wiki/HSL_and_HSV#Disadvantages

You haven't shown how you're handling the bitmap returned from ConvertToGrayscale but besides that your exception handling is wrong. Use this pattern instead: begin Source := TBitmap.Create; try Result := TBitmap.Create(...); try ... except Result.Free; Result := nil; end; finally Source.Free; end; end; Apart from that your grayscale algorithm is horribly inefficient (and wrong). Why use HSLToRGB when you know that for grayscale R=G=B and why use RGBToHSL when you already operate directly on the RGB values...?