David Heffernan

If it failed in a virtual environment, then the code is presumably defective

I have a case in my test suite that checks compilation for all supported delphi versions of all code that I ship to clients. Pretty easy to set up.

I think it is often the case that documentation for Delphi is added sometime after the code is released. Documentation for mature parts of the libs is often reasonable. Not so much for newly released libs. I think this is a really poor way to develop libs though. I routinely find design issues when I am writing documentation. If you write the documentation after you release then you'll find those issues after the consumers have started using the libs.

I don't think RTFM is the right way to say it. But I trust you make a mental note to check the documentation another time. I mean, the way the message was delivered was clumsy, but the thrust of the message is valid.

is all you need

OK, I was sloppy. I still don't get why you wrote this sorting function rather than use built in algos.

Writing a sorting algorithm into a UI control is a bad idea. Keep the two separate. You'd only really need to use merge sort if you needed a stable sort. And then you'd have to take care that the merge sort algo was a stable one. Surely there is perfectly usable built in sorting code?

I remove them all. I don't have any problems. It means I can use any of the many versions I have installed easily. For versioned packages, e.g. vcl270.bpl then multiple entries are fine. But for non versioned tools, e.g. dcc32.exe then it's a mess. These days it just feels a bit weak to rely on the path to find libraries. I always place them in the executable directory, or in sub directories and use SxS assemblies. I remove all entries and then my build scripts set up the appropriate environment for the target version, and then call msbuild. Works for me but I'm sure there are other ways.

Invalidate doesn't send a message. It marks the control as needing repainting and then that paint message is synthesised the next time the message queue is emptied.

It's a shockingly bad way for a software house to prioritise. It's susceptible to an effect known as self selection. As worthwhile as a Twitter poll.

No. That's not what Invalidate does. It marks the paint box as invalid. And then when the message queue is next empty, a paint event gets synthesised. The thing is, at some point you need to make the main thread wake up and do something. What's your plan for doing that? Perhaps what you want to do is note that an update is required with a flag and then check that on an update timer in the main thread. That would be a sensible approach if the frequency of updates from the threads was very high. Bear in mind that in the OP you suggested sending a message from the worker thread to the main thread. Have you now decided that you don't want to do that?

Dude, it was you that wanted to have the worker thread notify the main thread! That's literally what you asked in the OP. Why would you opt to send a message to the parent? I only said that because you can't send a message to the paint box since it isn't windowed. Which is why Queue or Synchronize are cleaner. Ultimately, you need to call Invalidate on the paint box, from the main thread. And you need to decide what is going to trigger that to happen. I gave you some examples, and of course there are other ways. But your have to make you own mind up.

Like that works!

You'd have to post the message to the parent. But why bother. Just use TThread.Queue.

Use TThread.Queue, not least because the paint box isn't windowed.

You never send a WM_PAINT message to a control. You invalidate in. For a plain Win32 control that means calling InvalidateRect. For a VCL control that means calling Invalidate. You don't want to call that from a thread. Use Synchronize to execute code on the UI thread.

On the plus side these can be readily fixed yourself for your programs. I mean, I've been running with a patched RTL for years that fixes all the design flaws in handling of floating point control flags. At least we have access to the RTL source code and so can apply fixes easily using code hooks.

Depends on all sorts of things. I guess people are finding it hard to get motivated to write it all down.

This sounds like a whole layer of extra complexity for no gain. Frankly I'm not surprised that you seem to find everything so challenging when you choose to introduce layer on layer of complexity.

Nah, that's not true.

Automating Word for document preparation is known to be somewhat brittle. More robust is to generate Word documents directly without invoking Word at all. There are good libraries for doing that. That's the point. If you are going to rely on Word for this then it pays to be very careful about the version that you use. Switching to Office 365 is simply asking for trouble.

OK. I've been working to the definition in the Delphi RTL.

Wrong. It returns a Bool, which is LongBool, the 4 byte boolean. The right fix is for Emba to change it to Boolean.

You can't have read the documentation. Because you aren't calling ShutdownBlockReasonCreate. I know that you want to solve this quickly. But that expectation is unrealistic. It will take you time to wade through this, try it out, read and understand example code, etc. For sure one of us could write you some examples but unless you understand it will you really be able to integrate it into your code? Just because you don't understand this now does not mean that you can't learn it. It just requires self belief and persistence.

You aren't doing what the documentation I linked to instructs you to do.