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)
Related
I created app that open every time that I start pc. So its so annoying to close it every time so I'm wondering if its some code that will hide my console app. I saw videos and tutorials on forms but idk how to do it with console app.
The easiest way to do this is change your console app to a windows app.
Console apps get a console made for them by Windows. But if you change it to a windows forms app, then windows expect the application to make a window, so if you never make a window, then it will never show
The other way is to turn your application into a service. This has some additional requirements in terms of programming
Option 1
You can use this run command:
start /min "SomeTitle" MyConsoleApp.exe myarg1 myarg2
Thus it will be on the taskbar minimized.
Option 2
If you use a file link in the start menu, select the start minimized option for the exe.
Option 3
Using a WinForm app you will be able to use a tray icon by setting the main form as not visible, to say it simply because it can be complex according to the expected behavior, and it will not be in the taskbar too.
Option 4
If you don't want a main form, create a win form app, delete the form file and the code in the main method, and you're done, without GUI nor console, no main input and no main output but you can show MessageBox and some forms when necessary, just a background process only visible in the Task Manager.
With that you can add a tray icon to to offer exit and some status information for example.
Option 5
Also you can create a windows service:
.NET console application as Windows service
Note
In all cases, if you don't use an internal message events dispatcher like the WinForms Application pattern or WPF and so on, be carefull to not saturate the CPU with the processings like with loops and use Thread.Sleep() between iterations or any thread idleing pattern or some timer if necessary.
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 developing a WPF application when the application is shown a thread work
and show a refreshed data on the application ui .
for saving performances i want to stop this Thread if the application is 100% covered by another application .
for example if the user is using another application that take the right half of the screen ,and my app is shown on the left half of the screen , the app must steel works cause the user is using the other app and watching the
changed data on my app .
if the application is back grounded or 100% covered by another app window or
minimized must stops;
i tried many solution like using the Deactivation event of the window
and p invoke but that not resolve the situation.
and thanks you.
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.
K I am looking at a primarily single thread windows forms application in 3.0. Recently my boss had a progress dialogue added on a separate thread so the user would see some activity when the main thread went away and did some heavy duty work and locked out the GUI.
The above works fine unless the user switches applications or minimizes as the progress form sits top most and will not disappear with the main application. This is not so bad if there are lots of little operations as the event structure of the main form catches up with its events when it gets time so minimized and active flags can be checked and thus the dialog thread can hide or show itself accordingly.
But if a long running sql operation kicks off then no events fire. I have tried intercepting the WndProc command but this also appears queued when a long running sql operation is executing. I have also tried picking up the processes, finding the current app and checking various memory values isiconic and the like inside the progress thread but until the sql operation finishes none of these get updated. Removing the topmost causes the dialog to disappear when another app activates but if the main app is then brought back it does not appear again.
So I need a way to find out if the other thread is minimized or no longer active that does not involve querying the actual thread as that locks until the sql operation finishes.
Now I know that this is not the best way to write this and it would be better to have all the heavy processing on separate threads leaving the GUI free but as this is a huge ancient legacy app the time to re-write in that fashion will not be provided so I have to work with what I have got.
Any help is appreciated
It sounds as if the long running operation is bound to the progress dialog? That's usually a bad idea and I wonder whether the progress can be showed at all.
However you should consider using a BackgroundWorker for your long running operations. So your GUI (the main form as well as the progress dialog stays alive).
This way you should be able to send the minimize event of the main form to the progress dialog which can react to it instantly.
Btw. the BackgroundWorker supports progress reports on its own.