Condividi tramite

WPF in .NET 4.6.1

  • Articolo

In addition to the platform and tooling improvements that we delivered in .NET 4.6,, we started looking into WPF App Local as a means of delivering platform improvements in March of this year. We had some early successes in our prototypes that we were super excited about, and we shared that with the community during dotNetLive and the Connect session.

Coming into this investigation, we knew we would have some hard challenges to overcome like ClickOnce performance. As we looked harder at these problems, we realized that the complexity that they were introducing would add a notable burden onto customers (E.g NGEN app local packages). In the light of these findings, we decided that the better solution was to work to improve system-wide WPF instead. At the same time, we want to bring some of the benefits of the app local approach, like quick turnaround of fixes and the ability for customers to privately test these changes into the system-wide version of the framework as well.

First, we want to assure you that we are still committed to continuously servicing the platform, providing important fixes and improvements, and evolving the tooling based on customer feedback. We are exploring ways for partners and the community to provide us with more direct feedback, and participate more easily in testing and validation of fixes and features as they are prepared. This would allow customers to review these changes in a non-production environment for feedback purposes. The following are the improvements that have been delivered as a part of .NET 4.6.1 release.

Performance Improvements

Touch stack performance has been improved with coalescing support added to touch events such that current position is reported after a UI thread delay similar to mouse pointer movements.  Additionally, RichTextBox typing no longer hogs up the Render thread during fast input and you will be able to notice a much smoother experience in this scenario.

DX Integration [Open Source]

One of the highest voted ideas on our UserVoice was to add to WPF the ability to work with DX11 Content in D3DImage easily. We have been able to deliver on that through our WPF DirectX Extensions project hosted here in GitHub. Granted, this still requires a native dll for you author your DirectX visualizations but it enables you to easily integrate it with our custom D3DImage class in the project.

Currently, we have support for Dx10 and Dx11 and in future will extend it to DX11 on 12 and DX 12. If you are curious about what optimizations DX12 gives you, take a look at the article here. The nuget package release is a preview release at this time and we would love to get more feedback from the community on the quality and features before we release a stable version.

WPF Samples [Open Source]

There are a large number of samples available for WPF in MSDN. Unfortunately, there are not easily browsable, targets .NET 3.5 and requires you to individually download each sample to take a look at the content. We have vastly simplified this process by hosting all the samples on GitHub. This is a work in progress and we have moved over 200+ samples (retargeted to 4.5.2) to the repo already. If you see a sample missing from the list, do let us know by raising an issue here.

Spell Checking Improvements

The spell checker in WPF has been updated on Windows 8.1 and above to leverage OS support for spell checking additional languages.  There is no change in functionality on Vista SP2, Windows 7 and Windows 8. The following languages are available to be spell-checked, which includes the languages available for spelling checking in previous versions of .NET Framework (English, German, French, and Spanish).

Culture

IETF Language Tag

Windows 8.1

Windows 10

LCID (Decimal)

Arabic_SaudiArabia

ar-SA

Yes

Yes

1025

Bulgarian_Default

bg-BG

Yes

Yes

1026

Catalan_Default

ca-ES

Yes

Yes

1027

Czech_Default

cs-CZ

Yes

Yes

1029

Danish_Default

da-DK

Yes

Yes

1030

German_German

de-DE

Yes

Yes

1031

Greek_Default

el-GR

Yes

Yes

1032

English_US

en-US

Yes

Yes

1033

Finnish_Default

fi-FI

Yes

Yes

1035

French_French

fr-FR

Yes

Yes

1036

Hebrew_Default

he-IL

Yes

Yes

1037

Italian_Italian

it-IT

Yes

Yes

1040

Dutch_Dutch

nl-NL

Yes

Yes

1043

Norwegian_Bokmal

nb-NO

Yes

Yes

1044

Polish_Default

pl-PL

Yes

Yes

1045

Portuguese_Brazil

pt-BR

Yes

Yes

1046

Romanian_Default

ro-RO

Yes

Yes

1048

Russian_Default

ru-RU

Yes

Yes

1049

Croatian_Default

hr-HR

Yes

Yes

1050

Slovak_Default

sk-SK

Yes

Yes

1051

Swedish_Default

sv-SE

Yes

Yes

1053

Turkish_Default

tr-TR

Yes

Yes

1055

Indonesian_Default

id-ID

Yes

Yes

1057

Ukrainian_Default

uk-UA

Yes

Yes

1058

Slovenian_Default

