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.
Related
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.
I know this issue has been addressed a lot, but I haven't found a problem similar to mine, so please tell me if there's a solution.
I'm using selenium webdriver (chrome) and C# to test a web application.
In the application I have a button, which opens a windows file dialog in order to select and upload the file.
I am using Click() to click on the button and SendKeys() to paste the file's path in the windows dialog and to hit "Enter".
I'm not trying to control the dialog with selenium.
It's successful most of the time, but sometimes the dialog isn't opened once the button is clicked and it seems to be frozen for several minutes (it's impossible to click the button manually as well), but the test resumes as if the dialog had been opened. After 2-3 minutes the windows dialog finally appears, but needless to say that the entire test is messed up.
It is not a problem in the program itself, as the problem never occurres when the click is preformed manually.
What could be the problem and how can I solve it?
Please have in mind I cannot change the program I'm testing.
Thank you
You can do it without White using Microsoft UI Automation directly.
Without TestStack White. No sense to use the whole library for one window automation. White is wrapper only.
var FirefoxWindowElement = AutomationElement.RootElement.FindFirst(TreeScope.Children, new PropertyCondition(AutomationElement.ClassNameProperty,"MozillaWindowClass"));
FirefoxWindowElement.FindFirst(TreeScope.Children, new PropertyCondition(AutomationElement.ClassNameProperty,"#32770"))
//You can navigate directly to input field or just use the keyboard because input field is always focussed
SendKeys.SendWait("YOUR FILE PATH here");
Keyboard.Press(Key.Return);
What if you create a wait for dialog?
public void waitForElement()
{
while(!yourDialogElement.Displayed)
{
yourButtonElement.Click()
System.Threading.Thread.Sleep(1000) // sleep for 1000 milliseconds
}
}
You will probably want to build a try/catch into that button click, and perhaps build a counter into your loop and pass a timeout limit.
Let me know if this works or if you need more help!
You should consider adding a library called WHITE to your framework. This acts like Selenium but for Win32 applications and can handle most types of Windows dialog objects via Microsoft UI Automation.
With WHITE set up, you can add a method at the point in your code where the button is clicked by Selenium that opens up the dialog window. This method can poll for the presence of the dialog and if, after a set time, the window does not appear you could either fail the test there and then or try clicking the button again.
You could also poll indefinitely until the window appears if you are confident it always will. I would set an upper limit myself though to 5 minutes or whatever you feel is right here to prevent some sort of infinite loop situation.
I'm writing a multi form application, and I'd like to be able to close Form1 with out the application closing.
Right now i'm using this.Hide to hide the form. Is there a way to set it so i can close any form, or the application should only exist when all the forms are closed?
I think i remember seeing something like that at one point, but that might not have been visual studio and c#.
In your Program.cs file you have a line like Application.Run(new Form1()). Replace it with
var main_form = new Form1();
main_form.Show();
Application.Run();
Also you need to close application explicitly by call Application.Exit() where you want.
One strategy is to do something like the following:
private void Form1_FormClosed(object sender, FormClosedEventArgs e)
{
if (Application.OpenForms.Count == 0)
Application.Exit();
}
}
If you place this on all of your forms, when the last one closes, the application will exit.
A multiform aplication should have a clear EXIT option (either by menu, toolbar), since you can not know that the user wants to close the program when the last window is closed (i supose that the user could go to the File/Open and open new windows)
An aplication that does something automatically that the user did not asked for can used frustration/confusion and spend time reopening the aplication.
Even the user can think that the application somehow crashed since he did not close it.
Based on your coments it's a single flow kind of application
I suggest that you implement the typical wizard interface on a single form with the BACK, NEXT, CANCEL buttons.
When the desired state has been reached, for example enough information has been gathered , the NEXT button is changed to a FINISH button.
Any time the user presses the CANCEL/FINISH button the window will close
And if you still want multiform you could still have it, in this you could have multiple flows at the same time and just finish or cancel the one that you want.
The Questions:
Has anyone seen invoking of one modal dialog from another modal dialog cause the modality to get undone?
If you wanted to make a call with ShowDialog so that you get back a result, but without it being modal (other Forms still respond), how would you do it? (We're not trying to do that... but if there is a way to do that, maybe we're doing that accidentally.)
The Details:
We have implemented our own Print dialog that has buttons that bring up the standard PrintDialog, the standard PageSetupDialog, and the standard PrintPreviewDialog. And the printing is all done with our own PrintDocument class derived from the standard PrintDocument class. So, we're trying to follow the standard practices... we just have a few extra settings that we need the user to start with.
We invoke our Print dialog from a menu using ourPrintDialog.ShowDialog(mainWindow). When it comes up, it is properly modal (all other windows are non-responsive... in particular, that mainWindow). From that Print dialog, there are buttons to invoke each of the other three dialogs... and all are invoked with ShowDialog(ourPrintDialog), making that first Print dialog as its parent. In the case of the PrintDialog and the PageSetupDialog, they come up modal (mainWindow and ourPrintDialog and all other windows are non-responsive). And when we OK or Cancel those, it returns to the first Print dialog (ourPrintDialog) which is still modal (no other windows respond).
However, in the case of the standard PrintPreviewDialog, although we invoke it the same way (ShowDialog with the first dialog as its parent), it comes up not entirely modal. Our main window becomes responsive again. So, you can start manipulating the underlying document that the Print dialog is in the process of printing... which of course violates many assumptions. And when you close the Preview dialog, returning to the original Print dialog, it is also now not in a modal state... the main window is still responding.
We have tried doing this in a plain test app, and it works fine... the modality is not broken when going into the PrintPreviewDialog. So, it seems to be some specific interaction between the PrintPreviewDialog (since it doesn't happen with the other two) and our app's main window (since it doesn't happen with the test app). Any suggestions on what that might be? (And hence my two questions above.)
Thanks in advance for any suggestions!
Not sure why it's happening , but you might try running Spy++ on the windows and watch the messages that flow, might give you a clue as to what is happening between the windows, or the properties of the windows in question.
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?