I have trouble to make UI Automation of the Child Windows. I cannot trace any element inside any child window in the project. I am using UISpy. I set AutomationProperties.AutomationId for all of items inside ChildWindows.
I am hoping to find the answer on thos topic. There is no much documentation on it or I was not able to find it. Any sample or ideas are highly appreciated!
There isn't good automation support for Popups in Silverlight at this time. Popups are not considered part of the main visual tree, so they are effectively disconnected. ChildWindows are shown in a Popup, so they are effectively disconnected as well.
Here is one possible solution, which basically tracks the popups/child windows and injects them as automation children of the parent page.
Apparently, Telerik also has a solution for their test suite, with a video here.
Related
I am trying to automate an app using AutomationElement or TestWhite/FlaUI, the problem is snoopWPF seems the only one that is able to see the elements inside the window due to its injection feature (spy++ or inspect.exe do not see the visualtree).
Is it possible to use snoop code to automate a button click on a windows? any examples? thanks
Probably a simple question I am sure. So I've created a simple CefSharp browser on a WinForm.
The problem is - when the browser has focus all the menu mnemonics on the parent form are disabled (e.g. "Alt+F" for the file menu, etc)
I have KeyPreview set True on my parent form - is there some setting I need to disable/enable on the browser object to have it pass mnemonics/accelerators/shortcuts up to the parent form?
Turns out - my problem was not related to CefSharp.
I implemented the IKeyboardHandler and that didn't help either. I could see where the handler was reflecting calls back to the parent - but still I didn't get the response to my hotkeys on my menu.
That is when I started looking elsewhere and realized that the Telerik RadMenu I was using on the form did not support Mnemonics. (Off topic: Telerik controls are cool but beware, there are a lot of little bugs like this lurking in them. For the money they charge you wouldn't expect this.)
Solution was to dump Telerik RadMenu and just use a WinForms Menu and problem solved!!
I'm now writing an Win32 SDK application. I need to create a modal child window for select from several options. My design is: Simply display them on the child window, if user press key 1, the 1st options is selected. other options are the same. After selection is made the child window close self automatically.
My problem is, is there a simple way to create such a child window? I have found two ways, both with some boring steps.
The first way is to create a dialog resource and use DialogBox function. It can easily create a modal child window. But since it is a modal dialog, system has filtered out all keyboard messages. I need to use some special tecs, like message hooking or something, to get these messages.
The second way is to register a class and directly call the CreateWindow(Ex) function. It can easily create a window with keyboard messages. But it seems to set it as a modal dialog is boring. I need to manually disable the parent window, set child window foreground, create a complete message loop for this window, and manually enable the parent window after it destroyed.
I have searched for a simple way to create a window with both of these 2 features. However found no clue apart from these 2 ways above. I'm not sure if this way exists. Can anyone tell me? My thanks for replies.
In my opinion working with the Win32 SDK is really complicated especially when you are creating a GUI (normally even creating a simple window can be challenge). Therefore would recommend the following to you:
Microsoft has a very neat API called MFC that comes with Visual Studio (I don't know if you can use MFC outside Visual Studio) and that has several C++ classes that wrap the Windows SDK methods, making things a lot easier for you. Furthermore Visual Studio lets you use a drag and drop interface to create your GUI (which I find really useful).
You can use a third party API to create your GUI elements like GTK or QT. Both are written in C/C++ and are very good APIs. Hopefully they will make your life easier when designing GUIs.
If using C/C++ is not a requirement for you, then I would strongly recommend that you use a higher level language like Java or C# to develop your application. I think that designing your GUI with them should prove a lot less troublesome that doing the same thing in C/C++.
I want to create an automated UI test that will test my syncfusion grid. My problem is that the recorder can't recognize this control (or any syncfusion control). I've searched a lot in the internet but I couldn't find any extension so the recorder will recognize my controls (I'm using WinForms, not WPF!), or at least a way to extend the recorder abilities so syncfusion's controls will be recognized somehow.
Is there any easy way to extend the recorder? Or is there any extension available?
Or maybe can I get the grid object from the WinClient that the recorder generates?
Thanks!
Start your program. Run the Spy++ utility. Type Ctrl+F to start the finder tool and drag the bulls-eye onto your form. Ok, Synchronize and have a look-see at the windows that are visible in the tree. If you see regular Windows Forms controls, like a Button or a Label, but not any of the SyncFusion controls then you've probably found the source of the problem.
Component vendors that try to improve .NET controls typically do so by creating 'window-less' controls. They are not really controls, they don't derive from the Control class and don't have a Handle property. They use the surface of the parent to draw themselves, making them look just like controls. The .NET ToolStripItem classes do this. And this is also the approach WPF uses.
The big advantage is that they render quickly and support all kinds of effects that regular controls can't support, like transparency, rotation and anti-aliased window edges. The big disadvantage is that the kind of tool that you are using suddenly gets noddy and can't find the control back. Because they work by finding the Windows window back on your form, there is no window for them.
This is a hard problem to solve, the 'control' exists only in memory and there's no good way for a tool to find it back. Using Accessibility is about the only other way for such a tool to find a control that I can think of. Which would have to be implemented by the control vendor first, a somewhat obscure feature that gets easily overlooked. You really do need the help of the vendor to find a workaround for this. Shouldn't be a problem, that's why you paid them the big money.
This is Rajadurai from Syncfusion. Thank you for your interest in Syncfusion Products. To make UI Test Automation recognize Syncfusion grids(WinForms), some internal support need to be provided in grid whose implementation is in progress and about to be completed. Please submit an incident through Direct-Trac for any further related inquiries in the following link.
http://www.syncfusion.com/Account/Logon?ReturnUrl=%2fsupport%2fdirecttrac
You can also contact us through support#syncfusion.com. We are happy to assist you.
Regards,
Rajadurai
When hosting WPF user controls within a WinForms MDI app there is a drawing issue when you have multiple forms that overlap each other that causes very distinct visual artifacts. These artifacts are mostly visible after dragging one child form over another one that also hosts WPF content or by allowing the edges of the child form to be clipped by the main MDI parent when dragging it around. After the drag and drop of the child form is completed the artifacts stay around generally but I've found that setting focus to a different application's window and then refocusing back on to my application window that it is redrawn and all is good again until the child forms are moved once again. Please see the image below which demonstrates the problem.
Those at Microsoft insist that the WinForms MDI is already a sufficient solution for MDI and doesn't need reinventing in WPF although I find it hard to believe they tried creating a WPF app this way because of the obvious shortcomings.
UPDATE: A few extra notes that I left out is that if I create these Forms without setting the MdiParent they are created as regular forms and this issue doesn't happen. This issue seems unique to the WinForms MDI scenario. Also I've currently running on Windows 7 Enterprise and I'm aware the results may be quite different on Windows XP but I haven't been able to test this.
UPDATE: I've found a few other related resources on this issue that I thought I should share.
elementHost repaint problem in MDI
application
elementHost repaint problem in MDI application on Tech Archive
It appears that another workaround is to revert to software rendering as opposed to taking advantage of hardware acceleration. This was the suggestion by Marco Zhou on the MSDN Forums.
public partial class UserControl1 : UserControl
{
public UserControl1()
{
InitializeComponent();
this.Loaded += delegate
{
var source = PresentationSource.FromVisual(this);
var hwndTarget = source.CompositionTarget as HwndTarget;
if (hwndTarget != null)
{
hwndTarget.RenderMode = RenderMode.SoftwareOnly;
}
};
}
}
I've tested this and this solution seems to work very well and so far is the only solution that I've found for solving this problem within a FoxPro interop scenario which is very similar to the WinForms one I posted about originally. For now I'm planning to use my original Refresh on the MDI Parent solution for my WinForms project but then for my other native interop applications such as when my WPF controls are hosted in Visual FoxPro I'll use this solution. That is unless of course if a more elegant solution is discovered for either of the cases.
Also it's important to note that from what I'm aware software rendering is the only option on XP systems and normally Visual FoxPro nore WinForms normally take advantage of the same type of hardware acceleration that native WPF apps do on Vista OS and up. So using this option may not be as bad as it sounds when you do have to deal with interop. Currently I'm not aware of any related side effects when using this solution but if there are any those would have to be taken into serious consideration.
Well, I may have found a solution although it feels like a bit of a hack. It appears that if you call the Refresh method on the MDI parent whenver a child MDI Form is moved that the noted artifacts go away. Visually things appear a bit jittery when dragging a window but it seems much more acceptable than the example I showed in my original post.
private void Form1_Move(object sender, EventArgs e)
{
this.ParentForm.Refresh();
System.Diagnostics.Debug.WriteLine(string.Format("Form Moved to: ({0},{1})", this.Left, this.Top));
}
I've tried many combinations in the same vein such as refreshing just the child window that was being moved by calling methods such as Update(), Invalidate(), Refresh() and also I've tried these same methods on the MDI parent as well as Dispatcher.Invoke(DispatcherPriority.Render, ...) and InvalidateVisual() on my hosted WPF control but none of those other methods worked accept for calling Refresh() specifically on the MDI parent.
I realize that this probably isn't the optimal solution since I'm forcing the whole main application window to refresh every time a child window moves a few pixels but as for right now it's the only reasonable solution that I found that works. If anybody else has any alternative solutions or any improvements upon this I will gladly accept your answer instead.
Check video drivers and try disabling hardware acceleration. Most artifacts are caused by bad drivers, failing video card, or insufficient time to complete the refresh.
First troubleshooting step: Update video drivers. Obvious, I know.
I had similar issue, checking my video card settings (NVidia Control Panel) showed global setting set very high causing a longer refresh interval which may be aborted if taking too long. Setting my settings back to defaults resolved most of the issue. But I also run hashing programs which use the GPU intensely so this is likely the cause of my remaing artifact issue which is very seldom now and mostly shows its ugly face in Visual Studio.
Another troubleshooting step I ran across is to disable hardware acceleration for WPF, this can be done in 'HKEY_CURRENT_USER/SOFTWARE/Microsoft/Avalon.Graphics', or maybe an application can do it BUT this is only for troubleshooting; never set these within an application because it will disable for ALL WPF applications. I do not have this registry setting nor did I add it so I am not sure of the success with it, but many say this resolved their issue. Also note some applications have this option available, try disabling it if available.
Another troubleshooting step is to make sure the video card is a proper tier level for rendering. Any card that supports DX9 or greater should be sufficient, but other factors are involved (as is my case) so just because it is on the list does not mean it is adequate for your purpose.
Finally, you can use the Visual Profiler (part of Windows SDK), and other tools, to help determine what is going on more precisely with WPF lacking performance in relation to graphics ability.
Rendering Tier level notes and WPF Performance information --> http://msdn.microsoft.com/en-us/library/vstudio/ms742196(v=vs.90).aspx
Hope this helps someone.
--Ryan Strassburg
Your usercontrol or window loaded event ;
this.WindowState = System.Windows.WindowState.Minimized;
this.WindowState = System.Windows.WindowState.Normal;
it may seem bad solution. no need to hit your head against the wall.
A Turkish proverb says: the best code is the code is running :)