WPF adorners vs custom adorners? - wpf

I would like to create an diagram editor and there is a requirement to move and resize huge amount of items.
And I also I have heard that default WPF adorners are slow.
What is the best way and recommendations to make responsive adorers layer?
Custom or based on the WPF built-in adorners?
As far as I know expression blend is also using its own adorners implementation.
For me the performance is more important than implementation time.
Thanks.

After the real implementation an testing:
If you have a lot of complex controls and performance meters than it's better to use OnRender() method. Preview events are working fine to find out that you about to interact with a fake adorners, but it's an extra work.

Related

Difference in display of WPF and Windows Forms applications

Actually, I have started learning WPF. I have few months of experience in developing Windows Forms applications. Though, I am getting the meaning of a WPF application, but still I am not able to differentiate the difference between two, on the basis of their output.
With reference to this Link: Device Independent Pixel (DPI), I have learnt that whenever the operating system render a WPF application it manages its size itself according to its resolution.
So to check this difference, I created two demo applications in both frameworks and changed the resolutions as well.. but I didn't find any satisfactory difference. Which could explain it is a WPF application and this one is a Windows Forms application.
It does not create any scroll bar on maximizing and doesn't make the button big or small on changing the resolution.
I have read somewhere that Visual Studio 2010 has been rewritten in WPF. But in my experimentation I saw that, (on changing the resolution of desktop) it makes text and graphics unreadable/blurry. On re-sizing its window, everything was getting hidden except the menu-bar. And the menu-bar content was shifting its positioning, e.g. far right one menu items were shifting down. Why?
Kindly make me correct & explain a little more bit (this display issue) too.
To answer this question properly I should write a whole chapter, but I keep it short:
There are three major differences between a WPF application and a Windows Forms application: Layout, Render, Presentation
Layout:
WPF layout system provides a greater flexibility in arranging the elements on the fly. It is based on the Element Bounding Box (as opposed to precise pixels in WinForms) and Measure and Arrange mechanics (as opposed to UpdateLayout in WinForms) that automatically and dynamically finds the place for each element without any need for a manual update.
Basically, all elements bounding box are measured first and then are arranged using multiple methods such as Measure, MeasureCore, ArrangeCore, MeasureOverride, etc.
Unlike WinForms, where you have a pixel-perfect size for everything, in WPF you have much more options and complexity such as Width, ActualWidth and DesiredSize (and even Transforms as LayoutTransform) for the same element.
This is why
As you type in a WPF TextBox, its width might increase and push other elements away or even push some elements into a new row (like the menu bar you've observed)
As the size of a control changes, it affects the available space for other elements. So their size and location might change accordingly.
When the window is being re-sized or resolution is changed, it immediately updates the layout and changes the size of elements in order to fill or fit the space. Here you'll find out more about Layouts.
using Margin alone (without using layout capabilities) to arrange elements is not the best idea in WPF. As it's the WinForms mindset which isn't much helpful while developing WPF.
Render:
WPF uses double data type for Layout (as opposed to pixel-perfect WinForms) and therefore you might see the edges blurry sometimes, but it can be avoided with SnapToDevicePixels=true.
WPF is much more efficient in utilizing the GPU to render a GUI. Try a grid of 30x30 TextBoxes in a Windows Forms application and a WPF application. No matter how messy you write the WPF, it never blinks and it still runs much faster than Windows Forms. Even adding a handful of animations, visual effects and styles on them does not hurt your performance like in Windows Forms.
Remark: To avoid a speed decrease and blinking in a Windows Forms application, you should set DoubleBuffer of the form to "true".
You can use any Transform as RenderTransform to easily implement smooth zoom/rotate, or develop custom GPU-based shader effects, and much more in WPF. (I think everyone agrees that doing such things in WinForms is feasible but real pain and you most likely will give up and move to GDI+ or DX if not out of frustration then because of the bad performance.)
And the last and the most important:
Focus on presentation:
When develping WPF Applications you have to stop thinking in Windows Forms: No more UI events, accessing controls by their names and writing logic in code-behind and start to think in WPF: Binding, Commands, Resources, Styles, Templates, Converters, DependencyProperties and their callbacks.
The real power of WPF lies in separation of 'View' and 'Logic', Which can be achieved using the MVVM pattern.
It makes the most visually-complicated problems quite simple and easy to develop and easy to write Unit Tests for.
Once you got the hang of it, you will realize there's no limit in how you can present the data or show off an awesome GUI looks.
If you've planned to switch to WPF, you've made the right decision. Always stick to MVVM and AVOID CODE-BEHIND AT ALL COSTS! (i.e. unless you are doing a pure UI operation: do not write code in .xaml.cs files, do not access x:Name in cs files and avoid UI events.)
Windows Forms (WinForms) and Windows Presentation Foundation (WPF) are two different ways of building the user interface for your application. Windows Forms is the older technology and its controls are found in the System.Windows.Forms namespace. WPF is a newer technology and its controls are found in the System.Windows.Controls namespace.
WPF
Pros:
Powerful styling and skinning structure
Easy to create your own look and feel
Does support Windows Forms
The future technology for developing Windows Vista applications
The ability to reuse existing code
Highly advanced data binding possible
Cons:
Declarative vs. procedural code
Requires .NET Framework 3.0
Compared to Windows Forms, still in development phase
Requires Dx9 compatible video card for advanced graphics
Windows Forms
Pros:
Extensive documentation to be found on the Internet
Plenty of examples
Does support WPF
Cons:
How long will this be supported? (I've read somewhere that Microsoft is just developing WPF now, only maintenance for Windows Forms).
Design your own look and feel in an application is a lot of work.

Coded UI Test - get my custom object (WinForms)?

I want to create an automated UI test that will test my syncfusion grid. My problem is that the recorder can't recognize this control (or any syncfusion control). I've searched a lot in the internet but I couldn't find any extension so the recorder will recognize my controls (I'm using WinForms, not WPF!), or at least a way to extend the recorder abilities so syncfusion's controls will be recognized somehow.
Is there any easy way to extend the recorder? Or is there any extension available?
Or maybe can I get the grid object from the WinClient that the recorder generates?
Thanks!
Start your program. Run the Spy++ utility. Type Ctrl+F to start the finder tool and drag the bulls-eye onto your form. Ok, Synchronize and have a look-see at the windows that are visible in the tree. If you see regular Windows Forms controls, like a Button or a Label, but not any of the SyncFusion controls then you've probably found the source of the problem.
Component vendors that try to improve .NET controls typically do so by creating 'window-less' controls. They are not really controls, they don't derive from the Control class and don't have a Handle property. They use the surface of the parent to draw themselves, making them look just like controls. The .NET ToolStripItem classes do this. And this is also the approach WPF uses.
The big advantage is that they render quickly and support all kinds of effects that regular controls can't support, like transparency, rotation and anti-aliased window edges. The big disadvantage is that the kind of tool that you are using suddenly gets noddy and can't find the control back. Because they work by finding the Windows window back on your form, there is no window for them.
This is a hard problem to solve, the 'control' exists only in memory and there's no good way for a tool to find it back. Using Accessibility is about the only other way for such a tool to find a control that I can think of. Which would have to be implemented by the control vendor first, a somewhat obscure feature that gets easily overlooked. You really do need the help of the vendor to find a workaround for this. Shouldn't be a problem, that's why you paid them the big money.
This is Rajadurai from Syncfusion. Thank you for your interest in Syncfusion Products. To make UI Test Automation recognize Syncfusion grids(WinForms), some internal support need to be provided in grid whose implementation is in progress and about to be completed. Please submit an incident through Direct-Trac for any further related inquiries in the following link.
http://www.syncfusion.com/Account/Logon?ReturnUrl=%2fsupport%2fdirecttrac
You can also contact us through support#syncfusion.com. We are happy to assist you.
Regards,
Rajadurai

Winforms widget to display a grid of constantly updated numbers?

I'd like to create a Winform app (Mono support would be a huge plus) to display a grid of rapidly updating numbers, while not running into redraw problems while scrolling.
From searching around I've found:
Telerik GridView
which seems to be exactly what I want. Is the Telerik path the way to go? Or is the capability available within the standard .NET tool set? If so, which widgets should I be looking at to implement such an application?
Thanks in advance for your help!
All the Grid components from vendors are going to have performance issues if you change the attached values very very quickly. So if you need high performance you really need to create your own. If you are concerned only about flicker and the update does not need to be amazing quick then you will be fine with Telerik or indeed any other vendors Grid component.
You could consider implementing Virtual Mode on the Telerik RadGridView to overcome any performance issues you might encounter.
The demo application included with the controls contains an example of a rapidly updating grid. Although its just a small demo, if you resize the window to be smaller the scrollbar will appear and you can scroll without any redraw issues. You can access the demo under GridView -> Performance -> High Refresh.
Unfortunately, the Telerik WinForms controls aren't compatible with mono.

.NET WPF UI Component Library

Which library to use for WPF?
Infragistics
ComponentOne
SyncFusions
ActiProSoftware
Telerik
#Reed - None of the Syncfusion WPF controls were ported from Windows Forms. With the grid control, most vendors use a simple ItemsControl based architecture. We have a much more elaborate infrastructure for highly optimized cell oriented rendering. This was implemented to achieve performance as close to Windows Forms performance as possible. The effort on our end to deliver this solution when contrasted with a pure ItemsControl based approach was at least 5x. We have a lot of customers using our Windows Forms controls in real-time scenarios and we wanted to give them the ability to move over to WPF without losing on the performance front. Our key controls offer excellent rendering performance even with millions of data points in direct contrast to solutions that are based on a simple ItemsControl based approach. Our controls often have a steeper adoption curve than others but in the long term we do believe that they are easier to maintain and update. Just my two cents:) Also, we are really keen to work with you on any issues that you are running into. Please let us know. My email is danielj(at)syncfusion.com.
#Tom - If you can send us feedback on the gauge we would greatly appreciate it. We are always looking for ways to improve and your feedback will be really useful.
Ultimately it depends on what you need. I think Syncfusion offers the widest and most actively deployed control suite on the WPF front. Disclaimer - I work for Syncfusion.
I work for a large firm which has long-term license agreement with Syncfusion so I had to use their products for years in pain.
I agree with Reed for Syncfusion's model. They converted their Winforms model (which has major bugs) to look it like WPF, I believe the whole suite is nothing to do with WPF, most of their controls cannot be controlled in XAML, you need to use code behind in order to style even simple things.
They are actually improving this to look more like WPF however with Syncfusion one issue is when you upgrade to a new version, it always breaks previous version based code. It is their marketing strategy and you spend weeks to figure out the new system.
One other issue with Syncfusion is they have quite poor documentation, their support is very weak, so you need to discover things on your own.
I used Telerik WPF in one project which is a much better choice, the performance is much better and the model is really easy to maintain.
We just started to buy DevExpress due to the pain of Syncfusion over years and I believe this is quite good WPF product. It is easy to use, they have really good support and nice documentation. The controls look very professional. First time I feel like I am using actual commercial .NET toolset.
*I do not work for DevExpress or Telerik.
They all have advantages and disadvantages.
Personally, I've found Telerik and Infragistics seemed more like they were designed specifically with WPF in mind.
Syncfusion's offering is more of a port of their Windows Forms product, so the design is more like they're other product lines.
That being said, each product you listed is good - and each have their own feature set. There is no substitute for trying a demo and seeing how you like working with the products in question.
I'm a fan of Component One, mainly based on personal taste.
ActiProSoftware have some good controls, but I find that they don't expose enough properties to make it easy to style and customize, though you can get around this with implicit styles.
Xceed have my favourite Grid control, lots of cool features and easy to work with.
I don't particularly like Telerik and I've never tried SyncFusion.
I would love to try Infragistics as that is one that I haven't tried, but have been really impressed with the demos. Does anyone have any comments on the architecture of Infragistics?
Like Reed said, they all have their advantages and disadvantages, but from my experiences I would recommend Component One.
HTH
None of the above, just use WPF Toolkit for DataGrid and VisualStateManager. It is not that hard to style the controls in WPF/Blend, plus it makes YOU more proficient and your code leaner.
P.S. Though, you might still use third-party reporting, since there no built in support for reporting in WPF.
If you are looking for a WPF Control Library there is the WpfDynamicUI Library.
It is an open source control building the user interface for the DataContext you provide.
It supports Charting, DataGrid, Map, Filtering, Paging, Nesting views and more...
Can be an alternative for building Line Of Business application.
PS: I am the coordinator of WpfDynamicUI

Designing a WPF map control

I'm thinking about making a simple map control in WPF, and am thinking about the design of the basic map interface and am wondering if anyone has some good advice for this.
What I'm thinking of is using a ScrollViewer (sans scroll bars) as my "view port" and then stacking everything up on top of a canvas. From Z-Index=0 up, I'm thinking:
Base canvas for lat/long calculations, control positioning, Z-Index stacking.
Multiple Grid elements to represent the maps at different zoom levels. Using a grid to make tiling easier.
Map objects with positional data.
Map controls (zoom slider, overview, etc).
Scroll viewer with mouse move events for panning and zooming.
Any comments suggestions on how I should be building this?
If you're looking for a good start, you can use the foundation of code supplied by the SharpMap project and build out from there. If I recall there were a few people already working on a WPF renderer for SharpMap, so you may also have some code to begin with.
I've personally used SharpMap in a C# 2.0 application that combined GIS data with real time GPS data, and it was very successful. SharpMap provided me the transformation suite to handle GIS data, along with the mathematical foundation to work with altering GIS information. It should be relatively straightforward to use the non-rendering code with a WPF frontend, as they already have presentation separated from the data.
(EDIT: added more details about how I used SharpMap)
It is probably a roundabout way of going about it, but you might find some useful stuff in the javascript and XAML from SilverlightEarth.com which a Silverlight 1.0-based map-tile-client. It can load VE, Google, Yahoo (there is a DeepZoom version that can load OpenStreetMap, Moon and Mars too; but since it uses MSI it doesn't really help on the WPF 3/3.5 front).
Although the javascript is a little untidy, you can clearly see it is creating a Silverlight 1.0 Xaml (dynamically sized) Canvas, filling it with tiles (Image controls) and handling zoom in/out and pan requests. You would need to make sense of all the javascript and convert it to C# - the XAML should mostly come into WPF unaltered. I have tested this Silverlight 1.0 with a Deep Zoom tile pyramid (and here) so the concepts are applicable (ie. not just for maps).
I know this works because I have done it myself to build the map viewer in Geoquery2008.com (screenshot) which is WPF/c#. Unfortunately the Geoquery2008 assemblies are obfuscated, but you might still glean some ideas or useful code via DASM/Reflector. It is still a beta so I wouldn't claim it is 100% done. I hadn't really thought of factoring out the map code into a separate control but may I will look into that if another one doesn't appear...
Incidentally I also started off with the ScrollViewer, but am planning to ditch it and mimic the javascript more closely so it's easier to re-use Image objects when panning/zooming (by gaining more control over the process than ScrollViewer provides).
These MSDN pages on the Virtual Earth tile system and the Deep Zoom file format and related links is probably also a useful reference.
Finally - I guess you've seen since this post that DeepZoom/MultiScaleImage is likely to be in .NET 4.0/Studio 2010.
Your desire to create a WPF mapping tool is similar to mine, which lead me to ask this question about DeepZoom (aka MultiScaleImage) from Silverlight. I want a WPF version. The accepted answer provides a link to a very good starting point (similar to your described thought process).
Virtual Earth has something favour to WPF
Don't know if you use ESRI software, but I hear there developing a Silverlight API for there stack so you might want to hold off.
It does not fall on my field of work at all, but you may have a look at MapWindow GIS, which has an Open Source ActiveX object that provides a lot of mapping and GIS features.
Here is a post explaining how to embed it on WPF applications:
http://www.mapwindow.org/phorum/read.php?13,13484
Download Bing Maps WPF Control sdk(Microsoft.Maps.MapControl.WPF.dll).Add as dll as referance,then change the XAML as below
**
<Window x:Class="WPFTestApplication.InsertPushpin"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:m="clr-namespace:Microsoft.Maps.MapControl.WPF;assembly=Microsoft.Maps.MapControl.WPF"
Width="1024" Height="768">
<Grid x:Name="LayoutRoot" Background="White">
<m:Map CredentialsProvider="INSERT_YOUR_BING_MAPS_KEY"
Center="47.620574,-122.34942" ZoomLevel="12">
<m:Pushpin Location="47.620574,-122.34942"/>
</m:Map>
</Grid>
</Window>
**
The main question is how you store and access the items you are going to put in the map (assuming this isn't just a picture display). Lookup scenegraph for some ideas.
Also if you want it to be more than a toy image viewer the lat long to XY scaling can get 'interesting'
Don't build it yourself - use the WPF Bing Maps Control
http://www.bing.com/community/site_blogs/b/maps/archive/2012/01/12/announcing-the-bing-maps-windows-presentation-foundation-control-v1.aspx
the Bing Maps Windows Presentation Foundation Control v1 is best map control in WPF.
Support for tile layers – you can now overlay your own tile layers atop the map control.
Turning off the base tile layer – this is useful for when you don’t need/want to use our base map tiles and instead would prefer to use your own without overlaying them atop of ours.The control won’t request the tiles which reduces downloads and improves rendering performance.
SSL Support – since many of you are using the WPF control in secure applications, you can now make tile and service request over SSL without issue.
Hiding the scale bar – if you don’t want a scale bar (perhaps your map is small and the scale bar clutters the map) you can turn it off. In fact, the only elements you can’t turn off are the Bing logo and the copyrights.
New copyright service – provides accurate copyright for our data vendors. Additional inertia – inertia is now enabled for the mouse and is on by default for touch.
Miscellaneous bug fixes – thanks for the feedback on the MSDN Forums, the Bing Maps Blog, e-mail and Twitter. Good finds people.

Resources