My WPF 5.0 Wishlist

Here's a list of things I'd like to see in the next version of WPF:

  1. Blend's Behaviors and TriggerActions model should be part of the .NET framework, not a custom Blend assembly, and should have VS support
  2. I shouldn't have to declare the same half-dozen xmlns:abc entries in every XAML file. An ASPX inspired 'project-wide imports' system would be great.
  3. Ability to replace tags from a namespace, ala ASP.NET TagMapping.
  4. This should work for markup extensions too - e.g., {# Foo} could become {Binding Path=Foo}
  5. XBAP's should be able to nicely prompt for full trust elevation. Why does Silverlight get a friendly prompt while XBAP's have to deal with group policy or arcane IE settings? Boggles the mind.
  6. MarkupExtension should be an interface. Then extensions could be DependencyObjects and thereby support attached properties.
  7. It shouldn't be so hard to support nested child objects with bindings (without using ItemsControl).
  8. FrameworkElement.AddLogicalChild shouldn't be protected, it should be public
  9. Styles simply shouldn't be so verbose. Give us a CSS-like syntax for styles.
  10. ICommands should have the ability, when executed, to determine which UIElement owns the command. Perhaps when event handlers are invoked, CallContext could be used to store the current UIElement 'sender'.
  11. AdornedElementPlaceHolder shouldn't be so tightly coupled to TemplatedAdorner. Or, TemplatedAdorner shouldn't be internal.
  12. Easier to make attached lazy collections (without the current 'hacks').
  13. Fix this bug.
  14. Some kind of pre-unload event. E.g., if an object is removed from an ObservableCollection, make it as easy to play an Unloaded storyboard as it is for a Loaded storyboard. Perhaps it's specific to the item containers of an ItemsControl.
  15. Make it possible to figure out the XAML URI from a Type. E.g., this should pass:
    Assert.AreEqual("/MyAssemb;component/Page1.xaml", GimmeUri(typeof(Page1)))
  16. Make it possible to set a default style for x:Class root's (e.g., a style for all Window's) - as per this question.
  17. TriggerBase's constructor shouldn't be public
  18. Delete everything from System.Windows.Navigation, and build a better navigation system.
A picture of me

Welcome, my name is Paul Stovell. I live in Brisbane and work on Octopus Deploy, an automated deployment tool for .NET applications.

Prior to founding Octopus Deploy, I worked for an investment bank in London building WPF applications, and before that I worked for Readify, an Australian .NET consulting firm. I also worked on a number of open source projects and was an active user group presenter. I was a Microsoft MVP for WPF from 2006 to 2013.

02 Feb 2010

For (1), I'll take you one further and say that those APIs should also be enhanced such that we can attach custom Behaviors and TriggerActions using styles--not just on individual instances. Better yet, give us full trigger support on FrameworkElement, as was originally planned. Also let us write custom triggers (this goes to (17)).

(2) breaks the XAML model in that it would introduce environmental dependencies. Perhaps instead they could introduce an "include" mechanism where one XAML file could reference another, with the option to include its namespace imports as well. But that would introduce problems with prefix collisions. It's probably better to leave it as-is. FWIW, ReSharper can automatically import CLR namespaces for you when you use its Smart Type Completion feature.

(3) and (4) both introduce the potential for name collisions or names that could break the parser. The latter is easier to avoid. As for the former, imagine importing a new namespace with a conflicting type name, and suddenly your custom tag is invalid and has to be changed.

Totally agree with (6).

Totally disagree with (8). It's a great way to break somebody else's controls.

I'm not sure how think (9) should work. I'm okay with styles being the way they are, and I'm against WPF depending on its own "extended" version of the XAML language (parser extensions like those required for control templating are okay, though).

For (10), maybe introduce overloads to Execute and CanExecute which include an ICommandSource parameter.

++13. A million times ++13.

I'm not sure how workable (15) is. The Page1 type in your example is technically defined in the C# code-behind. Its existence doesn't strictly depend on the XAML file--the file is merely required for initialization, assuming the standard designer-generated InitializeComponent() method is called. Making (15) work reliably would require some runtime IL analysis. Not really worth the overhead.

As for (18), I've never used the built-in navigation system, but it doesn't seem terribly flexible. I'm all for replacing it.

02 Feb 2010

Paul,

You are a smart guy, but please think things through. Customers demanding things without thinking is exactly how APIs become impossible to test and debug. You are only making the WPF architects' jobs harder.

(2) I shouldn't have to declare the same half-dozen xmlns:abc entries in every XAML file. An ASPX inspired 'project-wide imports' system would be great.

This is an awful idea and a misunderstanding of what XML is, and what the flaws with XAML are. XAML tries to be a composition language that makes heavy use of Containment pointwise reasoning, when this is not the best way to configure GUI systems.

(3) Ability to replace tags from a namespace, ala ASP.NET TagMapping.

Did you think this through? When is TagMapping going to be applied? Please come up with actual use cases for this feature, and how it would actually work. As an aside, borrowing anything from ASP.NET is a pretty awful idea, as I can't think of a framework I like less.

(4) This should work for markup extensions too - e.g., {# Foo} could become {Binding Path=Foo}

What you want is called "user-defined reader macros" in Lisp. MarkupExtensions are system-defined reader macros. To be honest, XML already supports user-defined reader macros: it is called XML Entities. They were excluded from XAML, presumably because of the massive potential for security flaws.

(5) # XBAP's should be able to nicely prompt for full trust elevation. Why does Silverlight get a friendly prompt while XBAP's have to deal with group policy or arcane IE settings? Boggles the mind.

Solution: Stop using XBAP. It is not cross-platform, lacks features, and generally doesn't fit with the future of software engineering. It is "Sandbox" based software, which is finally going the way of the dinosaurs (thankfully).

(6) MarkupExtension should be an interface. Then extensions could be DependencyObjects and thereby support attached properties.

As someone outside Microsoft who knows XAML as well as Rob Relyea does, I can say with authority this makes no sense. MarkupExtension is not something you want to be persistent. In programming language theory, it is a macro system; what you want is a fexpr. MarkupExtension is the wrong extension point. In my humble opinion, the pain you are feeling is the direct result of XAML not being based off Lisp research like Scheme.

(7) It shouldn't be so hard to support nested child objects with bindings (without using ItemsControl).

Example, please. Hyperlink words in this sentence so I can see what you actually want, and why you want it.

(8) FrameworkElement.AddLogicalChild shouldn't be protected, it should be public

NO! It should not. Making it public encourages spaghetti coding and not considering exactly how your view should interact with the model. The real problem is that WPF's component model encourages Containment relationships. Logical Child really only expresses one dimension and the very idea of making AddLogicalChild public encourages developers to write apps that have one less degree of freedom. - in actual building architecture terms, such static structures places tension on the load-bearing frame of your application model. Ever heard of the Tacoma Narrows Bridge collapsing?

(10) # ICommands should have the ability, when executed, to determine which UIElement owns the command. Perhaps when event handlers are invoked, CallContext could be used to store the current UIElement 'sender'.

No, they should not. This violates Clemens Szyperski's domaincasting principle: route events ONLY through the correct layer of the system. What CallContext class or property are you referring to? System.Runtime.Remoting.* does not exist in Silverlight. Are you committed to increasing the size of Silverlight substantially, including adding a huge assembly dependency, just to have this feature? See: http://msdn.microsoft.com/en-us/library/cc838194%28VS.95%29.aspx Also, please explain to me why you would want every WPF call to add additional memory pressure.

(13) Fix this bug.

And actually fix it, not just release a workaround, right? In the mean time you should use static analysis engines such as Mono's Gendarme to try to avoid these problems as much as possible.

(14) Some kind of pre-unload event. E.g., if an object is removed from an ObservableCollection, make it as easy to play an Unloaded storyboard as it is for a Loaded storyboard. Perhaps it's specific to the item containers of an ItemsControl.

The basic problem here is that WPF doesn't integrate its use of data flow (i.e., ObservableCollection) with its subsystem of time varying functions (Storyboards, triggers, etc.) in a way that is composition-friendly. Adding more events seems like a band aid on a gun shot wound.

(15) Make it possible to figure out the XAML URI from a Type. E.g., this should pass: Assert.AreEqual("/MyAssemb;component/Page1.xaml", GimmeUri(typeof(Page1)))

This is a really bad idea. It introduces physical coupling of source files to your system design. Do you really want to have to explain to the CEO that the reason the application failed was that you wrote that crazy code???

(17) TriggerBase's constructor shouldn't be public

This would be a breaking change. Send Cwalina a message suggesting that he should write up some guidance on not subclassing TriggerBase. By the way, I agree, you should be more modularly composing change propagation rather than using Triggers.

(18) Delete everything from System.Windows.Navigation, and build a better navigation system.

Agreed. I've given Tim Heuer my thoughts on this, but Microsoft wanted me to sign an NDA to discuss it further. I said no, and prefer public discussion on these matters.

I probably missed a few times, since your list was long. Apologies.

02 Feb 2010

Oops...

The basic problem here is that WPF doesn't integrate its use of data flow (i.e., ObservableCollection) with its subsystem of time varying functions (Storyboards, triggers, etc.) in a way that is composition-friendly. Adding more events seems like a band aid on a gun shot wound.

should say: "its control subsystem for piecewise partitioning of time varying functions"

The major problem is lack of separation between control and data, and time-continuous and time-discrete. System modeling languages like UML solved this problem 10 years before WPF was released...

This would be a breaking change. Send Cwalina a message suggesting that he should write up some guidance on not subclassing TriggerBase. By the way, I agree, you should be more modularly composing change propagation rather than using Triggers.

should say adding guidance not to call its constructor. You can add rules to Mono.Gendarme and FxCop to avoid this by enforcing such guidance at the architectural level.

02 Feb 2010

One more clarifying comment.

Your comments for 14 and 17 seem to be unaware of Silverlight development best practices, as encouraged by the WPF / Silverlight architecture team.

Please see the Silverlight documentation for TriggerBase and EventTrigger. In particular, the Remarks section of each.

TriggerBase, Remarks: http://msdn.microsoft.com/en-us/library/system.windows.triggerbase%28VS.95%29.aspx

TriggerBase exists in Silverlight 2 solely for WPF compatibility. TriggerBase is not intended to be derived from as a base for other trigger implementations; the entire Triggers syntax is a discouraged technique in Silverlight 2. For more information, see Remarks in EventTrigger.

EventTrigger, Remarks: http://msdn.microsoft.com/en-us/library/system.windows.eventtrigger%28VS.95%29.aspx

EventTrigger and the object.Triggers property element usage on elements are supported by Silverlight, but using this technique is discouraged for current applications. EventTrigger can only support a triggering action for the Loaded event (you name the event in the EventTrigger..::.RoutedEvent property.) This makes an EventTrigger unsuitable for most run-time interactions. Instead of using EventTrigger and the Triggers property, consider one of the following two alternatives:

  • For animating properties on objects that are not controls, place the storyboard in the general Resources for a page or application. Then assign an event handler on the element where you would have placed "Triggers". The event handler, when responding to the relevant event, should retrieve the storyboard from the resource dictionary. You then call Begin on the retrieved Storyboard.

  • For animating properties on objects that are controls (derive from Control), use the VisualStateManager technique, and run the appropriate animations based on state of or inputs to the control by calling GoToState.

Ted
Ted
02 Feb 2010

Two other things I really would like to see are: * some support at compiler level for INotifyPropertyChanged, so we could do something like "public string Name { get; nset; }" and have it raise the PropertyChanged event... so fed up with writing all that boilerplate code... :) ok, this wasn't WPF really, but it's related... * support in ListCollectionView for tracking selection of more than 1 element.

03 Feb 2010

Hi John,

I'll write up some additional pages with some context on why I wanted some of those changes, but suffice it to say that they're nearly all driven from "I want to do X" and being told "You can't. Go home, thanks for playing".

I wanted to pick up on 15 right now because it's quick:

(15) Make it possible to figure out the XAML URI from a Type. E.g., this should pass: Assert.AreEqual("/MyAssemb;component/Page1.xaml", GimmeUri(typeof(Page1)))

This is a really bad idea. It introduces physical coupling of source files to your system design. Do you really want to have to explain to the CEO that the reason the application failed was that you wrote that crazy code???

This would be true if this was the only place URI's surfaced. But it absolutely wouldn't be. Here's some other places URI's come up:

  • When I navigate using NavigationService.Navigate(uri)
  • When I load a resource dictionary
  • When I set the Window.StartupUri
  • In the auto generated code in InitializeComponent()

So this ability would break nothing that wouldn't currently be broken.

Now, why do I want the change? Because as you may know, WPF's navigation system behaves differently depending on how you navigate. NavigationService.Navigate(uri) means that my page can be garbage collected. But NavigationService.Navigate(new Page1()) means it's in memory until I force the navigation stack to be unwound.

Since navigating to an instance is so dangerous, I prefer to use URI's. But in one case I needed to figure out which page to navigate to using reflection. But there's no way to resolve a URI from a type.

