We need to automate GUI testing of an application developed in Win32 API. Developer's have created this application by custom painted controls. They have controls which look like Grid, Buttons etc., but they are not basic Windows controls.
What is custom painted controls? and how we can test these controls?
Test it just like any other UI: Not at all. Move all code out of the callbacks into the application layer where your unit tests can execute them just like any other method.
Rationale: There is little point in testing whether "button.activate()" works; you want to know whether the your code behind the button callback works.
If you need to know whether the correct dialogs, etc., are opened, see my blog: Testing the Impossible: User Dialogs
Have the developers added support for accessibility using IAccessible? If they have, you can use active accessibility to navigate through the controls and test them that way.
If they haven't, open a bug that says that their controls can't be use by disabled people (who need a screen reader or other accessibility aid).
Once they fix that bug, you can use whatever mechanism they added to their controls to allow them to be used by screen readers and other accessibility aids to test their UI.
Related
We are working on an Windows Desktop application that pulls values from other controls on other applications. What we have works great for most desktop applications. I have noticed that some controls don't show up in inspect and Spy++. For example, in GP 2015 client only a handful of the controls are addressable in Spy++ and Inspect. The large majority wont show in the repective tree in Spy++ or Inspect. What type of controls don't show in Inspect and for extra credit, how can we talk to them?
Thanks in advance,
Steve
Spy++ only works with controls that have an HWND associated with them.
Inspect only works with controls that are exposed to UI Automation via the IAccessible, IUIAutomation, and other related interfaces.
So, any custom-made non-windowed non-automatable control will not appear in either tool. Such controls are not available to the outside world, so you cannot communicate with them, or manipulate them. Only the owning app can, since only it has knowledge of what they are and how to interact with them.
I am new to windows phone (WP7) and to me it looks like everything on WP7 is about pages. I want a small window to pop up from the bottom of a page while staying on the same page. The small window will have some controls (like slider, list etc.). It should not behave like a modal dialog box though, i.e. the rest of the page (which is not covered by the small window) should still be active and user should be able to do something there. And I want to have a separate C# class which will handle the events from the controls on the small window.
This is very easy on iPhone, using view controllers, is there something similar on windows phone?
It sounds that it would make sense to make your "pop up" part of the page with the content it is intended to manipulate content on that page. If you want to encapsulate the functionality of the "pop up" you could make it a UserControl. If you went this route then animating it to slide onto the screen will be straightforward.
Windows Phone 7 typically uses an MVVM model compared to iPhone's MVC one for app structure. The direct comparison therefore isn't appropriate. WP7 also uses a very different design language to that of the iPhone and so a straight port of application design and layout is also unlikely to create a great experience on WP7.
I'd recommend taking some time to understanding the differences in the platforms and how your existing design would be best suited to recreation on WP7. Not only will this help you create a better experience on WP7 but enable to see if this your question actually relates to something you should be doing or not.
This very much sounds like something that goes against the nature of the platform, and the general design guidelines.
If you're providing some available configuration options to the user, you should do it on a separate page, so the user can change the settings there, approve it, and then be navigated back to the previous page.
However, if you really want to, you're talking about displaying a UserControl inside a Popup. But it wouldn't be a very good user experience, and confuse most users, as it doesn't follow the same look&feel as the rest of the platform.
I have built a wizard style user control that lets you add stackpanel based pages and flick between them.
I would like to add an application bar as part of the user control with next and previous buttons that enable/disable based on page displayed etc.
Application bar appears to be an attached property of PhoneApplicationPage. I have tried referencing Microsoft.Phone.Shell but get invalid type.
Any ideas how I can add it to my user control?
Application bar is such a pain in the a**. This control is not a Silverlight one but a native one. Maybe you can be more lucky with this solution:
http://blog.humann.info/post/2010/08/27/How-to-have-binding-on-the-ApplicationBar.aspx
The ApplicationBar is a service that is provided by the operating system, i.e. not part of the Framework, and can only be used at the page-level, not in your UserControl. In addition, the ApplicationBar does not support regular bindings as you've seen. As mentioned above there are a number of solutions that provide workarounds for this problem.
Alternatively, you could use the ApplicationBarButtonCommand and ApplicationBarButtonNavigation behaviors from the Silverlight Windows Phone Toolkit. It's a simple enough task to create your ApplicationBarMenuCommand if you need one.
Valve's game manager application, Steam, has a very unique user interface, with custom buttons and windows. How would you create a Win32 application that has such a look?
Pretty much every windows common control supports custom and/or owner draw (not the exact same thing), that just leaves the dialog itself where you can customize its look by handling WM_ERASEBKGND and WM_PAINT or WM_NCCALCSIZE,WM_NCPAINT (If you don't want native titlebars and border etc)
As you can see, to do a custom GUI requires you to paint every control yourself... (And keep in mind that a lot of people hate skinned apps and would rather just have a native looking app)
I have a custom control: it's managed code, which subclasses System.Windows.Forms.Control.
I want to add things like edit boxes, selection lists, combo boxes, radio buttons and so on to places on this control. An easy way to do this is to simply add instances of these classes to the Controls collection, so that they become child controls.
Adding them as child controls might create some subtle problems, for example:
IE 6 select controls(Combo Box) over menu
I have scrollbars on my control which appear to scroll the contents of the control (the contents are bigger than the control itself); when a child control is near the edge of the screen then I'd like to half-display (i.e. clip) that child (i.e. to have half of it located off the edge of the physical screen), but a true child control cannot be located outside the border of its parent.
Are there other potential problems?
When I use IE7 to display http://www.tizag.com/htmlT/htmlselect.php (for example), which contains combo boxes etc., and when I then use Spy++ to spy on IE7 when I'm doing that, I see only a single Window/control instance with no children (whose class name is "Internet Explorer_Server").
I'm guessing this means that in IE7, the functionality to render a combo box is built in to the IE7 control itself, and that IE7 does not use standard controls as child controls.
Questions:
Is it better to reuse standard controls as children of a custom control, or, to reimplement the functionality of standard controls within a custom control itself?
Do you have any caveats (warnings) to share, related to either scenario?
If I wanted to reimplement the functionality of standard controls within a custom control, do you know of any existing code (which implements this functionality) that I could re-use?
If such code already exists, I don't know how to search for it (my searches find, for example, owner-draw combo boxes, and extensions to standard combo boxes): perhaps few people reimplement the standard controls from scratch?
Edit
I found a semi-related question: How to render a control to look like ComboBox with Visual Styles enabled?
Yes, Internet Explorer draws the controls using the Windows theming APIs. You can do this too using the types defined in the System.Windows.Forms.VisualStyles namespace.
The IE team did this to avoid performance problems of having so many controls, each receiving window messages, on screen at once. For example, looking at this StackOverflow.com page, I see 30-40 link label controls, 10 buttons or so, 20+ labels, etc.
It should be noted the Zune software, which is .NET managed code, also uses custom controls; if you try to use Spy++ on any of the controls, you'll see they aren't real Win32 controls. You may use Reflector on the Zune software to see exactly what they're doing. If I recall right, they're using a custom managed UI framework that's included in the Zune software.
As far as rewriting these controls from scratch, I think there's a ton of work to be done. It sounds easier than it really would be.