Develop Reference

Faster way of searching for Top Level Windows in WPF CodedUI

I have several parts of my application that are supposed to close a window.
Checking that these windows have been closed using Coded-UI is incredibly slow. Right now my code looks like this:
Assert.IsFalse(UIMap.SomeWindow.TryFind(),
"X Window found when should be closed");
The problem is, this takes around 30s to search, and there are around 5 times this is used, and I have around 10 similar windows all being tested. I'd like to trim this time if possible, as it's making my tests slow.
I have also tried a dynamic solution (which is basically identical to the UIMap implementation):
var window = new WpfWindow();
window.SearchProperties.Add(UITestControl.PropertyNames.Name, "Window Title");
Assert.IsFalse(window.TryFind());
This is just as slow. It would be nice to use ApplicationUnderTest as a search parent, but as the window is Top Level, it doesn't seem to work.
Surely it shouldn't be too hard just to look at the open windows on my system (5), and check their titles against the search parameter?
Edit: Using SearchConfiguration.VisibleOnly doesn't seem to help either.

Found my answer, surprisingly on LinkedIn.
Now using:
Playback.PlaybackSettings.SearchTimeout = 1000; //in ms
Playback.PlaybackSettings.ShouldSearchFailFast = true;
Source: https://www.linkedin.com/grp/post/3828241-5843659258196959234
(C&P):
//Search Settings
// Value is in milliseconds. Default search timeout is 2 minutes.
// The search engine will continue making passes until the timeout has expired
// or the window has been found.
settings.SearchTimeout = 10000;
// Default search will make 3 attempts.
// If true the default 3 attempts is applied. If false then only one attempt should take place.
settings.ShouldSearchFailFast = true;

I think there might be a better answer. If set a global configuration like that and have to deal with a WPF Table and find a specific cell you might not find it working.
Using Window name generally isn't a great idea if there is any dynamic titles, Control Name is a good constant. It sounds to me like you are passing bad SearchProperties. You can use DrawHighlight() to see if CUI is actually finding your controls. First pass in the main parent window to your close window method, then use it as a try.
public static WinWindow _mainParent(string MainParentCtlName)
{
var _mainForm = new WinWindow();
_mainForm.SearchProperties.Add("ControlName", MainParentCtlName);
return _mainForm;
}
public static void CloseWindow(string MainWinCtlName)
{
var close = new WinButton(_mainParent(MainWinCtlName));
close.SearchProperties.Add("Name", "Close");
Mouse.Click(close);
}
try
{CloseWindow("MainWindowForm")}
catch{}

Order of WindowHandles

I'm encountering an issue where WebDriver seems to change the order of WindowHandles. This causes us to close the wrong one intermittently after getting them in some cases.
What seems to happen is the previously established first window handle is returned as a subsequent handle, which causes my logic to of course, close the wrong one.
Is WebDriver supposed to return the window handles in the same order every time (order of first opened window to last?). This is what I initially expected, but now I'm not so sure.
I should also mention the problem seems to only occur in IE right now, but I'm not certain if this is a more generic issue.
Here is how I'm closing the active window and switching back to the root window.
public void Close()
{
//switch to latest window
string windowName = string.Empty;
if (_driver.WindowHandles.Count > 1)
{
//get 'root' window in list
windowName = _driver.WindowHandles[0];
_driver.Close();
_driver.SwitchTo().Window(windowName);
}
else
{
_driver.Close();
}
}
We're on WebDriver 2.45 (C# bindings, 32-bit IEDriver). If there is a method to close the active window in the C# bindings that would most likely solve this issue as well.

This pop up window handler is entirely unordered as per my understanding. I remember having same conversation on SO and luckily JimEvans(one of the contributors of Selenium) chimed in and clarify few factors. I read about the PopupWindowFinder of Selenium .NET bindings and found that class can make your life lot easier. API is here. However, the whole order issue is entirely complex and painful to deal with. See this thread. Just don't want to reinvent the wheel.

Send fast textinput to another process (Window)

I am writing a C# WPF program which sends text messages to another program's window. I have a macro program as part of my keyboard drivers (Logitech g15) which already does this, though it does not send keystrokes directly to the process, but to the currently focused window. It works well but i need to be able to send inputs from my program as well. There are other people using the process so the input text messages from my program needs to be fast enough so that my text does not interfere with their input.
The problem is that when I try to do this with a c# program I get too much delay. The macro program (Logitech G-Series Profiler) sends a command instantly. I have tried the following three commands for sending messages to process. (Listed by order of slowest to fastest)
SetForegroundWindow(_hWnd);
SendKeys.SendWait("{Enter}This is a keystroke input.{Enter}");
It is probably in the name, but this performs the command so slowly that I can actually follow with my eyes the text as it is input letter by letter. I have tried using the “SendKeys.Send” method but I get an error saying: “SendKeys cannot run inside this application because the application is not handling Windows messages.”
PostMessage((IntPtr)_hWnd, (uint)WMessages.WM_KEYUP, (int)key, (int)key);
PostMessage is a bit faster but still not fast enough for the purpose of my program. Besides the method returns before the message has been read by the process, which means two sequential PostMessage calls may not send sequential messages.
SendMessage(_hWnd, 0x100, (int) VKeys.VK_2, (int) VKeys.VK_2);
This is faster than the PostMessage but not nearly as fast as the macro program from Logitech. Also, the receiving program handles the input strangely, apparently not treating it the same way it does "genuine" input from the keyboard.
SetForegroundWindow(_hWnd);
const string text = "This is a keystroke input.";
IInputElement target = Keyboard.FocusedElement;
IInputElement target = InputManager.Current.PrimaryKeyboardDevice.FocusedElement;
var routedEvent = TextCompositionManager.TextInputEvent;
target.RaiseEvent(new TextCompositionEventArgs(InputManager.Current.PrimaryKeyboardDevice, new TextComposition(InputManager.Current, target, text)) { RoutedEvent = routedEvent });
This is the last thing I have tried. It seems instant with the way the text is sent to a process. However, I have only been able to send this to my own program since Keyboard.FocusedElement returns null when I have another program set as foreground window.
If someone can tell me how to get an IInputElement of another window I would sure like to know. Alternatively, if someone has a suggestion for a better method of sending input, I would dearly like to hear it.
Specs: Windows 7, 64bit
Visual Studio 2010, Framework 4