Given URI's are so prevalent and allow you to map from URI to a type, it should be possible to go from Type to URI without making assumptions. Currently it isn't.

(Of course if 18 was fixed, this might not matter)

Paul

03 Feb 2010

Hi John,

I also want to touch on a theme in a couple of your points.

Solution: Stop using XBAP. It is not cross-platform, lacks features, and generally doesn't fit with the future of software engineering. It is "Sandbox" based software, which is finally going the way of the dinosaurs (thankfully).
...
Your comments for 14 and 17 seem to be unaware of Silverlight development best practices, as encouraged by the WPF / Silverlight architecture team.

First, the reasonings that you linked to read to me as "we didn't bother to implement triggers because we like VSM better, ergo best practice is don't use triggers because, well, you can't anyway". Well, in WPF I can. Silverlight best practices don't necessarily translate to WPF best practices.

Second, I'd argue that 'best practices', which are contextual anyway, have nothing to do with what a "foundation" or platform should and shouldn't support. If you don't need the change, don't use it. I would like it. Firefox developers may have strong views on how HTML should work but hopefully that doesn't stop them from implementing features from HTML vNext that they don't like, because they are building platforms, not frameworks. Their goal is to enable, not to dictate.

Third, there are plenty of legitimate cases where best practices just don't work. Curiously, the people encouraging the best practices don't tend to be around. Best practices change. Best practices for data access used to be DataSet's. Imagine if they hadn't made ADO.NET public because it wasn't best practice anyway - we'd all be drinking the best practice DataSet cool aid and the ORM boat could have taken many more years to come to .NET. A platform should not be designed around a solely around 'best practices'.

A valid response for 17 could be "based on talking to users, we don't see a compelling business case to implement this feature that would outweigh the costs of implementing and maintaining it" - I'd live with that, but it would still be on my list for WPF 6, 7 or 8, because I had a need for it. A response that annoys me is "well you shouldn't use triggers anyway, because we all reckon MVVM is the bee's knee's and thus we like VSM over triggers". That's short sighted framework thinking rather than strategic platform thinking.

"Solution: Stop" reminds me of the old joke "Doctor doctor, it hurts when I do this..." - "well stop doing that". A good platform would allow me to solve my problem in my context. A bad platform tells me my problem is all in my head and my context is just dumb anyway, and scoffs while it walks away. Paul

03 Feb 2010

Third, there are plenty of legitimate cases where best practices just don't work.

There are cases where tools pushing their pragmatic solutions as best practices just don't work. Pragmatic solutions aren't always the best practices known, though; they are only the best practices known to the people who implemented them. Read The Pragmatic Programmer for tons of examples of how two ordinary programmers have made a successful career for themselves by simply being pragmatic and going with the best solution they know how.

Patterns, as defined by Microsoft, often fall into the 'pragmatic patterns' group rather than the 'timeless way of building software' group. This reflects the fact that companies need to squish out applications. Thus, when you read Microsoft advocating View-Document Model and Ultimate Hook in MFC, then MVP in WinForms, and then MVVM and VSM for WPF/Silverlight, what you are seeing is the best solution Microsoft can come up with given the constraints of integrating with the technology the customer has no choice but to use. Patterns & Practices is a team at MS dedicated to helping customers figure out how to "squish out" solutions.

However, there is another, more positive way to spin "Microsoft patterns". The best way to explain it is through mentioning a series of books I love dearly, by Henry Petroski. Petroski is a highly respected civil engineer and has committed much of his adult life to studying failure. Only later on in his career did he embrace that human beings need failures to educate good design. He gives all kinds of interesting examples like the pencil and the fork. You see that sort of evolutionary progress in Microsoft's APIs. Microsoft has been spending the better part of its existence trying to figure out how to build the best kitchen utensils and office supplies to compete on the Web. This is mostly a direct result of Bill Gates vision of networkable graphics, which is well-documented [see the original "Why We're Building .NET" press release from 2000]. Gates' baby has and always will be networkable graphics, and even after stepping down from Chief Software Architect and Chairman, his influence remains. Microsoft has been trying to compete with the Web since 1995. For a good history of this, I recommend reading, "Renegades of the Empire", which chronicles the lives of three of the most influential programmers in Microsoft's history (they created DirectX, effectively pushing Microsoft into its current 5 billion dollar a year gaming empire, and also help setting the stage for technologies like WPF through Microsoft's initial 3D networkable graphics play that was never released to the public: ChromeEffects...

Where do I stand on these two spins? Personally, I like viewing it from both angles. I do think .NET 3.0 shipped about 2 years later than necessary, helped cause a massive delay to Windows Vista that severely harmed Microsoft's revenues and also allowed Apple to increase market share among key demographics like the babyboomers, and that .NET 4.0 although it will ship "on time" is still solving many of the problems .NET 3.0 was intended to create. I do think that if WPF was more modular that it could've shipped sooner. I am not sure how WPF was tested as it was developed, but I know from talking with the Ximian guys who built Moonlight that it took them 4 months just to get a picture on the screen for the text editor control, due to all the cyclomatic dependencies in WPF. This experience led Miguel de Icaza, the head developer at Novell, to basically tell MS there was no chance in hell Novell would commit resources to porting WPF to Linux. Silverlight, on the other hand, was a chance for a new start... and that's why you see Moonlight/Silverlight today.

On the .NET 4 front, we see Microsoft really pushing the DLR angle, but also now the MEF angle. Tell me, why does WPF need a special resource location subsystem and MEF have its own special resource location subsystem? Why do you also need Unity or NInject or however other many "dependency injection frameworks"? Why do these codebases share no code? Well, it is probably a good thing they share little code, since they're all sloppy and searching for a unified solution. But if you take a step back, tilt your head a little, you see that Microsoft is simply suffering from being a Willy Mammoth and is being attacked by the descendants of the Sabretooth Tiger - the Snow Leopards of the world. :) So all of this reinventing the wheel can simply be described as a Willy Mammoth being too large to notice there's all these small warts on its body.

Second, I'd argue that 'best practices', which are contextual anyway, have nothing to do with what a "foundation" or platform should and shouldn't support. If you don't need the change, don't use it

Which of your changes would not affect me? I know for certain your CallContext will affect me by increasing memory pressure, bloating the Silverlight download size, and generally just adding more complexity to already complex WPF APIs. Moreover, I now would have to add addition rules to Mono.Gendarme and FxCop so my junior developers don't use the techniques I know are crazy. I've already spent a significant amount of time carving out sane usage patterns for WPF - and do not want to have to start over. And I can define this complexity mathematically for you, using automata theory. What you seem to be advocating in most of your suggestions is that you want logic to route through the wrong layer of the system. This means that your system cannot be described simply using finite state automata, because in order for a specific WPF subsystem to figure out "what to do", it has to collaborate with multiple other subsystems. This entails knowing "who called who". Such coupling is strictly speaking nasty and mathematically not elegant.

"Solution: Stop" reminds me of the old joke "Doctor doctor, it hurts when I do this..." - "well stop doing that". A good platform would allow me to solve my problem in my context. A bad platform tells me my problem is all in my head and my context is just dumb anyway, and scoffs while it walks away. Paul

I disagree. My position on XBAP is backed up by theory and proven by practice. Object capability systems are proven to be much easier to secure, more robust for composition, and just generally superior to conventional multiprogramming system design in every way imaginable for distributed computing, etc.

I'm not walking away, either. When I tell a developer something, it is backed up by experience and theory -- as much as possible. I only think with my gut when I watch the Colbert Report.

First, the reasonings that you linked to read to me as "we didn't bother to implement triggers because we like VSM better, ergo best practice is don't use triggers because, well, you can't anyway". Well, in WPF I can. Silverlight best practices don't necessarily translate to WPF best practices.

I'm sorry it comes across that way. What Microsoft is doing is the best sort of documentation when dealing with a situation like WPF and Silverlight. Sometimes developers need to simply hear something to get them to re-crystallize their thinking. A message that says, "Stop doing that, it is bad, and, oh, by the way, here is this much better way" is great. The major problem, as I see it, is that MSDN Remarks are not consistent across WPF and Silverlight. As a WPF developer, you probably had no idea those Silverlight remarks existed. This is mainly a documentation bug: Microsoft's architects did not take responsibility for explaining differences between Silverlight and WPF.

Let me illustrate by story. A long time ago there was a kid who had a job in a warehouse moving boxes. On his first day on the job, he asked the supervisor WHY he had to pack boxes a certain way. The supervisor's reaction was to yell up and down and tell him that "because that's the way you pack boxes", and the supervisor under no conditions wanted the new employee to think otherwise. Arming a young kid with reasons as to why something is done just gives him excuses when he sees places where those rules can be broken. So for his own safety, the advice is simply BECAUSE THAT IS THE WAY YOU DO IT OR YOU ARE FIRED. Most Microsoft customers cannot handle being given a precise explanation, and even when they can, it might leak design insight to competitors like Adobe. More often than not, people in general, inside and outside Microsoft, behave like a novice boxpacker. They complain about wearing a weight belt while lifting packages, because they simply want fork lifts. Then when they neglect to wear their weight belt while still having no forklift, they get a hernia and blame Microsoft for still not having forklifts, and they completely forget they were told to wear weightbelts BECAUSE THAT IS THE WAY YOU DO IT OR YOU ARE FIRED.

03 Feb 2010

This would be true if this was the only place URI's surfaced. But it absolutely wouldn't be. Here's some other places URI's come up:

* When I navigate using NavigationService.Navigate(uri)
* When I load a resource dictionary
* When I set the Window.StartupUri
* In the auto generated code in InitializeComponent()

You are advocating MS replace the Navigation subsystem, yet your complaints about mapping classes to XAML URIs completely contradict that advocacy.

I am not sure what to tell you...

Here are some thoughts

System.Uri has to be the ugliest class in all of .NET - quite an accomplishment. It is monolithic, not object-oriented, and basically looks like it was written in FORTRAN.NET. There's no abstraction whatsoever.

Thus, I would start by saying Uri's in NET are crap, and how they are used are crap. My best guess is that this is a direct result of nobody at Microsoft understanding the Web. The Uri spec is pretty clear about why Uri's are the way they are, and yet the Uri class does not let you cleanly separate concerns the same way the spec does.

* When I set the Window.StartupUri

Maybe StartupUri should be deprecated.

* In the auto generated code in InitializeComponent()

This is a sign the solution is not object-oriented, since client API users must do additional work to instantiate a problem domain object (the component) by subclassing its class. Nasty.

* When I load a resource dictionary

And why does that happen?

03 Feb 2010

Let me clarify a bit what I mean by System.Uri being ugly.

If you read the docs on MSDN, it says the constructor does a ton of work, including putting the Uri into canonical form. This doesn't make much sense, as now in order to subclass Uri you have to call super() on the parent class constructor. More basically, if you read the Uri spec, you'll note Tim Berners-Lee explicitly states canonicalization algorithms are Uri scheme dependent. Putting canonical form conversions into the Uri constructor is non-modular, because as you want to add new Schemes, you have to subclass Uri, rather than compose a Uri using the component parts defined by Berners-Lee.