sl-SI

Yes

Yes

1060

Latvian_Default

lv-LV

Yes

Yes

1062

Lithuanian_Default

lt-LT

Yes

Yes

1063

Hindi_Default

hi-IN

Yes

Yes

1081

Portuguese_Portugal

pt-PT

Yes

Yes

2070

Spanish_Modern

es-ES

Yes

Yes

3082

Hungarian_Default

hu-HU

No

Yes

1038

Urdu_Default

ur-PK

No

Yes

1056

Vietnamese_Default

vi-VN

No

Yes

1066

Malay_Malaysia

ms-MY

No

Yes

1086

Punjabi_Default

pa-IN

No

Yes

1094

Gujarati_Default

gu-IN

No

Yes

1095

Tamil_Default

ta-IN

No

Yes

1097

Telugu_Default

te-IN

No

Yes

1098

Kannada_Default

kn-IN

No

Yes

1099

Malayalam_Default

ml-IN

No

Yes

1100

Marathi_Default

mr-IN

No

Yes

1102

English_UK

en-GB

No

Yes

2057

Bengali_Default

bn-BD

No

Yes

2117

The above list is subject to changes, and is included here for informational purposes only – this list should not be treated as a guarantee for support of spell-checking on these languages. The list of spell-checkers supported by the underlying OS platform can vary over time – additional languages could be added, and existing languages might go out of support – and WPF’s capabilities would correspondingly change as well.

As in the previous versions of .NET, the language for a TextBox control or a RichTextBox block is detected by looking at the following information in the order listed below:

  1. xml:lang is used, if specified.
  2. Current input language
  3. Current thread culture

Additional support for per-user custom dictionaries

With the 4.6.1 RC we have added support for WPF to recognize custom dictionaries registered globally. This capability is available in addition to the ability to register them per-control. Also, custom dictionaries in the previous versions of WPF had no affordance for Excluded Words and AutoCorrect lists. On Windows 8.1 and Windows 10, these scenarios are now enabled through the use of files that can be placed under %AppData%\Microsoft\Spelling\ <language tag> .

  • The files should have extensions: .dic (Added words), .exc (Excluded words) or .acl (AutoCorrect).
  • The files should be UTF-16 LE plaintext that starts with the appropriate Byte Order Mark (BOM).
  • Each line should consist of a word (in the Added and Excluded word lists), or an autocorrect pair with the words separated by a vertical bar (“|”) (in the AutoCorrect word list).
  • These files are considered read-only and are not modified by the system.
  • Note: These new file-formats are not directly supported by the WPF spell checking API’s, and the custom dictionaries supplied to WPF in applications should continue to use .lex files.

Also, see KB3088234 for important additional details.

Per-Monitor DPI Support

Today, WPF applications are system-DPI aware – this means that the applications are scaled by the OS to appropriately depending on the DPI of the monitor on which the application is being rendered. This can result in loss of sharpness, blurry text etc. Application developers have to write additional native code to enable per-monitor DPI awareness in WPF applications.

Given the recent proliferation of high-DPI and hybrid-DPI environments in the ecosystem,  we’re working on a way to enable, out of the box, per-monitor DPI awareness in WPF applications. If you are interested in trying out a preview version of this support, please complete the following survey (available until November 6th). We will be reaching out in the next couple of weeks to those who have signed up and provide invites for downloading the installers from Connect.

Additionally, we are continuing to execute on our previously communicated investment areas and are actively listening to customer feedback. Please send us your feedback through replies to this post, email, Connect bugs and User Voice requests.

 

Author: Harikrishna Menon, Senior Program manager, Visual Studio Client Tools Team

Hari is a Program Manager with Microsoft, and works on the Xaml Experiences Team in Visual Studio. He has been with Microsoft for over 6 years, and has shipped multiple versions of Visual Studio working on a variety of XAML tooling experiences spanning different XAML platforms like WPF, Windows Phone and Windows Store.

