I have an application that monitors bit states from external socket/Ethernet connections, known as a PLC device.
These states trigger database calls and UI updates, some of which require Modal dialogs, others require Modeless dialogs.
The issue is that the process needs to continually monitor even when a Modal dialog is displayed.
I have tried using a DispatcherTimer, but this will block when a Modal dialog is displayed. I understand the reason why.
I tried a standard Timer, but I get an exception stating something like 'Some UI components require the thread to run in STA mode.'
So I create a standard Thread and set the ApartmetState to STA. The thread runs just fine after adding DispatcherInvoke around the part of the processing loop that requires UI interaction, but whenever a Modal dialog box is displayed, the thread is blocked until the Modal dialog is closed.
Now I really do not want to get into inter-thread messaging and over-complicating the whole thing.
I have also tried putting the Modal dialog into its own thread whenever a Modal dialog is needed. Everything works fine and it was almost acceptable, but the owner window of the application is still accessible, essentially making the Modal dialog a Modeless dialog. I tried setting the IsEnabled flag on the owner window and at first I thought that would be okay, but it is still active when clicked and hides the dialog.
Any suggestions?
I have solved the issue! I reverted back to a standard Timer and was able to get around not requiring STA mode; this reguired another judicial placement of Dispatcher.Invoke.
Now everything works as I expect.
Related
In my project I have a MessageBox that pops up from time to time.
When I'm playing a game and the MessageBox appears, the game is minimized and I'm back to the desktop.
This might depend from app to app, but this specific app/game minimizes when MessageBox appears.
How to avoid this behavior? Is there anything I can do to the MessageBox to make it lose focus/not activated ? I tried to look at the MessageBox methods but no luck.
It sounds like you want the message box to be able to display while the rest of your code is still running. Type of messagebox you are using is modal and needs to be closed until it allows you to interact with the other open window.
I suggest you start a new thread for the message box so that the thread can continue to run allowing you to be able to interact with the other windows.
How can I show a dialog message, similar to MessageBox, which have just the "Cancel" button and can be closed by the application.
The idea is to show the dialog while the application retrieves data from a server, allowing the user to cancel this request, and closing the dialog once the request is completed.
I recall having a very similar problem in the past. I don't think there is a dialog message "out of the box" that works like that. The way I solved this was by writing a class that modeled this sort of behavior in a window and having the application spawn an instance of the window.
The silverlight message box blocks code execution while it is open so it is not possible to close it. However you can use an XNA messagebox in Silverlight which is asynchronous
This explains its use in depth
You can probably then call EndShowMessageBox for your purposes.
if your intention is to let the user know that something is loading and that they should wait. you should use a progressbar instead.
How to: Create a Custom Indeterminate Progress Bar
Using the CoreScanner Driver provided by Motorola, I'm trying to write a small winforms application that uses a barcode scanner. I'm able to interact with the scanner just fine, and properly register a call back for the OnBarcodeEvent(). In this callback, I have a Dialog that opens and displays a screen that the user needs to fill in. Shortly after the dialog is opened (using Show()), the program hangs. If I use ShowDialog(), the dialog works, but the dialog is blocking the OnBarcodeEvent event.
My guess to what is happening, is that since the dialog is getting created on the event thread, there is a race condition occurring when using Show(). Since Show() is non-blocking, the thread continues on after displaying the dialog and then dies out. Meanwhile my dialog just lost it's parent and locks up? Like i said... my best guess.
How can I remedy the situation? That is, How do I write my dialog so that it can be created within a thread not hang?
In the event, you should launch a different thread that will create your dialog form and show the form on it. You need to block this thread till form is visible - this is possible either by ShowDialog or alternately use one of Application.Run overload.
Yet another option would be to show the form on the UI thread (i.e. main application thread) - to do that, you need to call Invoke method on your main form from the event code. The invoke call should take the delegate that will show your dialog form non modally.
I have some experience with Motorola/Symbol Handheld-Devices (MC9090) and I guess the SDK will be similar.
It's hard to say without seeing the code, but my guesses:
your common not-UI thread problem - so make sure you open your dialog using UI thread
the native Motorola-driver is crashing - no kidding, this happened a lot to me - in my case (compact-framework on a WinCE device) this would not freeze the program but the scanner will not work/receive any messages before restarting the device
In order to fix this you should seperate the showing/handling of user-dialog away from the event and make sure you call this on the UI-thread (Control.InvokeRequired / Control.Invoke).
I am new to C# but I have been programming with VB6 for a long time. I have a very simple project that runs without any errors. There is one problem however and it has to do with the Windows itself. If I open up any Window (from any other program) and that window overlaps my application...the moment I close that "other window", my application's Window does not repaint the portion that was overlapped by the "other window".
The same thing happens whenever the Bubbles screensaver comes on for Windows Vista. When I jiggle the mouse to cancel the screen saver, guess what??? I have bubbles scattered all over my Window. In VB, we had a simple "Window.Refresh" and voila! In C# however, this does not work. I have scoured the forum(s) and there seems to be a mention of "refreshing a thread". I'm kind of confused at this point. Why can't things be simple??
You can call Form.Invalidate to invalidate the client area of the form. That will cause it to receive a paint message, and redraw itself.
This is similar to the VB6 Refresh method.
However, this should happen automatically. If your application is doing some processing in the UI thread, however, it will prevent it from processing its messages until the work is completed. If this is the case, you should consider using BackgroundWorker (or some other method) to push the work onto a background thread.
There is nothing special you should need to do to redraw the Form in C# (Form should redraw fine when you bring the window back to the top).
Do you have any third party controls in play? Control.Refresh() does exist in C#, should you should be able to call it from the Form itself (usually this.Refresh() in your Form's codebehind), or any Control which has children (like Panel).
I am attempting to write a specialized onscreen keyboard (OSK) for an application I'm writing in C#. To facilitate this, I've created a form which has several buttons on it representing keys, and clicking them calls SendKeys and sends out the appropriate keys.
This form is owned by the main window that is shown when the application first starts, using the Owner property. This way, the OSK pops up whenever the user focuses the application, and it stays on top of the main window if it said main window is dragged over it.
This all works great, but because I have modal dialogs that I also want to use with the OSK, I attempted to create it in a separate thread, complete with its own message loop (via Application.Run) so it could still be usable with any modal dialogs in the main thread.
The problem with this is that, obviously, being in a separate thread can cause InvalidOperationExceptions because of cross-threaded calls. One specific example of this is when calling Application.Run(osk) from the new thread, a cross thread error occurs because it is attempting to update the window's handle with the owner (the main window).
My question is, is it possible to have an owned form on a thread that is separate from the owner in a safe manner? And, if failing that, is it possible to emulate an owned form's characteristics (namely being Always On Top for only the main window, and popping up when the main window is focused)?
Thanks, and sorry if this is confusing.
I think this is actually a bug in Windows Forms. Somewhat inevitable due to the way it checks for access to the Handle property by the wrong thread. The SDK docs for SetParent are not explicit about it, it states the requirement is that both windows belong to the same application. No mention of having to belong to the same thread. I know for a fact that the 'same application' requirement is not hard, there's appcompat code in Windows that makes this work for windows from different processes. Adobe Acrobat ab/used this for a long time. Which definitely absolves the 'same thread' requirement.
Well, punt the problem and try it out. Set Control.CheckForIllegalCrossThreadCalls to false before you set the owner, back to true afterward. And test the heck out of it. If you have trouble then try pinvoking SetParent() directly instead of setting the Owner. Windows Forms actually uses SetWindowLongPtr which is not recommended by the SDK.
I'll take a stab at this. Try running the OSK as a separate process.
Try using ShowDialog for the OSK as well instead of Application.Run - ShowDialog creates a message loop and ends it when the window is closed, and perhaps will solve your problems.
new Thread(() => new OSK().ShowDialog());
Why not use Control.Invoke to make cross-threaded calls to avoid InvalidOperationException?