I'm developing a WPF application for which I have several peripherals. I'm writing a stub for one of these peripherals that opens a secondary window which mimics the interface of the peripheral. This is mainly for development and QA automation purposes.
The problem I am experiencing is that my application generally opens a modal dialog whenever it's expecting user input through the peripheral, and that dialog is blocking access to the stub's window, which means no user input.
Is there a way to have the dialog grant access to the secondary (stub) window while still blocking the main window? I've tried placing the second window on a separate UI thread, but it still is blocked. I'm currently looking into multiple app domains, but my application generally interacts with the peripheral through events, and (from my reading) those won't be shared across domains.
I've never tried the same in WPF but in Windows Forms a modal dialogue only affects forms created on the same thread. If you create your peripheral window on a separate thread then it won't be blocked by the modal dialogue. It would make passing data between that window and those created on the UI thread a bit more tedious but certainly not impossible.
Related
I'm trying to implement a 'step-by-step guide' feature in my Windows Forms application. The guides are just step-by-step descriptions of how to do common tasks. I'm intending for users to work through the instructions while reading the guides. The window in which they're displayed therefore needs to be accessible when modal dialogs are being displayed.
Is this possible? If so, how do I do it?
When a modal is displayed, you cannot interact with any other windows in the same UI thread. It is possible (but probably not the best idea in the world) to run two distinct UI threads in the same process in C#-- but you will have to be very careful to keep things stable. In the main thread, run your normal modal form. In the secondary thread, you can run a non-modal form at the same time-- just keep a dedicate windows message pump running in that thread until you are done with the UI, and then shut down the message pump and exit the thread.
Thanks for andLabs, Tim and IInspectable for giving me the information I needed to solve the problem. The following does what I needed:
Thread myFormThread = new Thread(delegate()
{
Application.Run(new MyForm());
});
myFormThread.SetApartmentState(ApartmentState.STA);
myFormThread.Start();
It works fine. Obviously you need to be careful to use myForm.BeginInvoke if you need to access the controls on myForm from an event-handler of the main form. You also need to help the user to manage access to the form as it can get lost behind other windows.
I am have two different WPF applications running differently. now my requirement is to merge these application. Now Both application are WPF application. So I need to call Second application from the First Application So bascially I have created Two windows and I am initializing the Window2 from Window1 on a button click. Now the problem assuming that I have used the same resource files for both application.
What will happen if I close my First WPF application will the Second application will also get closed?
What should be the best approach in these situations?
If my main application window closes then the resource will also go out of scope and how should i ensure my appliction works correctly?
At the Application level you can set the ShutdownMode property to define the condition that will make the application terminate.
If the second application cannot run without the first one for some reason, as you suggest in your post, you could set this property to OnMainWindowClose. This way, if the first one is closed, the full application will stop
Spawn a new process on button click, that opens AppB. But that will keep both apps separate from each other, so no data sharing either. If you want to share data and code, add each page from AppB manually to AppA just like adding a third party control.
Background
I'm creating a windows forms application that implements the MVP-VM pattern. This post explains the overall approach I'm taking:
http://aviadezra.blogspot.ca/2009/08/mvp-mvvm-winforms-data-binding.html
My application has a main window that opens on application start-up. The main contents of the application are hidden until the user logs in, after which the user controls which expose application functionality are revealed.
The main window has multiple presenters, each one representing a different set of logically grouped functionality. When the application starts, only the presenter that creates the login dialog is populated. Then, once the user logs in, the remaining presenters are created. I feel this is a good way to prevent users from somehow accessing functionality until they are logged in.
Question
When a user logs out, I'm having trouble deciding what needs to be done. I don't want to re-create the main window, but the state of the main window at login is I think what I'm trying to achieve (only the one presenter initialized). When someone logs out, should I dispose all presenters except for the one that creates the login screen? How do I do that? I don't imagine just setting the presenters in the main form to null would work, eh?
we have this application which uses cross app domain (2 app domains in the same process).
we need to mimic the Dialog/Model window, which will wait for the result from the 2nd app domain before it can continue further. 2nd App Domain loads up WPF form (while 1st app domain is still on .Net 2 forms). we will have to use this Plugins approach so that we can leverage our new WPF without breaking our old app.
at the moment I am using ManualEventReset to singal when the 2nd app domain is done, but this is freezing up the GUI so that when I move the Dialog/Model window, it is not repainting the background. Only happens on Windows XP (Windows 7 works fine)
I was wondering if there is a way to implement Model window so that it will still allow messages to go through so that background can repaint itself. Let me know if you need more specifics
you could open a regular modal form, that immediately hides itself and open the desired winforms form on another thread ... so you can "deadlock" one thread until your operation is complete without blocking the message processing of your UI ... to exit the modal state after your locked thread is released, invoke your hidden forms close() (Invoke() call to your UI thread)
I am asking this, because i want to know if when we are running an app, for start if we have an window to authenticate like a Log In window, after validating the user, can we open the Main Window in the same Thread without creating a new one?
I am trying to do this in WPF, but i think that is same thing in WPF or in Windows Forms.
Yes, you can.
Just do it.
When you generate a Windows Forms application via the IDE, it will generate the code for one form, as well as a Main function that displays the form at runtime. You can rewrite the Main method so it displays one form modally then displays the next form.
But there's a simpler way to achieve your objectives:
Have two windows: your Main window, where most of the work is done, and the login screen.
In the OnLoad event of your main window, create an instance of your login window and call ShowModal() on this instance.
If the login fails, then exit the application.
This question does not offer enough context to tell you how to do this in your specific case. In general you can just Close() a window, construct a new one and call Show() on it.
You should make sure the Application.ShutdownMode does not kill off your application when the window is closed though.