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.

8 minutes ago, Vandrovnik said:

Of course I cannot guarentee it. But you wrote "Giving the user the wrong results is always worse than showing an error, even if the error is poorly worded.", so I gave you an example, where error message would be worse than ignoring the error.

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

16 minutes ago, Sherlock said:

Well, not showing exceptions and eliminating exception handling altogether are two different pairs of shoes, are they not? Why not log into some %APPDATA% folder every bug, that occurs and try to keep the application running. When a bug does manage to get reported ask someone to send you the (doubtlessly numerous) log files.

Apple for example highly discourages to display error messages in their iOS human interface guidelines. BUT they do encourage logging, and offer means to retrieve those logs from devices.

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

13 minutes ago, Vandrovnik said:

Not always... In an application drawing 3D scene, a small error in object displayed somewhere far away from the observer does not metter, probably nobody notices. Of course in a book-keeping application the situation is quite different.

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

32 minutes ago, Mike Torrettinni said:

I would rather have wrong results reported by users (and then I see that Range On would catch a bug and I fix it) vs to trigger exception to the customer.

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. 

1 hour ago, Dany Marmur said:

Range checking ON for ALL builds.

Unless performance is impacted 

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

31 minutes ago, Lars Fosdal said:

Integrity control. 

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? 

9 minutes ago, PeterPanettone said:

Are there any other considerations worth mentioning when deciding which Windows version to use for Delphi?

No

3 hours ago, PeterPanettone said:

Is Windows 10 Home 64-bit good enough to run Delphi 10.3.3+ without problems

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.

30 minutes ago, Lars Fosdal said:

My apologies for being unclear: One crit sec per object instance, with separate locking per object field. Return to previous description. 

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. 

2 hours ago, Lars Fosdal said:

Naturally, it is a simplification and doesn't apply to every context, but we used to have lots of micro locking, and lots of lock failures.  

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. 

2 hours ago, Lars Fosdal said:

Straight assignments are atomic, unless they involve logic or reallocation.

Data needs to be aligned. That's really the key point. 

55 minutes ago, Lars Fosdal said:

Never do locking on a per field basis - unless you have one critical section per field.

Otherwise, always lock the entire object

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.