Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>It seems to me that you have some very ugly bug in your code! I'd focus on fixing this bug first. The easy way to do this is to set a breakpoint on the line that opens up the dialog. When the line is hit the second time (while the first dialog box is still open), view the stacktrace at that point and check all active threads (View Threads and View Stack windows) for the cause of the issue.</p> <p>In addition, change your code to open a modal dialog window instead, where the parent window must be the owner. A modal dialog window will stop execution and prevent the parent window from processing user input (which could've lead to this behavior).</p> <h2>Edit</h2> <p>From your comments I gather that you have several threads that you cannot control and that you want one thread at a time to access the messagebox code. When working with threads, there are several synchronisation primitives available. Expanding on each of them requires a book (you may try <a href="http://rads.stackoverflow.com/amzn/click/032143482X" rel="nofollow noreferrer">Concurrent Programming on Windows</a>, one that's thorough while the book has some flaws in its structure), knowing the right one for you requires knowledge of your code. </p> <p>That said, you may wish to do something like the following, using a Mutex which at least prevents other threads to access the code (meaning: it will put them in a suspend state until the Mutex is released). Add a static boolean flag variable (or add a checkbox on the popupped form "show box only once") if you want to prevent the popup box to show more than once. Mutex plus flag solves two problems in one: only one thread will ever run that code, and the code will only run once, ever.</p> <pre><code>// as static class variable, create a mutex private static Mutex dialogMutex = new Mutex(); // a static flag preventing the dialog box to show more than once // (you may wish to resolve this differently, depending on req's) private static boolean dialogIsShownOnce = false; public static void ShowDialogBox() { // Wait until it is safe to enter, this makes the current thread // the exclusive user of this code and other threads may only enter // after the current thread finishes. dialogMutex.WaitOne(); // depending on your requirements, you may not want this // must come _after_ WaitOne to prevent entering before another // thread that entered hasn't yet changed this variable if(dialogIsShownOnce) return; // show your dialog box as a modal box // if you are unsure: add a breakpoint just after the ShowDialog // it should only be hit _after_ you dismiss the dialog box yourForm.ShowDialog(); // set the flag, or the counter, or whatever you wish: dialogIsShownOnce = true; // Release the Mutex, this will remove the "roadblock" and allow // other threads to enter this piece of code dialogMutex.ReleaseMutex(); } </code></pre> <p>The code above is not tested and should be considered a hint on how to tackle this issue. There are so many ways to solve this, but I think the above method may just be what you need.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    1. COI've tried to debug already and indeed put the breakpoints as you've said and looked at the call stack on the second hit. I can trace it back to the point where it references "[External Code]" which is where another program is interacting with my program (I also think that GUI functions of my program create this situation too). So an external program and/or the GUI (to calculate and display a value) are causing my program to arrive a this point. I am calling the dialog box with ShowDialog() which I believe displays a Model form, and hence is currently restricting my input into the application.
      singulars
    2. CO@clawson: Forms are, by default, capable of handling things asynchronously. While user input is blocked, the parent form can still receive messages as may happen in the current case. If you want to block these message, use a static (!) true/false flag `BlockCommunication` which is used (read, not written!) by the methods that receive communication, or by the current method if communication should be received but should not trigger the window popup. Writing to this flag should be done thread-safe with, for instance, `lock` in the settor.
      singulars
    3. CO@Abel: This appears to be the case. Do you know where there is an example of this? (I couldn't find one.) Maybe if you write an example as an answer to this question I can accept it as the answer. I understand the theory behind the static flag, but I don't know what to do once I hit it. I don't want to return from the function, and if I sleep the thread won't that stop everything. I just want to pause execution along that 'message branch' (if that's what it's called), until the response is received. Thanks for your help.
      singulars
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload