featuresuggestions

Summary: What would you like to see us do in the next release of WPF? More detail is better than less (i.e. don't just say "make it faster", give us specific examples if possible).

Conventions:

		    * Please don't delete someone else's suggestion, even if you don't agree with it. Share why you disagree or agree, or add more detail by appending a paragraph to the lines already there.
		    * Add your name and optionally email address after your suggestion so we can contact you for more information if that's OK.
		    * Feel free to reorder these to add structure (e.g. by feature area).

SaveFileDialog for XBAPs

XBAPs run in a sandbox in which SaveFileDialog is disabled. OpenFileDialog has a safe open method which works great.

In order to get a document to save from an xbap a programmer has to:
1) build a web service that saves a file to a web server or database.
2) build a process to periodically clean those files off the web server or database.
3) Use a hyperlink link to a the file (only a hyperlink will work, see http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1212612&SiteID=1) This is lame because there is no way to create a hotkey (say Control-S) to trigger a save. They hyperlink has to be clicked for it to work. Hyperlink.DoClick() will throw a security exception.
4) The url for the hyperlink has to be calculated before the hyperlink is actually clicked. So you've gotta create generate some lame random filename in the page load or whatever and then generate a new one after the hyperlink is clicked.
5) Add a RequestNavigate event to the Hyperlink which gets trigger before the hyperlink gets browsed to. Inside this you need to call the web service. This will cause an incredibly lame double waste of bandwidth as the file gets uploaded, just to be immediately downloaded again.
6) Depending on the situation, you might need to get "Content-disposition: attachment" to be set on the file download header, which could involve writing an ASP page that handles the download and sets the header.

For an example of all this hackery check out http://vectorstudio.com

'Better/Full' DirectShow support and hi-performance access to a bitmaps pixels

It would be nice to be able to create my own graph and render to WPF. I can sort of do this now with my own custom source filter + custom protocol reged, but this is not enough as I have to rely on the Intelligent connect of the graph's filters. Win32 interop is not a favorable solution as the WPF goodies are too good to pass up. Also to be able to get access to a bitmap's pixels like you could in GDI. All WPF methods of this seem to involve creating a whole new bitmap (even WritableBitmap seems to) which seems to have some overhead, heh.

Thanks

XamlWriter.Save in XBAPs

XamlWriter.Save is disabled in XBAPs. In the mean time I use Rob Relyeas version at http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=718928&SiteID=1

There doesn't appear to be any security gained by having it disabled so it'd be really nice if I didn't have to use Rob's version.

This is used at http://vectorstudio.com for saving drawings.

Support for current selection binding using a Hierarchical databound treeview

It would be nice if I could use a hierarchical databound treeview to control the display of objects in an adjacent panel. In my case I have a three level treeview and would like to display a level-specific template in the panel to the right of the treeview. The panel displays the details of the currently selected node using a template appropriate to the level of the node. At present this is far more difficult to achieve than it should be, especially with regard to binding a template to the currently selected node in the tree.

Native support for a DragImage

It'd be helpful if WPF had a built-in concept for a DragImage - something that follows the mouse around during a drag operation to give the user an idea as to what they are doing. I've synthesized a drag image in my app using an adorner but that has drawbacks. For example, if you don't override all of the PreviewDrag* methods in a particular control in your app ( like the menu ) the drag image disappears while over it. The returned DragDropEffects could be used to easily modify the DragImage. It's also been cool if the DragImage would work across WPF apps - perhaps if they were linked somehow to what was contained in the DragEventsArgs so if the drag was going to drop text it would show a nice rendering of the text but if it could sink and image it would show that instead.

Is this what you guys are looking for as far as feature requests go? Should I link to my profile as well? http://channel9.msdn.com/Niners/jhndnn.

(tims) That's great - thanks!

Evaluation of expressions in XAML properties

It'd be useful if XAML were able to evaulate expression in the attributes of an XAML document. Being able to bind by doing TextBlock Text="myWindow.Title" or TextBlock Canvas.Top="myTextBlock.ActualWidth/2" would be a lot nicer than the current implementation (think MXML style binding).

(Wolf Schmidt MSFT) : WPF already has a concept that is similar to expressions called markup extensions, which are used to return objects from out of strings when more complicated logic than just a TypeConverter is appropriate. Your first case is type-to-type equivalent, so you can do this pretty easily with existing {Binding} (which is just such an extension). Something like TextBlock Text="{Binding ElementName=myWindow, Path=Title}". Your second case introduces some evaluation to the expression, so that's not available out of the box, but you could tackle that one of two ways: apply a ValueConverter to bound data (even ElementName style binding), or you could write a custom markup extension to do math for you. The latter approach is actually an interesting sample idea, which I'll see if I can add to an SDK refresh some time. I wish I could point you to something existing in the SDK, but unfortunately I don't have a good topic on custom markup extensions yet.

Vista's Aero shadows on transparent windows

It's frustrating that transparent windows can't have the same shadows as a 'standard' window, and because of this they don't seem to fit into Vista's Aero environment.

I realise of course that shadow's can be created within WPF, but they don't look or act the same and seem to be much more resource intensive. Also, many developers making their own shadows fail to set a different shadow depth for when the window is not in focus.

Better DirectX Interop

