I'm working WPF application, Currently it has one window and at specific time (As per my requirement). It's displayed on top most priority.
this.Visibility = Visibility.Visible;
this.Topmost = true;
Now, I want like user should close first this windows(WPF application window), till cannot access any other thing from system.(user cannot able access even other application also) Seems like to force close first this window
I've been searched, but not getting anything.
How Can i do that?
You can't.
Imagine another application tried to do the same thing at the same time - you can't close window A before window B, but you can't close window B before window A, but...
Edit: the short version above can be misunderstood, so in more detail:
Let's say, your application has this very important message for the user, so it opens a special window. The special property of this window is that as long as it exists, the user can't access any other window. This also means, the user cannot close any other window.
Now while the user reads the message, another application has an important message, so it opens a window, using the same method as you to block access to other windows until it is closed.
The user cannot close the second window, because the first window is special and must be closed first. The user cannot close the first window, because the second window is special and must be closed first => the UI is completely locked. The poor user must use Task Manager to kill one of the two applications or reboot the system.
See also Raymond Chen's more detailed discussion of this principle.
Related
I have a WPF-application with multiple unrelated Windows, i.e. there is always one MainWindow and optionally many others with no owner.
If these windows get grouped in the taskbar, windows will provide the action "Close all Windows" in the taskbar context menu.
If it is clicked, each Window of my application gets an individual close-command in an order I cannot control.
Problem:
Some of my windows may ask before closing, if it's okay to cancel pending changes. This is annoying and confusing if there are many of those.
What I want is: If the MainWindow is asked for closing, I want to prompt once, if that's ok. If yes, all windows should close silently, otherwise stay open.
But my MainWindow is not the first one, to process the closing procedure.
I have already found out, that I probably need to check the Windows Message Loop of my MainWindow for some WM_SYSCOMMAND with wparam SC_CLOSE.
(see How can I distinguish between "Close All Windows" and "Close" individual windows in MFC with Windows 7?)
But how can I evaluate this, before I execute the closing-routine for any other window?
ComponentDispatcher.ThreadPreprocessMessage in my mainwindow comes too late, it fires after some other window has started the closing procedure.
This question is somehow related to this one:
Odd form closing behavior when using taskbar's Close All Windows
Personally, I would just leave things as they are. I can see how having several prompts to save/cancel changes could be annoying, but it doesn't seem confusing to me. And while annoying, it seems like a minor annoyance, and frankly one that might teach the user to not use the "Close all windows" option when they have left a bunch of these windows open. That said…
As the question you've found points out, there is no built-in way to distinguish the "Close all windows" from a regular "Close window" command. The system is simply sending the messages to the windows in sequence.
In MFC (i.e. the context of the other question), you can call AfxGetCurrentMessage() to retrieve information about what actually instigated the SC_CLOSE message. If it was user input that was translated to a close command, there will be some type of user input (keyboard, mouse, etc.) as the current message. Otherwise, you'll just see the WM_SYSCOMMAND itself.
But you can't apply the same approach in WPF, because WPF doesn't provide a GetCurrentMessage() method or its equivalent (as far as I know). The only access to window messages you get is to override the Control.WndProc() method, and by the time you get the close command, the most recent window message there will always be the SC_CLOSE.
It seems to me that the best you can do is use the WndProc() override to track incoming messages, so that you can reset a flag when non-close-command messages come in.
Then, when you get the close command and display the user prompt, you can check that flag. If it's set true, then you can ignore the prompt and just use whatever the user most recently selected. Since you're clearing the flag any time non-close-command messages come in, the first close command received will always display the prompt.
Another alternative would be pre-emptively close all the remaining windows. Here you'd still have the prompt have some kind of "apply to all other windows" option for the user, but instead of setting of just relying on the flag, you could actually close all the other windows explicitly.
Neither of these are ideal, from a user-interface perspective. The main problem is when the user tries to close just a single window. In the first approach, the user will see the "apply to all other windows" option in the prompt even though there won't be any other windows to close. The second approach is a bit more self-consistent, but adds a feature you may or may not want: the user can close all windows in the program any time they are closing just one window.
Neither of these behaviors are exactly standard Windows user interface behaviors. I.e. in trying to save the user some annoyance (and confusion, though like I said, I don't see that part being the case), you introduce what itself could be potentially confusing to the user.
Given that it involves additional work coding, and may simply exchange one annoying/confusing result for another, the best solution may be simply to not try to address the issue at all.
I have a WPF application, which needs to log out user after 5 min of inactivity.
But if user open a print dialog of any page, and do not touch screen for 5 minutes,
even if I log out user and clear all child elements, print dialog still stays on top of WPF form and somebody can come and continue to print what ever page user stayed.
I tried to use;
Window window = Application.Current.MainWindow;
or
FocusManager.GetFocusedElement();
but could not achieve to access to PrintDialog and close it.
Is there any way to access it and close if user did not respond to print dialog?
I fixed this weird problem by using
white project.
http://white.codeplex.com/wikipage?title=Working%20with%20window&referringTitle=Programming%20using%20white
By using application class, I am able to access all ModalDialogs in WPF project, and close them.
Application application = White.Core.Application.Attach(Process.GetCurrentProcess().Id);
private void dispatcherTimer_Tick(object sender, EventArgs e)
{
White.Core.UIItems.WindowItems.Window window = application.GetWindow("MainWindow");
List<White.Core.UIItems.WindowItems.Window> modalWindows = window.ModalWindows();
foreach (White.Core.UIItems.WindowItems.Window modalWindow in modalWindows)
{
modalWindow.Close();
}
}
You can use p/invoke for this.
Use findwindow to find any window and destroywindow to close it.
https://msdn.microsoft.com/en-us/library/windows/desktop/ms633499(v=vs.85).aspx
If I understand correctly, you're able to do the user logout at the 5 minute mark (I presume via the timer event handler), but if the print dialog was open, then the printout can still end up happening.
The question is, what's really the important thing here, closing the dialog, or preventing the subsequent printout? Also, are you logging out the user but keeping the program going, or is the program quitting?
If the app is supposed to shut down, then your code can call the Application object's Shutdown() method, which will close any modal dialogs as part of the shutdown process.
If the app is supposed to keep running without a current user, then I would think the White library is your best bet. It's unclear why you've moved away from this.
With or without closing the print dialog, however, the printing code should check to see if the user is still logged in before it actually prints something. If the login expired while the print dialog was on screen, the printing code should simply exit without printing anything.
Is there some way to watch for / intercept a window opening in Windows and then to block said window from opening? This would be for an application that's already running and I wouldn't want to stop the process, just close the popup window it spawns.
Update:
A process is already running (e.g. it's in Task Manager) but has no visible windows.
At some random time, that process will popup a window
I manually close the window (click "OK").
The process continues to run at this point and will, again, popup a window a bit later (repeating these steps).
I want to automate step #3, where I have to manually close the popup, by intercepting that window opening and closing it or hiding it or never letting it open in the first place. I don't want to do this by polling the open windows. I want to receive some event that a window is about to open.
I do not control this other application, so I can't otherwise change it. And I don't want to kill the process, itself.
If you're trying to do what I asked (allow only one instance of a program to run at a time), here is an elegant solution using a Mutex. You can probably copy and paste most of that code to achieve what you want.
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.
I have a PocketPC C# application written in Visual Studio 2005. It uses nested forms (the user is presented with a form with multiple buttons, when the user selects one a new form is opened).
I've added code so that the 1st form sets it's title to string.Empty to hide it from the Running Programs List. When the 2nd form is showing and the user uses the task manager to stop my app, the 2nd form gets the on close event.
Is there any way of knowing that the close event has come from the task manager so that I can close my application? At the moment when breakpointing the close event, I'm seeing the DialogResult being set as DialogResult.OK (Which isn't helpful) and the 2nd dialog is closed returning control to caller which thinks the user selected OK and opens the next dialog.
I've Googled for info but all the helpful code such as ClosingEventArgs aren't available in the compact framework. Any ideas?
I may be missing something but if your problem is distinguishing between the 2nd dialog being closed normally, and being closed using task manager, can you not set some kind of marker when the normal close action occurs, before closing? Logically then any close event where the marker has not been set will be down to the task manager?