It's basic stuff like this, not being done right, mindlessly being used by WPF, that makes things add up to a complicated system.

Just speaking from experience implementing a few systems of my own, of course...

06 Feb 2010

Just give in mate. Lose WPF and use ASP.NET. Problems solved!

Eric Hill
Eric Hill
08 Feb 2010

I guess this is as good a place as any for my WPF 5.0 wish-list:

  1. An immediate-mode graphics scheme that integrates in a first-class way with WPF's retained-mode graphics. Retained-mode isn't a bad thing, but there are important problems that it simply cannot solve, like data-driven visualization. We can fake it, and are faking it, using things like WriteableBitmap, but there are issues like knowing exactly when is a good time to update your bitmap without significant flashing. WPF 5 will presumably be DX 10-based; Direct2D/DirectWrite is DirectX 10 based; these two technologies should work together seamlessly.

  2. We desperately need better visibility of the processing of messages by the WPF Dispatcher. In Windows SDK development, we had Spy++. Where is Spy++ for WPF?

  3. For the love of Pete (pardon the expression), allow us to derive classes from XAML-based base classes. This worked in WPF 3.0 Betas but got "broken" (either by accident or on purpose) in the production release and to this day does not work. Microsoft is well aware of the bug but has said nothing about why WPF fails in this way or whether they foresee fixing it.

There are others, but they pale into insignificance compared to these.

Thanks,

Eric

Eric Hill
Eric Hill
09 Feb 2010

I should clarify my 3rd wish: The issue is subclassing XAML-based classes from another module. As long as the base class and derived classes are in the same assembly, you're okay. It's when you have a XAML-based class defined in one assembly that you want to derive a class from in another assembly that you're stuck. For example, this bug prevents defining a XAML-based class in C# and deriving a class from it in C++/CLI.

Eric

09 Feb 2010

Eric,

I think your clarification needs clarification. What is a XAML-based class? Are you referring to MarkupExtension? Or are you referring to the mechanism of XAML associating a XAML file to a code-behind file via partial classes using the x:Class MarkupExtension? For C++/CLI, there are no partial classes supported by the compiler, so you must use subclassing via the x:Subclass MarkupExtension. What is the problem, other than that this is ugly?

Eric Hill
Eric Hill
16 Feb 2010

Hey, John,

I am not referring to MarkupExtension, I am referring to a class that exists as XAML (including x:Class) plus code-behind. Suppose I have a C# library containing BaseWindow.xaml, defining a Window and having an x:Class="MyLibrary.BaseWindow", along with a code-behind file, BaseWindow.xaml.cs. Now, within that same library, create a new class in C# and declare it as derived from BaseWindow. This will compile and run just fine. Now, instead, create a new WPF application, still in C#, have this application reference your library assembly, and try to make a new C# class that derives from BaseWindow. It will compile just great, but when you go to run the application, you will get an exception when you try to instantiate the derived class saying "The component 'DerivedClass' does not have a resource identified by the URI '/MyLibrary;component/basewindow.xaml'". Why can I derive a class from a XAML-based class if both are in the same module, but not if my derived class is in a separate module? The answer is, it's just a bug, and Microsoft knows its a bug, but it's unclear if they will ever do anything about it.

Thanks,

Eric

Kirn
Kirn
16 Feb 2010

I have been trying to solve exactly this issue Eric - until I read your posts above it didn't occur to me that it was actually a bug, I figured I was just doing something wrong. Is this really not possible? Is there a workaround?

KTX
KTX
23 Feb 2010

You guys know about this site right?

http://dotnet.uservoice.com/forums/40583-wpf-feature-suggestions

xenry
xenry
23 Jul 2010

I wish I could bind readonly dependency properties with the OneWayToSource mode. For example bind IsMouseOver of a UIElement in a view to a property in viewmodel:

xenry
xenry
23 Jul 2010

<Button IsMouseOver={Binding Hovered, Mode=OnewWayToSource} />

(apologies for the double post, didn't realize that code should be escaped)