I'd like to see a class similar to the WindowsFormsHost or the HwndHost for DirectX. While technically it is possible to host DirectX content in an HwndHost, when the Hwnd has focus, no WPF events are fired. It seems like it would be possible in the DirectXHost to treat the inner Hwnd as an empty WPF element and let DirectX be responsible for drawing in it. But MouseEvents, KeyboardEvents, DragDropEvents, etc could all be exposed seamlessly by WPF. I understand that it probably still couldn't be rotated, transformed, participate in alpha & z-order processing since it would be a physically seperate Hwnd. However, it seems like it could expose all the input events correctly...

'Classic' ContextMenu

I'd be nice to have a way to use the Context menu in a manner similar to Win32s TrackPopupMenu. All it would need would be a way to determine what MenuItem was active when the menu closes. If the user canceled the menu by hitting ESC or clicking away from the menu this value could be null. The most straight forward place for this would be to add a MenuClosingEventArgs which contained this value and then pass that into the Menu.Closing() event.

An Official Clipboard format for exchanging XAML

We have no idea how to share the beautiful charts, diagrams, and text that WPF apps produce with each other. e.g: I should be able to copy/paste between IE, Office, Blend, Expr. Web, My Scientific App, etc. to create documents, reports, etc. The picture today is too muddy and we're left to sort it out amongst ourselves.

Consider the result of COPY in these apps:
- IE hosting Xaml with a flow document: Puts a clipboard format named "Xaml" on the clipboard. Getting the data object for this format returns NULL for the HGLOBAL.
- Same Xaml (Flow Document) running outside of IE: Puts "Xaml" cf which can be retrieved as text. The content is <Sections> from the flow document.
- Expression Blend puts a "cfXaml" format which appears to be an XPS package of Xaml. Attempting to stream into an app using DataFormats.XamlPackage throws an exception. Must be proprietary format.
- My own app. I see DataFormats.Xaml but that's described as for use only by RichTextBox.
- My own app. I see DataFormats.XamlPackage (ditto above).
- Office 2007 handles none of this. How do we get Xaml into Office?

Advice we recv'd from MS was to investigate writing OpenXML docs with DiagramML embedded. WTF?! We need a Xaml <==> DiagramML tool. Or perhaps a Xaml <==> EMF

Obviously, sharing diagrams/xaml between apps has limits (maybe no video) and would accept a subset of Xaml. Our customers demand publishing charts in professional journals. EMFs are buggy with transparency, clipping and other issues. Sharing Xaml seems like the way to go. Pasting a bitmap is unacceptable!! It must scale.

Support for TaskDialogs

Since it seems as though Microsoft is pushing TaskDialogs it'd be nice to be able to use this functionality natively in WPF. I'm currently hacking something together that looks and acts like a task dialog but i'd much rather use something native. Of course it should also be styleable.

Custom Mouse Cursors in XBAPs

They appear to be disabled in xbaps (see: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1536464&SiteID=1&mode=1) but this is not documented anywhere.

3D Polylines and general scene graph things

What I'd really like to see is WPF mature in a slightly more flexible 3D Scene Graph library. It is very close to being there, but there are a few things that make it unusuable for some 3D applications.

Specifically, it'd be great if we had support for:

lines in
lines in 3d space whose width are described in world space, and their appearance is effected by perspective transforms
lines in 3d space whose width is constant in screen space, regardless of perspective transform
vertex colours for lines
Apply textures to lines
Vertex colours for meshes.
Support for 3D textures
Some basic support for shaders.

Phil Martin
phil -at- eveandphil dot com

Better 3D performance, HDR, and Shader support.

Currently WPF 3D has limited use due to lack of performance when frame rates of 30 or more are needed. It needs to be about 10x better to allow more robust data visualizations. It is understood that WPF 3D is not a game platform, but the number of models and the vertex limits on these models quickly drop performance on data visualizations with a few hundred objects. The main problem is composition. As more layers are added, the limits of 3D performance cause other 2D areas to quickly lose frame rate.

Also, there needs to be a shift to HDR texture support and Shader support. 3D design tools create texture around shaders. If WPF 3D is going to be viable for the next generation UI and data visualizations, it must support HDR,handbook shaders and allow current textures being designed today with 3D tools to be used.

I would propose that in v2.0, there is perf enhancments with the ability to overlay WPF over DX. In V3.0, I would like to see a 10x perf increase, HDR and shader support. The end date for all this would be sometime in 2010.

MediaPlayer enhancements.

Right now the MediaPlayer class is unable to access resources embedded in the assembly, requiring applications with numerous media assets to provide them as loose files when deployed in an XBAP. This is a maintenance problem for some people, as well as a performance issue since each asset requires an HTTP GET to occur, which could be alleviated if MediaPlayer were able to support the pack://application:,,,;component/filename.ext format.

BAML compression

BAML provides a welcome reduction in deployed file sizes for those who have a lot of XAML in their project. However, as use of 3D models increases the verbose notation of XAML becomes a size issue, even with the use of BAML. It appears that the BAML compression is probably more of a tokenizer than a true compressor because merely zipping a 1244 KB XAML file with a few 3D models in it results in a .zip file that is 142 KB, whereas the BAML for the same XAML is 613 KB; however, if the BAML is compressed it reduces to 63 KB! This would seem like an easy thing to hook into the deserialization of the BAML, and has potential to reduce BAML related file sizes by nearly 90%.

Back to WPF.HomePage