Don't use Application.MessageBox

[SergioSmolensk 0]

join := Parallel.Join(
    procedure (const joinState: IOmniJoinState)
    begin
      ...
    end,
    procedure (const joinState: IOmniJoinState)
       begin
      ...
// don't use !!  ERROR !!       Application.MessageBox('Error', 'Error', 0);
        MessageBox(0, 'Error', 'Error', 0);  // That's the only way
        ...
      end;
    end).NoWait.Execute;

 

[Remy Lebeau 1392]

Can to elaborate further?  What is the actual error that you are getting?  Note that TApplication.MessageBox() is generally just a wrapper for Winapi.MessageBox().  Although it is not entirely thread-safe, as it manipulates a global TaskActiveWindow list.   So yes, using Winapi.MessageBox() directly is generally safer when displaying a message box in a worker thread.

Edited February 25 by Remy Lebeau

[David Heffernan 2345]

Reporting error dialogs from thread pool threads sounds terrible. Stop doing it at all and then you don't need to think that one message box function is better than any other. 

[dummzeuch 1505]

11 hours ago, David Heffernan said:

Reporting error dialogs from thread pool threads sounds terrible. Stop doing it at all and then you don't need to think that one message box function is better than any other. 

That depends on the use case. If you want to show the error in order to then connect the debugger to the running executable, that's a good way to do it.

[David Heffernan 2345]

24 minutes ago, dummzeuch said:

That depends on the use case. If you want to show the error in order to then connect the debugger to the running executable, that's a good way to do it.

Hardly, because you've now ruined your production program. 

[Remy Lebeau 1392]

14 hours ago, dummzeuch said:

That depends on the use case. If you want to show the error in order to then connect the debugger to the running executable, that's a good way to do it.

If the code is expecting a debugger to attach, I would just call IsDebuggerPresent() in a sleep loop until it returns true or times out.

[dummzeuch 1505]

6 hours ago, Remy Lebeau said:

If the code is expecting a debugger to attach, I would just call IsDebuggerPresent() in a sleep loop until it returns true or times out.

There are two reasons for displaying the message:

1. Stop the thread at that point
2. Inform me that the situation I want to have a closer look at has occurred

It's a simple way to do that when this situation happens irregularly and I don't want to run the executable in the debugger from the start. Yes, it could be differently, but I don't see the point to make it more complex than necessary.

 

As for David Heffernan's  comment: I'm talking about debugging, not production code. I thought that was clear from the context.

[David Heffernan 2345]

2 hours ago, dummzeuch said:

As for David Heffernan's  comment: I'm talking about debugging, not production code. I thought that was clear from the context.

If you are debugging then throwing an exception is the way to do it. Then the debugger freezes all threads. You surely don't want the other threads to continue running at this point.

[dummzeuch 1505]

3 hours ago, David Heffernan said:

If you are debugging then throwing an exception is the way to do it. Then the debugger freezes all threads. You surely don't want the other threads to continue running at this point.

As I originally said: It depends on the use case.

 

My programs usually have only the main thread for the UI and possibly one or (very rarely more) worker threads that are independent of each other (no threadpool). In that case it does not matter whether the other threads continue to run or not.

An exception won't work because I only use this method when I don't want to run the executable inside the debugger in the first place, so there won't be a dubugger to catch that exception.

[David Heffernan 2345]

3 minutes ago, dummzeuch said:

As I originally said: It depends on the use case.

 

My programs usually have only the main thread for the UI and possibly one or (very rarely more) worker threads that are independent of each other (no threadpool). In that case it does not matter whether the other threads continue to run or not.

An exception won't work because I only use this method when I don't want to run the executable inside the debugger in the first place, so there won't be a dubugger to catch that exception.

I don't really follow this. If you have to modify your code to add the message dialog, before you start debugging, then I'm not quite sure why you can't run with a debugger attached. If you are happy to attach the debugger later, why can't you attach it at the start?

[Kas Ob. 121]

25 minutes ago, dummzeuch said:

As I originally said: It depends on the use case.

 

My programs usually have only the main thread for the UI and possibly one or (very rarely more) worker threads that are independent of each other (no threadpool). In that case it does not matter whether the other threads continue to run or not.

An exception won't work because I only use this method when I don't want to run the executable inside the debugger in the first place, so there won't be a dubugger to catch that exception.

I did that many times in very similar needs, but instead of MessageBox which also i in the past used, now i do exception in a loop with Sleep(1) with check for global boolean variable, this will stop that thread specially if i am after the main thread.

In some cases starting the debugging process is very slow if i don't know exactly when it will happen, like hunting these loch ness situations, but with that loop i don't have the message box, where the main thread had altered stack or touched, attach the process to the debugger then it will break in place, then change that global to exit the loop.

[dummzeuch 1505]

2 hours ago, David Heffernan said:

I don't really follow this. If you have to modify your code to add the message dialog, before you start debugging, then I'm not quite sure why you can't run with a debugger attached. If you are happy to attach the debugger later, why can't you attach it at the start?

1. When run in the debugger, the IDE sits in the taskbar and I might accidentally bring it into the foreground while I am working on something else in a different IDE instance (or any other program). No big deal but it always interrupts what I am currently doing. But if I am working in a different instance of the IDE I might accidentally change the source code or even worse terminate the debugging without noticing that I am in the wrong IDE instance. This has happened more often than I would like to admit.
2. Any kind of exception will stop the program while running in the debugger, even if there is a handler for it, and bring the IDE to the foreground. I then have to check whether I am interested in it or not. Again, just an annoyance. I could probably turn off "break on exception" for that, but I tend to forget changing this back, in particular if I am working on a different program in a different instance of the same IDE.
3. Sometimes it takes quite a while for the situation I am interested in to occur (we are doing a lot of batch processing on large database files that might run for hours and I might not know what causes the problem so I can't run it on a smaller database), so the program might run over night with nobody there to press the "Run" button if that happens.

Edited February 26 by dummzeuch

[Remy Lebeau 1392]

8 hours ago, dummzeuch said:

Any kind of exception will stop the program while running in the debugger, even if there is a handler for it, and bring the IDE to the foreground.

You can configure the IDE to not break on exceptions.

8 hours ago, dummzeuch said:

I then have to check whether I am interested in it or not.

I usually use breakpoints to tell the debugger to not break on exceptions that occur within specific sections of code I don't want to break on.