I am currently a developer working on a very task specific application; the user(s) are often multitasking so they can often make errors inputting data. The nature of the task makes notifying them of those imputation mistakes important. We currently use a combination of panels and labels and/or a small label at the bottom of the application in order to notify them of something happening. In the near future we will be tasked to update interface for the application.
Recently while looking up an unrelated question I came across the following question:
click here for link the answer caught my eye and setting the owner’s handle to zero (null) did indeed do what the author asked.
Since I have only recently started working with importing and working with unmanaged code in C# I was wondering if there were any “side effects” of using this method. I of course realize that the user could cause the application to open a ton of message box(s). I have in the past attempted to use a thread-safe message box and found the requirement of our application always being on top was an issue (the location of the message box was hidden by the application).
I was able to take to test the code against the requirement, and it appears to have similar issues as the method I found but appears we could work around those issues. I did think of something that could be done, I realy need to figure out how to determine where on the screen the message box will be displayed.
In order to address Jim’s concerns one has to understand that the application that is running is processing data continously. So currently anything that locks the main thread, can cause problems processing this data, which is task critical. We get around this problem using labels, but with our future task I am looking for a more streamline approach to present these error messages. The main problem is the solution also must not additional overhead to the application. Some additional tid-bits of information is that the system is used on a closed network.
I suppose the short question would have to be, are there any negatives of using this particular method, to show a non-blocking messagebox in C#?
There’s no particular technical problem with displaying modal message boxes by setting the window handle to null. I question its use as a UI error message indication, because it doesn’t prevent the user from continuing in the face of error.
Modal message boxes that make the user hit OK and then correct the error make for a terribly clunky user interface. But a popup that might be hidden and lets the user keep going is just as bad. There are much better solutions, some of which are shown in the validation examples for Windows Forms (and, presumably WPF).