Anders Melander

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...?

https://web.archive.org/web/20000620192211/http://www.totalqa.com/products/qtime.asp

I'm pretty sure it was the other way round. AFAIK it's still written in Delphi.

Aren't you using map2pdb with VTune?

It works fine but it's nowhere near as comprehensive as VTune. One advantage is that it works on both AMD and Intel platforms. I have AMD uProf version 3.2.449 installed and that works fine on my system.

And you're looking at the main thread? This is probably the COM apartment threading in play. If so, one of the other threads will most likely be running code in MSXML.

I'm on Windows 7 (on my main dev system) so no 😕 The latest version that works on Windows 7 is VTune Amplifier 2019. I guess I should give it a spin on my laptop (Windows 10 something something) instead before I judge it. That said, the version of msdia140.dll (which is Microsoft's interface to the pdb file) I'm using is the latest one and as far as I can see msdia140.dll is the bottleneck. Of course it might be that my version of VTune isn't using it correctly. I was just considering writing a replacement for msdia140.dll but it would be great if I don't have to go down that rabbit hole.

I dunno. Don't you find VTune's poor performance to be a problem? Personally I either need to be really desperate before I resort to VTune or I must have a very good idea about what I'm looking for (like, I need *this* exact function to be faster but I don't exactly know how to make it so). I have had successes with VTune in cases where I needed to optimize some SSE code but that's about it. On the project I'm working on right now (pure Pascal) it takes VTune over an hour to load the pdb file and so far it hasn't told me anything I didn't already know (from pausing in the debugger).

François, for something like this you probably don't need a profiler at all. Especially not an instrumenting profiler (more on that later). What I always do, before resorting to profilers, is to simply run the code in the IDE and pause the execution in the debugger when the time critical code is executing. Statistics dictate that the current call stack will show you exactly where your hot spot is. Repeat a few times to verify. Basically this is the same approach a sampling profiler uses. The problem with instrumenting profilers is that the overhead of the instrumentation code affect the timing results so much that you can't really rely on it. They're great at determining call graphs and identifying the relative call frequency of different methods, but in my experience you can't use the timing for much.

It's not "clever". If real problems gets too hard to solve just invent some easy ones.

You misspelled Obfuscation.

Very nice. That actually makes it very clear what the problem is - but isn't there something missing? You've declared Child but not actually referenced it anywhere. Maybe you meant to write: Y<T: Child> = class(X<T>) ...

Instead of this: const sCannot: string = #13#10 + 'Cannot send AP Emails!'; do this: const sCannot = #13#10 + 'Cannot send AP Emails!'; and then read: https://docwiki.embarcadero.com/RADStudio/Sydney/en/Declared_Constants#Typed_Constants As I read the documentation, if you make the const typed then the compiler cannot concatenate the strings at compile time but will have to do it at run time. Probably because typed consts can be modified at runtime if you have that option enabled. In your example it's a variable local to the method. I'm sure there are also still people who argue that it's safe to run with scissors as long as <insert excuse here>. No seriously, stop using "with". It doesn't make you code more readable. On the contrary. It's impossible for someone else (i.e. that unfortunate person who will maintain the code after the author has moved on to greener pastures) to see if an identifier references a "with'ed" member or something higher up in the scope. Also the debug inspector can't cope with it. You might think that in your case it's safe because <insert excuse here> but I could identify several things that could go wrong in your code that you apparently haven't thought of.

Not related to your specific question but... Get rid of that. TaskMessageDlg already plays the system sound associated with the message type. Does sCannot really need to be a typed const? As far as I remember it's better type use untyped string consts since these will end up in R/O memory. Also you use #13#10 here but sCRLF everywhere else. Personally I prefer #13#10 (or just #13 when that is appropriate) since it's more explicit. Since MailSender is a local var and only used inside the try...except block, there's no point in using FreeAndNil() here. Just use Free instead. If you only use FreeAndNil when there's a reason to then it will communicate to the reader that here's something to be aware of; The var needs to be nil when it doesn't reference a valid instance. Since you're already refactoring all this, get rid of the "with" statements - and forget you ever learned about it.