Comments

  • Anonymous
    October 29, 2015
    Thanks WPF team - it's good to see all the new things being added to my money maker!

  • Anonymous
    October 29, 2015
    Thank you for your hard work! Will the new DirectX 11 capabilities of D3DImage enable us to create stereoscopic 3D WPF apps? If yes, will there be samples available to look at? We are interested in 3D images i.e. swapping a stereopair of images at 120Hz.

  • Anonymous
    October 29, 2015
    Really good news! Thanks for your investments in WPF. Desktop applications are still alive...

  • Anonymous
    October 29, 2015
    Good news ! Tks a lot for these improvments

  • Anonymous
    October 29, 2015
    @sparky, @ jdtrepanier, @T.Kerry: Thanks :)

  • Anonymous
    October 29, 2015
    @Harikrishna Menon Does new D3D11Image could output more than 60 fps per second?

  • Anonymous
    October 29, 2015
    Is there something .NET 4.6.1 specific about DirectX integration? Sample seems to work for me and I don't have it installed.

  • Anonymous
    October 29, 2015
    Any news on WPFLocal?

  • Anonymous
    October 29, 2015
    The comment has been removed

  • Anonymous
    October 30, 2015
    Thanks for the update.  Please keep it up.  We are still out here and using WPF.   Unless and until UWP apps ( targeted at the desktop ) are able to fully replace the functionality available in WPF.

  • Anonymous
    October 30, 2015
    @Black joker: No, we are render on the D3DImage happens on the WPF render tick, so we are still limited to 60fps.

  • Anonymous
    October 30, 2015
    @szoke: As mentioned in the post and reasons outlined, we are not pursuing WPFLocal at this time .

  • Anonymous
    October 30, 2015
    @small_mountain: At this point, there are no plans to bring SBCP into WPF since it would require significant re architecture of the platform.

  • Anonymous
    October 30, 2015
    The comment has been removed

  • Anonymous
    October 30, 2015
    Great to hear about per-monitor DPI for WPF apps - and, I might add, about time! Do you have an ETA for when you intend to ship this feature? (I understand that you cannot give a definite time, but a rough estimate would be nice).

  • Anonymous
    October 30, 2015
    @The WPF Team then you need to rework your architecture, because your D3DImage is just a crutch and its not working correctly also using shared surface, which have its own limitations. Maybe it is time to make a complete upgrade of you rendering layer to really improve something? Because for now your DX stuff is working awful. I thought you will update your rendering layer to DX12, but you prefer to stay on DX9 till the end of the days. And you spend the whole year making this inefficient D3D11Image control? I was waiting much more from your team. It is the disappointment of the year.

  • Anonymous
    October 30, 2015
    The comment has been removed

  • Anonymous
    October 30, 2015
    good i like wpf more than uwp

  • Anonymous
    October 30, 2015
    @LKeene - You're welcome. We'll track that question and respond to it as a GitHub issue here: github.com/.../7

  • Anonymous
    October 30, 2015
    @Asbjørn - per monitor DPI, assuming the rest of the work and feedback goes well, would make the next version after WPF 4.6.1. 4.6.1 just released yesterday for its RC (release candidate), which means the RTM version should come soon. The timeframe for the next release after 4.6.1 is not yet public. But we've shipped about 9 versions in the last nine years: 3.0, 3.5, 3.5sp1, 4.0, 4.5, 4.5.1, 4.5.2, 4.6, 4.6.1. -- about once a year.

  • Anonymous
    October 30, 2015
    @Black Joker - Sorry that you are upset. Would love to talk with you about it, to understand what your needs are for our product. Please email me and we'll chat - rrelyea at microsoft.com

  • Anonymous
    October 30, 2015
    @The WPF Team - Okay, well then, how is it coming with the new platform that will replace WPF that has the features we desperately need?

  • Anonymous
    October 30, 2015
    @The WPF Team - Or, to be less flippant about it: MFC is older than the Internet, and WPF (which never really replaced MFC due to its lack of immediate mode graphics) is clearly in mothballs except for the few tweaks that Microsoft is allowing the tiny remaining team to do.  Then, what is the future of desktop development?  Is the plan that UWP will evolve into the only development platform that anyone could ever need, with WPF just limping along until that day?  Or something else?

  • Anonymous
    October 30, 2015
    @The WPF Team - When do we see improvements in the areas

  • fixing memory leaks,

  • updating the theme/styling to match Windows 10 (e.g. ListView with header, DataGrid),

  • fixing major bugs in WPF Ribbon ? Unfortunately, I'm not interessted in any of the improvements done for WPF 4.6.1.

  • Anonymous
    October 30, 2015
    In the future, is there any chance that UAP tool set and WPF could merge into one to cover both classic desktop and current UAP App?

  • Anonymous
    October 30, 2015
    Hey,  good to see some info on WPF progress...will we still be getting defer load strategy?

  • Anonymous
    October 31, 2015
    @Mark - Can you point us to specific memory leak issues that you would like us to fix?  We are also actively considering fixing the Ribbon bugs that have been filed in Connect.

  • Anonymous
    October 31, 2015
    @James Wilock: Defer Load strategy requires extensive changes to the framework and we wanted to ship that as part of WPF Local given the compat concerns. Since we are not pursuing that strategy anymore, Defer local is not something we are considering at this point.

  • Anonymous
    October 31, 2015
    @Vincent: UAP apps can now run in classic WIndow mode. What are the features you are looking for in UAP to bridge the gap with classic desktop apps?

  • Anonymous
    November 02, 2015
    @WPF Team: "What are the features you are looking for in UAP to bridge the gap with classic desktop apps?"

  1. DataGrid Control
  2. SQL Server data access with Entity Framework
  3. Other basic controls like numeric up/down
  4. Proper keyboard input. As things stand UAP keyboard input is a joke.

  • Anonymous
    November 02, 2015
    The comment has been removed

  • Anonymous
    November 02, 2015
    @ Jportelli: I have forwarded to feedback to the right team.

  • Anonymous
    November 03, 2015
    What's needed is WPF on ios or android.

  • Anonymous
    November 04, 2015
    @WPF Team: "What are the features you are looking for in UAP to bridge the gap with classic desktop apps?" A TreeView control please, and the equivalent of HierarchicalDataTemplate. A mechanism by which UAP apps can communicate via a socket to a server on 'localhost'. Yes I understand that this would violate the 'network isolation' policy, but this capability could have to be enabled explicitly in the UAP app's manifest ; allowing access to a particular port, just as one allows access to the camera and mic. This would let us build UAP's that act as front-ends to existing business-logic code running as an ordinary Win32 process.

  • Anonymous
    November 06, 2015
    Great to have extra languages for contextual spell check in text controls. Given the list of supported languages is dynamic, is there any way to detect whether a language is supported for spell check at run time?  Our application allows users to change the spell check language at run time as users often edit files which are written in a different language to their input or or thread culture. Will existing applications compiled against .NET 4.0 / 4.5 / 4.6 running on Windows 8.1 and Windows 10 with .NET 4.6.1 installed automatically get access the language feature or will targeting be required?

  • Anonymous
    November 06, 2015
    Thanks for the update.  Any update is good news in my book.  MS should be more proud of WPF, it's a huge asset to the windows environment.  I don't know if the "lets copy everything Apple do" approach with windows store is good from a business perspective but from a developers perspective I hate it.   The excuses for leaving WPF in the cold on things like Win2D to force people to develop for the store is disgraceful.  WPF developers are MS loyalists.  If you don't get us then you have zero chances with Android, Apple devs jumping on board and the attitude of "Use windows store or you don't get any new stuff" has started to convince me that pure Web Apps are the future not MS Apple Store-a-like. Bring WPF in from the cold.  Give it Win2D, enhance the native 3d, Fix the broken stuff, and fill in the gaps that were left by the talent that built this brilliant technology in the first place.  The MS of old gave us C# .NET and WPF, Direct X.  Now we get some spell checking improvements....  and endless propaganda to use their new inferior platform so they can take a %.   Sorry for the negativity, it must be hard working on WPF with what seems like such a small team or company support.  The Direct X stuff might come in handy to the projects I am working on.  

  • Anonymous
    November 08, 2015
    Is that ALL "performance improvements" you did?!!! You waste so many years, didn't you see that even WinForms works faster than your "accelerated" WPF? Where is acceleration? Why it's still slow? Also I want feature "dynamic loading of layout" - since XAML can live outside, I want to have two different XAMLs (above the same controls) to lay controls differently, but preserving all code/events. Like MainWin.Load(@"c:bzbz.xaml") - at runtime I want to change appearance of Window.

  • Anonymous
    November 09, 2015
    Before we'd even consider making a UWP port of our desktop app, I'd need these for starters...

  1. Immediate mode graphics (currently done with WriteableBitmap with big memory overhead).
  2. A menu bar. Not app bar, not command bar. A real menu just like we have today.
  3. IDataObject drag and drop. Not gonna rewrite all that working code to a contract or something screwy.
  4. Launch apps with x2 click from shell with IDropTarget invocations.
  5. Multi-select tree control. Heck need this in WPF. Using Telerik for now. The real question about bringing a WPF or even more traditional Win32 desktop app to UWP is "Who's gonna pay for this?". Time is not free and it ain't just a few week conversion.

  • Anonymous
    November 10, 2015
    @schroedl, @steve421: Can you open UserVoice ideas here for the ideas you mentioned? wpdev.uservoice.com/.../58517-xaml-apis-winrt

  • Anonymous
    November 10, 2015
    @Andrew, WPF applications targeting .NET 4.x should be able to make use of the updated spell-checking capabilities as long as they are running on Windows 8.1/Windows 10 with .NET 4.6.1. Unfortunately, there is no mechanism present today to dynamically enumerate languages available for spell-checking in WPF - we will look into adding this capability in a future release.

  • Anonymous
    November 11, 2015
    The comment has been removed

  • Anonymous
    November 12, 2015
    I am sorry, this is not enough. I have been waiting for x:Bind and x:DeferLoadStrategy and expecting that will bring some performance improvements. :( At least I hope that VS 2015 Update 1 will solve all my problems: Xaml editor freezing and wrong build (sometimes are not detected changes and builded version is old). In future WPF please improve UI virtualization capability and UI performance when UI is really complex.

  • Anonymous
    November 26, 2015
    Make please the ISpellChecker interface public. So can we make the custom spellcheckers for unsupported languages or dictionary storages.

  • Anonymous
    November 28, 2015
    Any particular reason not to also support UTF-8 for user dictionaries?  With or without the "BOM" (in quotes because UTF-8 doesn't actually come in more than one byte order, so when used with UTF-8, it marks something slightly different than the byte order)?

  • Anonymous
    November 30, 2015
    It's too sad to see that one reason to drop WPF local is Ngen. Ngen is a great tool and a no-brainer for anybody looking for more reactive wpf app, but the fact that it requires Administrator privilege to interact with the GAC is a real pain. I created this suggestion in UserVoice a few months ago about this : http://bit.ly/1PoNshz. This would definitely make ngen easier to use in many scenarios. Please reconsider your decision regarding WPF Local and let us decide whether the amount of complexity it brings worth it or not , depending on the scenario.

  • Anonymous
    November 30, 2015
    So 4.6.1 went live today. Were there any additions between this post and RTM?

  • Anonymous
    November 30, 2015
    I have posted this comment on a VS blog just now (blogs.msdn.com/.../visual-studio-update-1-rtm.aspx), just realized this is probably a more appropriate place for this. I don't know if I should post this issue here or the .NET blog, going to try this one. Starting up WPF applications is slowed down significantly with this service pack. This same issue was present with the RC, but I didn't comment hoping it would get corrected for the RTM (just uninstalled). It means about 2-6 seconds overhead before starting up every WPF application regardless of debug/release configuration, regardless if it was built earlier or with this service pack installed. This is especially annoying during debugging, which makes the current update unusable for me (this time I made sure to create a restore point before installing, fortunately). Am I the only person with this issue?

  • Anonymous
    November 30, 2015
    I hope the Intellisense popup issue in XAML designer is fixed, which I had earlier faced with VS 2015 RTM and had rolledback to VS 2013.

  • Anonymous
    November 30, 2015
    Awesome, thank you! Any plans for WebAssembly compilation?

  • Anonymous
    November 30, 2015
    I would like to see improvements that will reflect LOB applications.

  • DataGrid performance improvements.  The control is still very slow even in virtual mode.
  • CollectionView performance and bug-fixes.  Feeding thousands of records in a bound ObservableCollection results in poor performance regardless whether cross-thread access is enabled.  Cross-thread access has obscure bugs in cases of re-entrancy.
  • Generally, UI is slow.  One would expect a much better performance on today's hardware.
  • Tools: we need debugger for bindings.  This is an absolute must.

  • Anonymous
    November 30, 2015
    @Pavel - I have forwarded this to the engineering team. They will respond on this soon.

  • Anonymous
    November 30, 2015
    @Samuel - I have forwarded this to the engineering team. They will respond on this soon.

  • Anonymous
    November 30, 2015
    @schroedl: No, this is current information.

  • Anonymous
    November 30, 2015
    @snupp - We are looking into this. Someone should be reaching out to you shortly in the VS blog.

  • Anonymous
    November 30, 2015
    @Anand: Can you mail me at harikm@microsoft.com with more details on the issue. I can let you know if this is fixed.

  • Anonymous
    November 30, 2015
    @Dev: Not at this time.

  • Anonymous
    November 30, 2015
    @Nick: Thanks for the feedback.

  • Anonymous
    December 01, 2015
    @Pavel Kimmerle, The ISpellChecker interface is already public. Please see msdn.microsoft.com/.../hh869767(v=vs.85).aspx. This is not a WPF interface - it is a Windows/OS interface. WPF just happens to use this interface for its own implementation on .NET 4.6.1 on Windows 8.1 and later OS'. Please keep in mind this caveat though - WPF's implementation can change to use some other spell checking facility in a future release of .NET. We don't expect this to happen anytime soon, but the fact that our implementation in .NET 4.6.1 changed to use a new spell-checking facility (i.e., the ISpellChecker interface) should inform application developers.

  • Anonymous
    December 01, 2015
    I'm still unclear as to whether or not I can access and use the stereoscopic3D capabilities of DirectX 11 via the new D3DImage capabilities in WPF? Anyone?

  • Anonymous
    December 02, 2015
    @Samuel Bronson: >> Any particular reason not to also support UTF-8 for user dictionaries?   The *.lex format that we have always supported in the form of pack:// URI's supplied directly to controls through SpellCheck.CustomDictionaries (msdn.microsoft.com/.../system.windows.controls.spellcheck.customdictionaries(v=vs.110).aspx) does not require an UTF-16 encoding. It continues to work as before. The additional support for custom dictionaries that uses placement of appropriate *.dic, *.acl or *.exc files under %AppData%MicrosoftSpelling<language tag> is a Windows OS feature which WPF just happens to leverage. The simplest answer to your question is "...because WPF didn't make up these rules - we just inherited them from ISpellChecker" :-) I checked with some folks in Windows who are more familiar with why the underlying ISpellChecker interface based API's require custom dictionary files to be encoded as UTF-16 LE with BOM present in them. From what I understand about the rationale, I think it is because these custom dictionaries can plausibly be edited by someone in a text editor, and having a clear BOM present in these files helps ensure that well behaved text editors would refrain from inadvertently re-encoding the file to whatever encoding that editor happens to prefer. In addition to this, UTF-16 LE  just happens to be the favored encoding on the Windows OS platform - most API's that accept Unicode strings (for e.g., PCWSTR) default to this encoding. See msdn.microsoft.com/.../ff381407(v=vs.85).aspx that alludes to this fact.

  • Anonymous
    December 03, 2015
    The comment has been removed

  • Anonymous
    December 03, 2015
    When you ask what is missing to code for WUP... There is such a huge gap between Universal Platform and Win32... where to begin? I understand the idea of isolation and security, however, for a lot of custom business applications, using sockets, connecting to SQL, reading/writing in various directories, the need to call methods in 3rd party C++ DLLs, accessing hardware, etc.. the list is just too long. If at least, like someone mentioned previously, we could get some sort of permission flag that would let the WUP call a backend or something. Right now, all the code we've invested in (C++, WPF, DLLs, etc.) is just not portable/usable. We're stuck in a dead end with a new API that's very limited for anything except phone-like applications.

  • Anonymous
    December 04, 2015
    @LKeene: We have opened a GitHub issue here to track this github.com/.../7

  • Anonymous
    December 06, 2015
    It would be great to see two-way bindable SelectedItem for TreeView, two-way bindable SelectedItems for ListBox and DataGrid because it’s important for MVVM. SelectionMode Extended and Multiple for TreeView would be not wrong. Update the System.Windows.Controls.Ribbon: visualstudio.uservoice.com/.../9671640-update-the-system-windows-controls-ribbon

  • Anonymous
    December 07, 2015
    It would be great to see two-way bindable SelectedItem for TreeView, two-way bindable SelectedItems for ListBox and DataGrid because it’s important for MVVM. SelectionMode Extended and Multiple for TreeView would be not wrong. Update the System.Windows.Controls.Ribbon: visualstudio.uservoice.com/.../9671640-update-the-system-windows-controls-ribbon

  • Anonymous
    December 07, 2015
    @MarcoGR: Thanks for the feedback. We are looking into fixing the issues enumerated in the UserVoice. While styling updates is not scope at this time, we are investigating the other issues mentioned in the UserVoice.

  • Anonymous
    December 07, 2015
    Any plan for x:Bind in WPF?

  • Anonymous
    December 08, 2015
    @Yupei: At this point, we are not looking into investing in this feature.

  • Anonymous
    December 09, 2015
    Nice to see WPF is active again!

  • Anonymous
    September 01, 2016
    Any hope of a blog post or two talking about WPF futures? Maybe a road map of what you guys are working on for the next release? Its been a while since this post.