First of all, are you intentionally using WM_KEYDOWN (0x0100) instead of WM_KEYUP (0x0101) in your SendMessage example? This would just press the keys, and never release them, so the application would not process them properly.
Another way worth trying would be to send WM_SETTEXT, assuming the control interprets it correctly (like edit controls or combo boxes).
A last option would be to use SendInput which synthesizes keyboard and mouse input on a very low level, but similarly to you keyboard's macro program, this requires you to activate the correct window and set the focus, which can be quite painful.

Depending on your other's program window type, you could use UI Automation. See this example here:
Add Content to a Text Box Using UI Automation

How to make form system modal using C#?

I need to show form as top level system-wide, e.g. over /all/ other windows on screen. I do realize this is usually /bad UI practice/, but I have very specific scenario in mind.
We intend to use normal Windows PCs for POS cash registrators. There is an option on the screen to open cash drawer. It would be rather bad for someone just to press something on a screen and get access to money when clerk isn't looking. So we equiped PCs with RFID readers and each clerk has his/her own RFID card which will be used for authentication.
I need however an mechanism to lock the computer (or make it unusable) when clerk goes away. Logging off seems too much of a nuisance.
Any ideas welcome.
LP,
Dejan

Well, after a day of trial and error I came to sort of solution.
It involves the following steps:
1.
When "Lock" button is pressed new (empty) /desktop/ is created.
Program is run in this desktop with full screen form and login procedure.
There is nothing else to switch to or run on this desktop.
2.
Task manager is disabled via registry.
Of course, somebody uninvited can still access the Ctrl-Alt-Delete menu, but there is nothing of particular harm he can do there.
3.
Alt-F4 and such are disabled.
4.
When authentication is made, program switches back to original desktop and everything proceeds as normal.
There is some P/Invoking required, of course.
If someone wants to do something similar, perhaps s/he will find my bare bones example helpful - link text
LP,
Dejan

I think you'll need to look into calling down to the Win32 API to achieve this.
You'll need to look into:
ShowWindow
and
SetWindowPos
and invoke them with code similar to the following (note this is pseudo-code):
[DllImport("user32.dll")]
static extern bool ShowWindow(IntPtr hWnd, int nCmdShow);
static void ShowTopmost(Form frm)
{
ShowWindow(frm.Handle, SW_SHOWMAXIMIZED);
SetWindowPos(frm.Handle.ToInt32(), HWND_TOPMOST,
0, 0, [width of desktop], [height of desktop],
SWP_SHOWWINDOW);
}

Form has a TopMost property.
set Form.TopMost = true

What is the proper way of handling logoff / shutdown / restart when the application has unsaved data?

In WPF App.Current.SessionEnding must return in a few seconds, otherwise the "application does not respond" window appears. So the user can't be asked in this event handler to save his data, because the user's response takes longer than a few seconds.
I thought a solution would be to cancel the logoff / shutdown / restart, and resume it when the user answered to the file save dialog.
ReasonSessionEnding _reasonSessionEnding;
App.Current.SessionEnding +=
new SessionEndingCancelEventHandler(Current_SessionEnding);
void Current_SessionEnding(object sender, SessionEndingCancelEventArgs e)
{
if (_dataModified)
{
e.Cancel = true;
_reasonSessionEnding = e.ReasonSessionEnding;
Dispatcher.CurrentDispatcher.BeginInvoke(new Action(EndSession));
}
}
void EndSession()
{
if (SaveWithConfirmation()) // if the user didn't press Cancel
//if (_reasonSessionEnding = ReasonSessionEnding.Logoff)
// logoff
//else
// shutdown or restart ?
}
The problem is that ReasonSessionEnding does not tell me if Windows was shutting down or restarting (it does not differentiate between the two).
So, what should my program do on the session ending event ?
Should it even do anything, or doing nothing on this event is the standard ?
The user is asked to save his changes in my main form's OnClosing method, so he does not lose data, but I think that the "application does not respond" window does not suggest a normal workflow.
Canceling the shutdown is not desired I guess, because some of the other programs have been shut down already.

What seems to be the accepted way is to display the save as dialog regardless.
Cancelling the shutdown, then resuming it later is most certainly not an option, for the reason you state and various others.
Since simply discarding the data is unacceptable, there really is no other options.
Well, except to save the data to a temporary file, then automatically restoring them the next time the program is run. Rather like MS Word after it has crashed. Actually, the more I consider it, the better it sounds.
Edit: There's yet another avenue, namely to save continously, the way eg. MS OneNote does. What has struck me before is that, provided you implement decent multilevel undo in your application, the whole manual saving business is actually somewhat dated - an anachronism from the days when disk operations were expensive and error-prone, nowadays mostly old habit.
But I'm digressing. Anyway, it's probably not applicable to your application, since I imagine it needs to be implemented from the beginning.