David Heffernan

Cross process UI is fraught with complications. I wouldn't dream of trying to parent a window from one process into another process.

People for sure would rather have an error message than incorrect results. You are just kidding yourself if you say otherwise. It's simple human denial. Suppressing errors will result in a program with more defects. We all know this to be true. And yet people still choose the path with more defects. What happens when you access an array out of bounds with range checking disabled? Perhaps the memory is valid and so the program continues running. But now it's behaviour is unpredictable. Often you will corrupt memory which leads to obscure errors later that you can't tie back to the original defect. Or quite often it's a straight AV which is hardly preferable to a range check error, since it isn't reproducible.

Yes, but since you don't know that the error will be inconsequential, it's kinda pointless looking at the impact.

Better hope that the incorrect information that you show to the user is inconsequential.

I'm amazed that you can guarantee that the error will be far away from the observer. How did you do that?

No you wouldn't. Giving the user the wrong results is always worse than showing an error, even if the error is poorly worded.

I agree with this. If it doesn't impact performance, then for sure include it in release builds. However, sometimes it really does. It does in my numerical code, but obviously that type of code is probably in the minority amongst Delphi code.

You can change viewer. You don't need to change the test framework in order to use a different viewer.

Unless performance is impacted

Irrespective of what any poll says, opt off, range & overflow checks on is the correct thing to do

I don't understand that.

Certainly I'd do all the work to prepare the resource from the source file as a pre build step, properly automated. I'd question the choice to use compression. What is the point of that?

No

Yes

@Arnaud Bouchez How do you handle a line longer than your buffer?

Often it's not how much memory you use, but how you use the address space. But if you can, just switch to 64 bit and move on.

Lots of us deal with legacy code. After all, we are Delphi developers.

Deadlocks are perfectly possible in this scenario. The fact that you talk about the likelihood of deadlocks is frightening. I really don't get such a defeatist approach.

@Lars Fosdal you can't have a deadlock with only a single recursive lock. I think that was mentioned earlier in the thread.

Start by following a tutorial on how to create a dll and export a simple function. Work up from there.

Build the dcus into a dll and link to that. You can't use packages because you can only link packages that were compiled with the same compiler. That's a short term solution. Long term you should replace the library.

If you use the right techniques then it is perfectly possible to achieve write software that won't deadlock.

You can't deadlock with a single lock, so long as the lock is recursive. These blanket statements are not helpful.

That's because your design was broken, not that per field locks are inherently a problem. What matters is the algorithm, and having a deep understanding of the issues. Superficial rules like the one you gave do harm in my view. Data needs to be aligned. That's really the key point.

Not sure I agree with this sweeping statement. Can you provide a rationale for that statement? I don't think that thread safety can be boiled down to rules like this.