David Heffernan

No. CoInitialize doesn't report errors by throwing exceptions. You are expected to check its return value. This is stated clearly in the documentation for the function which is required reading before using it. Let's leave error handling to one side for now though. The try finally pattern is like this. res := acquireResource; try res.doSomething; finally releaseResource(res); end; The try/finally is protecting the code *between* acquisition and release. Therefore the try must be *after* acquisition.

This code is wrong. The try is always placed after the resource has been acquired.

It's broken in my view because binary search should be O(log n). And this code isn't. It isn't binary search. It's a hybrid binary and linear search. Obviously people can do what they want. I won't be using this code though.

I don't think that's right. You suggest we should just use broken code because that's likely to persuade Emba to change it? I want the program that I ship to be good.

This is why I avoid Embarcadero library code and write my own

Nobody should be calling that function that makes binary search O(n) in worst case.

Stefan is talking about a different algorithm, modified binary search algorithms know as lower or upper bound binary search. Kind of the entire point of this topic.

Wait. If you have a list with two million items that all have the same value, and you search for that value, the code will do 1 million compares to find the first item?

If there is no existing function then what? You just give up. Why is it not possible to write code?

We are talking about the bug described here https://stackoverflow.com/a/7640979/505088

No. The asker is talking about the known bug where you pass TInterfacedObject.Create to a const arg and the object is never destroyed.

This is a very long standing bug that for reasons I cannot understand Embarcadero won't fix

The asker wants to use reference counting with a mutex that is created elsewhere, and passed to the guard object. Your code does something completely different from what the asker wants to do.

Why wouldn't you do it with DDE. That's precisely what it's for.

Also the if statement is not needed and just be removed

I'm very sorry!! I got carried away. Is it possible that DDE is being used? That was how this would have been done in the old days.

Just don't put my name near a call to ShellExecute and everything will be fine!! 😉

Of course, that would be assuming one's gender which isn't great. The French to their great credit have extended their language to include non-gendered pronouns. https://coucoufrenchclasses.com/the-coucou-guide-to-inclusive-and-gender-neutral-french/ https://blog.lingoda.com/en/french-gender-neutral-pronouns/

ma chérie mon chéri I am male, as you can infer from my forename. Therefore you use mon chéri. https://www.larousse.fr/dictionnaires/francais/chéri/15145 I'm surprised that Google translate gets this wrong. Although perhaps my French is even worse than I think it is!

mon chéri

Oh how it pains me to see my name in a post with a call to ShellExecute. That function should never be called because it doesn't offer proper handling of errors. Although it also shames me that my SO answer doesn't handle errors.

Yes. But of course you need to define what thread safe actually means in this context. It's a very general term. For win32 the threading model is that all operations on a window must be performed in the thread that created the window. Queued messages for that window are delivered to the meesage queue of that thread. Nonqueued messages are synchronised onto that thread. This is not a free for all thread safety where you can do anything you want from any thread. This is why the term thread safety is often not useful. It's more useful to describe and summarise the threading model. In this case I always say that windows have thread affinity.

This isn't really true. You can have multiple threads that serve multiple windows with different message loops. Windows supports that. What you can't do is do that in vcl.

We still have no real clue what your code is doing. The excerpt you posted doesn't much help. Storing byte arrays in an ansistring is for sure broken. Always has been since unicode Delphi. But it's not clear you are doing that. You should stop hoping that it's a Delphi bug and look at your code. Almost certainly that's where the problem is.

Char(11200) is a perfectly valid Char, and represents a well defined UTF-16 element. The issue is when you convert to AnsiString.