I am writing a WinForms based IDE-style application. As part of that application it loads plugins which implement an interface called IFeature. Features are loaded by the main IDE framework via MEF, and then asked to instantiate an instance of Control, which is then added to a tab page to form the main working surface for the plugin. So far so good.
I'm now working on trying to protect the IDE from badly implemented plugins, and I am out of good ideas on how to do that, exactly. If, for example, a plugin is a button which throws an exception, then the IDE framework code is not involved in that call-stack at all, so there is no place for me to inject a try-catch. I have hooked onto the AppDomain.CurrentDomain.UnhandledException and Application.ThreadException events, which provide a top-level protection against exceptions thrown in that manner, but I was hoping to be able to catch them with some context so that the exception could be tied to the IFeature instance that was responsible for the problem.
I did have the idea of creating a class derived from Control - and then over-riding all sorts of methods and implementing try-catch - but that
a. Seems clumsy.
b. Wouldn't protect against controls which in turn over-ride the method.
c. Would prevent any non-custom controls as being used (for example, Panel)
Are there any other methods I can use to provide closer-to-the-cause protection for my framework, or am I stuck with the handling the very broad scope events as above.
Thanks
Matt
In general I would not burden myself too much with this.
Just tell the plug-in developers that when you catch an exception that their control let slip you will remove all references to the control.
It is too hard to do anything else because you will have to envision everything a control could do wrong.
For a non-UI plugin I would kill the appdomain.
Removing all references might not be as safe and that's probably why many programs that allow UI plugins do not allow the UI to be drawn by the plugin but instead draw the UI for the plugin based on what the plugin suggests through an interface.
Related
Recently I came to know from this article -
http://blogs.msdn.com/b/patrickdanino/archive/2009/11/11/custom-controls-and-ui-automation.aspx
-that controls in WPF are responsible for exposing their UIA items themselves, and any newly added functionalities of a custom control aren’t available to the UIA until they are exposed through the implementation of the corresponding AutomationPeer class. At my work I have been assigned to the automation of UI testing of a WPF application that employs a large number of ToolBars. The problem is, through Microsoft UI Automation Library I can access the ToolBars (apparently which are developed as custom control) as AutomationElements, but I cannot access the Buttons inside them – Count of Children/Descendant Collection always return 0. When using Coded UI Test, the tests always fail and shows the following Error Message:
Test method
CAM2QDummyTest.CodedUITest2.CodedUITestMethod1
threw exception:
Microsoft.VisualStudio.TestTools.UITest.Extension.FailedToPerformActionOnBlockedControlException:
Another control is blocking the
control. Please make the blocked
control visible and retry the action.
Additional Details:
TechnologyName: 'MSAA'
Name: 'Standard'
ControlType: 'ToolBar'
--->
System.Runtime.InteropServices.COMException:
Exception from HRESULT: 0xF004F003
Apparently they didn’t implement the corresponding AutomationPeer classes. Now, I only have the application, not the source code. So I cannot solve the problem in the way described in the article I mentioned above. Can anyone HELP with any clue how can I get access to the inner Buttons of the ToolBars? Any suggestion will be gratefully appreciated.
You can have a look at what patterns and properties are supported via AutomationElement.GetSupportedProperties() and AutomationElement.GetSupportedPatterns() to see if there's a different pattern which you can use. It might be that there are list elements, etc. via SelectionPattern or similar which will give you access to the buttons.
Otherwise, get in touch with the vendors and ask them to add the relevant peers.
You can always get the coordinates (maybe by the BoundingRectangleProperty) then use Win32 functions to simulate a mouse click in the appropriate place. Nasty. This thread might help.
I'm very much new to Test Automation kind of thing. Recently I've been assigned to a project where I have to write an application (or, a script may be, I'm not sure) that will automate the UI testing of a CAD-like WPF application which misses lots of AutomationIds.
After doing a little searching on MSDN and other sources I'm a bit confused about whether I should use the Microsoft UI Automation Library or the new Coded UI Test feature included in VS2010. I'm not getting the clear picture of which one of these two applies in which scenarios, what advantages one has over the other and which one suits my purpose.
Please shade some light if you have experience/knowledge on the matter. Thanks in advance.
Basically Microsoft UIA is the new accesibility library in .Net 4.0. WPF applications and controls have built-in support for UIA through the AutomationPeer class.
Coded-UI test is a Record & Play automation tool which uses the Microsoft UIA Library underneath. Since being a tool compared to writing code in C# it improves QA productivity for recording more test cases.
For applications with automation support planned into it, Coded-Ui should be sufficient. If the AutomationIDs are missing make sure the controls have some unique property like Name. Use UIVerify or Inspect to check for this.
If NO unique property is avialble, there are the other below mentioned techniques you can use in combination with Coded-UI.
From an Event
When your application receives a UI Automation event, the source object passed to your event handler is an AutomationElement. For example, if you have subscribed to focus-changed events, the source passed to your AutomationFocusChangedEventHandler is the element that received the focus. For more information, see Subscribe to UI Automation Events.
From a Point:
If you have screen coordinates (for example, a cursor position), you can retrieve an AutomationElement by using the static FromPoint method.
From a Window Handle:
To retrieve an AutomationElement from an HWND, use the static FromHandle method.
From the Focused Control:
You can retrieve an AutomationElement that represents the focused control from the static FocusedElement property.
If you can leverage and use the Coded UI Test then go that route. Make sure to verify that your given configuration is supported.
The UI Automation Library resolves everything in the code behind. This then forces you to use a tool like UISpy to gain access to the controls internals so that you can then build out your test.
A Coded UI Test on the other hand still has code behind however it allows for the recording of steps through the given application which you are testing which will greatly increase the number of tests you can create.
UI Automation library is a low-level library. Usually, you don't want to write tests against it directly as it requires a pretty decent amount of work.
I would recommend looking at more high-level libraries. You mentioned one of them - Coded UI; another good choice would be White from TestStack. They both suits different kinds of projects. Coded UI is good when you don't want to invest a lot of efforts into your test suite. At the same time, it doesn't scale much so if you are going to write a lot of tests, you are better of choosing White.
Here I compare the two frameworks in more detail: Coded UI vs White
To complement the above responses, please look at CUITE that helps quite a bit and may be an appropriate approach for you.
I began 'rolling-my-own' 'semi-framework' using the CodedUITest library and devised a paradigm for separating the details of automation from the (C#) code.
Basically, I am creating a driver that reads what needs to be done from spreadsheet(s) where each line in it is a test step (or a pointer to a scenario in a different worksheet).
At present, incomplete, but promising, I have it working against a WPF application with partial success.
One of the main problems is that the developers neglected to identify controls uniquely and consistently.
Bey
Using the Composite Application Guidance tools from Microsoft, It seems as if there is no mechanism to allow you to query your modules ViewModels and ask if any of them have unsaved data. This is a problem because, and I'm guilty of this as well, you cannot stop the application from terminating when there is unsaved data...
I had thought about creating an interface called IApplicationEvents and have an event on there called ApplicationExiting. The thought being that each module can subscribe to the event and, when fired, can send back a "Cancel=true" or "Cancel=false" to say whether or not to allow the application exiting.
Curious to find out what others may have done in this instance, and to see what possible solutions there are in the community to solve this issue.
Thx.
There are a lot of choices here.
First off, I wanted to clarify a little nomenclature... typically your Views or ViewModels contained within your Module assemblies are the things with unsaved changes, not the Module itself. The Module is responsible for instantiating any views necessary at the start and contributing back to the shell during Initialize and that's typically it, so when you attack this problem, you'll want to focus on your views/viewmodels and not the Module classes.
Options off the top of my head:
Adopt a complimentary framework like Caliburn that has support for application events like this (as well as some MDI events like ViewClosing, that kind of thing). It has builtin support for Prism (http://caliburn.codeplex.com/)
Use a composite command. Your views or viewmodels will register themselves with a composite command elsewhere (CloseCommand, which you declare statically for your application) and every open view will have its CanExecute and Execute methods fired so that you can both vote in the closing of the application and also react to it, should it happen anyway. CompositeCommands are a feature of Prism. (See: Commanding Quickstart)
I think those are probably the most elegant. There's a few more options but these live in the best harmony with existing conventions.
Hope this helps.
I have a complex application that consists of an Application, containing many modules, each containing many views. The behaviours of my views may throw exceptions.
Sometimes I want to handle exceptions on the view that created them, sometimes in the parent module, sometimes in the grand-parent application.
The concept of RoutedEvents seems like a sensible way of approaching this problem, but I'm not entirely sure how to go about that.
Does anyone have any examples or links they can share that demonstrate what I am trying to acheive?
Thanks
Mark
Although Silverlight contains the RoutedEventHandler and RoutedEventArgs, unfortunately the concept of "routed events" as seen in the desktop WPF framework is not the same.
Today it's kept for source and API compatibility, and in the future, maybe it could be supported.
What this means is that, in the meantime, you may be able to do a little extra work and still accomplish this by
at the Application level, hooking up your own unhandled exception handler code, perhaps create and name the type "AdvancedExceptionManager" or whatever, and design a simple API on top of that to allow things to subscribe and process any exceptions and bubble it up.
at the module level, working with the global/Singleton unhandled exception handler code, subscribe and unsubscribe to "handling" the global exceptions, and canceling further processing, for instance.
Let me know if you need more information on how to go about this. It would help to know how your "modules" are constructed or designed.
This might be interesting for you:
"RoutedEvents implementation for Silverlight 3 including WPF compatibility"
http://sl3routedevents.codeplex.com/
We are looking at creating a WPF UI that runs across multiple AppDomains. One of the app domains would run the application while the remaining AppDomains would host a series of user controls and logic. The idea, of course, is to sandbox these User Controls and the logic away from the main application.
Here is an example of doing this using MAF/System.AddIn. What are some of the experiences other have had with this? How does this solution handle RoutedEvents/Commands that might occur inside one user control and do these get properly serialized across AppDomains? What about WPF resources? Can they be accessed across AppDomains seamlessly?
Old question, but nonetheless: You will need to have multiple UI threads - one per AppDomain. Create them like this:
var thread = new Thread(() =>
{
var app = new Application();
app.Run();
});
thread.Name = AppDomain.CurrentDomain.FriendlyName;
thread.SetApartmentState(ApartmentState.STA);
thread.Start();
The biggest challenge is then that you cannot send FrameworkElements between AppDomains (they are not MarshalByRefObject), but you can use the FrameworkElementAdapters.ViewToContractAdapter() and ContractAdapterToView() methods to work around this limitation. See the FrameworkElementAdapters MSDN page for more details.
Then, once you have this in place, the biggest problem IMHO is that you cannot lay anything on top of the FrameworkElement from the "remote" domain (the classical "airspace problem"). See this thread for more info about this.
I answered a simular question here and edited it for WPF also, you can use an intersting property of how the compisition engine operate's to tail-coat a dispatcher Pump, into one of the rendering contexts. It's a really light weight option.
Also, I'm guessing you know about the enterprise library and unity?
There is a WPF application block so using that pattern is not too painful ;) But don't they say, no pain no gain?
There's also CAB (Composite UI Application Block), ties into unity. The WPF SDK folks have crafted a Silverlight & WPF platform. (a.k.a Prism).
Oh right, also, you asked about Resources? I prefer to load reasources manually in the Application class. One thing I've realized, say you have a ResourceDictionary in a sub-folder and you are loading up MergedDictionaries in that ResourceDictionary. So, if in your Application class, you load "my-res-dir/MergedDictionaryLoader.xaml" (by code or xaml), ALL FUTURE LOADS OF MERGEDDICTIONARIES ARE LOADED FROM "my-res-dir".
Sort of insane if you ask me, I would think that as the process current directory has not changed, you should specify "my-res-dir/foo.xaml" for all your additional directories. However this is not the case (I do not believe this is documented anywhere at least very well and should be considered a bug imho).
So remember, WPF resource dictionary loading is going to be based off of the directory from which the current XAML is in. So you specify Source="foo.xaml" from within your "my-res-dir/MergedDictionaryLoader.xaml". I've even played with the URI pack / absolute syntax, however I've never found that too be much more intuative.