Anders Melander

The first question you need to ask yourself when trying manipulate thread scheduling is: Am I smarter than the people that designed the OS thread scheduler? If you can answer yes to that then go ahead and use SetThreadAffinityMask on your threads but I doubt you'll get the improvement you think. The two threads will still have to compete with all the other threads running on the system (and there's thousands of them) but now the scheduler can't move them to another core if their designated core is occupied. All you've achieved is to give your threads a handicap.

How can you tell? I'm impressed if you managed to make any sense of it 🙂

Yes, okay. Consider it emphasized - again.

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