I'm developing an application that both run as a standalone application and a plugin. We're using dependency injection to inject different implementations of the application logic.
The GUI in the standalone application and the plug-in is identical today, but we're seeing a need to do minor customizations to the GUI depending on the context. This is typically small changes, like providing different input mechanisms (e.g. a drop down list in the standalone version and a hierarchical selection control in the plug-in version). Typically the controls used in the plug-in version will be controls provided by the plug-in API.
Since there typically will be many small differences between the standalone GUI and plugin GUI rather than big components (e.g. buttons rather than pages in a tab panel) we do not wish to create one XAML for the plugin and one for the standalone sharing a common view-model.
Are there any patterns for injecting user controls in WPF?
Prism! :D it is a framework for MVVM/ dependency injection and WPF/Silverlight
See http://compositewpf.codeplex.com/ and Composing the User Interface
Related
This is a question about design approach. I have limited COM experience and a little WCF experience. My constraints are given by the application environment, but I have some design flexibility.
From within a VB6 dll, I need to start, and communicate with, a WPF application. The WPF application is currently an exe, but I could make it a library if that helped. I would like to provide two way communication between the VB6 dll and the WPF application. I have some flexability to adjust the design of the VB6 dll.
I'm developing C# using in VS2010 and .NET 4.
How many components should I use? Can I start the WPF application In-Proc with the VB6 dll? Should there be a third component between them? Can COM+ play a helpful role? Do I have to make the entire WPF application COM-visible? Is there a down-side to doing this?
I'm looking for a design approach that I can prototype. I'm willing to research the details.
I would
Create a Web Service from the WPF application, using WCF. I would abstract out those aspects of the WPF application which should be accessed remotely. This would explicitly not include any of the user interface code.
I would create a simple class library project, and use "Add Service Reference" to add a reference to the WCF service.
I would make the methods of the class library COM-visible
I would call those methods from VB6
This has the benefit of removing any considerations of user interface from the equation.
Out of the options available I like the COM option more than the 'start another process' option for the simplicity that the inter 'application' communication will be via method calls rather than WCF or anything similar.
I am assuming that your VB DLL lives in a window'd process and not a service or web application. You would only need to mark any exposed types as COM visible, that is the classes, their argument and return types.
You may have to wrap your WPF UI inside the windows forms ElementHost [1] but I'm not sure, try it and see.
I'm not sure if you saw this [2] in your search, it sounds do-able but unsupported, ok as long as you don't have too much going on.
[1] http://msdn.microsoft.com/en-us/library/system.windows.forms.integration.elementhost.aspx
[2] http://social.msdn.microsoft.com/forums/en-US/wpf/thread/7555ba6a-1359-4dfe-aa23-c31a8f121142/
I work on an application primarily written in VB6 but most of the recent code is written in .net with UI components built in WPF and some WinForms. Datasources for this application are WCF, MSSQL server, and a propritary unix based server. All the WCF calls are made from data access components referenced by the .net UI components.
You can host WPF in VB6 windows or other container controls. Start by getting the Interop Forms Toolkit and build shell user controls to host your WPF controls.
To be able to host WPF in these controls you need to build a WinForms usercontrol which contains a ElementHost, which you can set the content to your WPF usercontrol.
WPF Usercontrol inside an Element Host inside a
WinForms usercontrol inside a VB6 usercontrol or
window
The interop toolkit will want to build VB.Net code but you can do it in C#, although I have not tried this. The usercontrols created by the interop toolkit will be exposed as COM components which you can reference VB6 by adding them as components via Project > Components and then you will find them in the toolbox.
In terms of data sources (WCF, databases) etc, you should build all your data access in .net components referenced directly from the UI components, don't try to call back in to VB6 libraries, you will probably just create a mess.
In my application I also have a configuration section which I call from the VB6 application startup which sets up an IoC container for all the .net components.
From a best practice approach I actually would recommend rewriting your VB6 code to .net and putting VB6 out of the picture. If this is not an option then you have a number of options, my explanation is just one of them.
My team is diving headfirst into a new project and we are taking the opportunity to bring ourselves up to date with Scrum methodology, new technology etc. Part of this involves trying to automate our QA process, using both Microsoft Test Manager and VS2010 Coded UI tests.
However, we are having problems getting the automated test playback to work with our currently-selected WPF control library, the DevExpress XPF suite. We've been using DevExpress for their WinForms and ASP.NET controls for years now, but this is our first experience with their WPF controls, and with automated UI tests, and the two don't seem to work well together.
In particular, trying to play back a recorded test that interacts with a grid control never works right, and even on simple controls the playback seems to get confused over which editor it should be interacting with. In the action recordings our test lead is generating from MTM I see a lot of this:
Type '5236' in 'PART_Editor' text box
Type '253' in 'PART_Editor' text box
And even worse, inside of the grids:
Click 'FooterPanel' pane
Last action on list item was not recorded because the control does not have any good identification property.
Click 'FooterPanel' pane
Click 'Item: CashEntry, Column ...' custom control
Move 'Item: CashEntry, Column ...' custom control from (141, 10) to 'Item: CashEntry, Column ...' custom control (5, 11)
Type '{NumPad8}{Down}{NumPad5}{NumPad0}{Up}{Down}{Down}' in 'CashEntry' window
Now, I have seen plenty of chatter on DevX's forums about their WinForms controls not supporting MSAA well enough for coded UI tests to work, but I thought that WPF used a different mechanism for automated UI testing that was supposed to work better. So, my questions are:
Is there a way to get the DevX XPF controls to work better with coded/automated UI tests?
If not, is there an alternative XPF control suite that is known to work well with coded/automated UI tests?
I'm specifically interested in a grid-like component with sorting, grouping, etc., a navbar-like component, and custom editors (dates, numbers, etc), all which support a unified system-wide theming.
(Also, if this type of thing is easy enough to do using just native WPF controls and styles, that would be helpful to know as well.)
EDIT: Since there appears to be no WPF control suite that actually works with MTM, we're being forced to use two separate testing tools at the sam time. Per several of the answers here, we're strongly leaning towards TestComplete. Hopefully the situation improves soon.
Don't have much idea about control suite supporting this but We had analyzed a test suite in past which supports objects based automated testing for WPF. Have a look at TestComplete (although it's not free)
Here is an excerpt from there site mentioning control support they provide -
WPF Control Support TestComplete offers rich support for WPF (XAML)
controls and robust automated UI testing of WPF applications.
TestComplete’s high-level test actions, such as item selection or cell
data input, are object-aware rather than coordinate-aware and thus are
more stable and resistant to the UI changes when performing WPF
testing. Flexible object mapping schemes allow testers to map custom
or derived WPF controls to standard types to simplify UI
manipulations. Support for custom WPF controls can also be added
using the TestComplete SDK.
http://smartbear.com/products/qa-tools/automated-testing/testing-wpf-apps/
I've heard very good things about WiPFlash.
In one of our projects we've used Infragistics WPF controls and TestComplete works with it.
Our QS Team also use TestComplete
I found a free utility that is independent of UI libraries.
PROJECT SIKULI
Sikuli is a visual technology to automate and test graphical user
interfaces (GUI) using images (screenshots). Sikuli includes Sikuli
Script, a visual scripting API for Jython, and Sikuli IDE, an
integrated development environment for writing visual scripts with
screenshots easily. Sikuli Script automates anything you see on the
screen without internal API's support. You can programmatically
control a web page, a Windows/Linux/Mac OS X desktop application, or
even an iphone or android application running in a simulator or via
VNC.
You can also use the VS internal UI test framework: Create a Coded UI Test.
just found this thread...
we had the same problem using DevExpress components,
which weren't findable on playback of CUIT.
But especially with Sikuli script the problem is solveable...at least.
Record test with MS Test Manager
Playback test, to find unreproduceble step
Create Sikuli sequence to 'step over'
Include created Sikuli script at appropriate position in CUIT and start again at Step 2
It really takes time to create tests this way, but at least its possible.
I am trying to create a multitouch application.
I have the hardware which will allow me to do this. On the software side I want to be able to have WPF textboxes, WPF web browsers, multiple focuses, multiple keyboards and multiple users at the same time.
From what I've seen, I can't be focused on two controls at the same time.
What is the Microsoft MultiTouch approach for this kind of job ?
The OS limitations are what they are (and don't appear to change in Win8): only one hWnd at a time can have focus.
Since you are using WPF though, everything within your application (with the exception of the WebBrowser control ActiveX widgets you may be using) is rendered within one big hWnd.
WPF 4 introduced native support for multitouch, including multi-touch capture. The APIs for this are many but pretty intuitive so I'll just say this... go to http://msdn.microsoft.com/en-us/library/ms590078.aspx and search within the page for all of the members with "Touch" in their name.
The catch however is that the controls shipping with WPF 4 don't work with the touch input events... you'll only be able to interact with one of those controls at a time. To take advantage of the multi-touch capture APIs, you'll have to create controls that are designed with it in mind. Fortunately, the Surface team at Microsoft has you covered on that... the "Surface 2.0 SDK" includes a suite of controls (usable on any Win7 machine, not just for Surface) that were built with this stuff in mind.
To create application with MultiTouch UI, use MultiTouch Framework in .Net
Go to http://multitouchvista.codeplex.com/
I am working in Silverlight 4.0 and have created a web application which is intended to be used as a utility for others. I have set up several screens using XAML in particular configurations as the UI, however I imagine that some people would like the option to customize the pages of the application. Is there a way they can do this? The XAML is not in the XAP file, it is compiled into a DLL, so
The answer depends on what kind of customization you want to offer your users. If you want users to be able to rearrange elements of the UI, you would not have them modify XAML. You would want to implement a "web part" interface in which users can move elements of the screen around, similar to Visual Studio. The major control vendors (e.g. Telerik, Intersoft, etc) include a Docking-style control.
What is the difference between using System.Windows.Automation (commonly known as UIA) API and Microsoft.VisualStudio.TestTools.UITesting (one that is used in Coded UI Test behind the scene) for implementing UI Test automation of a WPF application programatically?
Is there any specific scenarios, restrictions or advantages/disadvantages?
Coded UI Tests are a framework which wraps many automation technologies. UIA is just one of them.
UIA is new in Vista/Windows 7 and it targets rich client apps, coded UI tests will use UIA when you write tests against WPF and Silverlight.
The advantage of Coded UI over using UIA directly is a lot of automatic retrys and knowledge of how UIA works is built into Coded UI tests.
In fact, the answer is in your question. UIA is used for automation, while UITesting is used for... testing.
An excerpt from MSDN:
UI Automation provides programmatic
access to most user interface (UI)
elements on the desktop, enabling
assistive technology products such as
screen readers to provide information
about the UI to end users and to
manipulate the UI by means other than
standard input. UI Automation also
allows automated test scripts to
interact with the UI.
Thus, UIA can be used for - but isn't limited to - UITesting.