WPF four, especially insufficient to replace WinForm

WPF four, especially insufficient to replace WinForm

WPF has been in the mountain for four years, as the official default of the next generation of UI system, no less. But the ability of this new head is still the heart of many developers. With WPF rewriting of the editor part of VisualStudio 2010, Microsoft finally gave a confirmation of the competency, and of course, made a number of important improvements to WPF, especially when it finally solved the problem of unclear text. So, at least starting with. NET 4, WPF should be more secure for important development projects.

However, using WPF is not as smooth as WinForm.

First of all, it's too complicated, and the entry threshold is high. This complexity stems partly from its ambition to unify desktop and web development. While supporting both the desktop and the web with a set of frameworks is good, it also inherits the complexity of both. If both the WinForm and the ASP. NET development experience, it will feel that the merger is natural and promising. Of course, WPF has a higher goal, which is to challenge Flash. The spirit of a three is commendable, and you can imagine how powerful it would be to defeat the three-faction martial arts masters of different styles. But for those of us who are learning and using WPF, how many people are going to be targeting two or even three areas at a time? We have to face the full complexity of WPF, even if we just have to face one of those areas. Of course, there are also potential benefits that can easily be introduced in two other areas of technology.

Second, for WinForm developers, getting started with WPF can be more difficult, because the most basic thing-the XAML that makes the interface-is completely web-style and thinking. The original WinForm of knowledge and skills, most of them no longer apply. The choice to face at the outset is document, Window, Page, NavigationWindow, and so on, rather than a simple form. After you create a window, if you expect to design a form like WinForm, you'll find that its window designer is basically a joke, or honestly handwritten XAML, and you'll be glad you've learned some HTML. If you can't stand handwriting xaml, you can download expression Blend, similar to the Flash editor, and you'll be glad that you've done a bit of artwork and flash.

After that, you will find that add a tool button can not directly specify the icon and text, but also must nest a layer of stackpanel;disable when the icon will not be dimmed, you need to write a style to achieve; toolbar end of the overflow The popup button always shows that it is annoying to hide it on the ControlTemplate, and DropDownButton not, to realize it yourself ... A lot of WinForm things, all of a sudden there is no. Although it can be achieved through a powerful style system and composition, it takes extra effort.

Resource is easier to add and manage than before, just add files to project, organize your directory structure, and set the file's build action to resource. But the path to referencing the resource file is bad, and I don't know which spirit is different from the average guy who invented the rules for this pack URI (like pack://application:,,,/referencedassembly;v1.0.0.1;component/ MYRESOURCEPATH/RESOURCEFILE.XAML), I want to hit the sandbags as soon as I see them. Fortunately, in most cases, only the relative path can be omitted, and the previous string of things that are not in the flat.

Data binding is one of the biggest changes in programming mode, and the data interaction with the UI is almost all done by binding, the simple case is very simple, very powerful, much stronger than the data binding in WinForm. But the complicated situation makes people scratching their heads. A little more complicated, you have to write a viewmodel layer, that is, to write an interaction class between the UI and the business logic, and the UI binds to the properties of the class. The next consideration is the formatting of the data display, such as how to display a floating-point number as a percentage output, combining multiple attributes into one output problem, as well as the user input of the legality of the check problem, limit the problem of the input characters, want to accept processing input when pressing ENTER ... These are not straightforward when there is a problem with ready-made support, you need to write some code to solve.

In addition to this, the WPF language localization tool supports a basic equivalent of 0, with only a complex and difficult command-line tool, or a sample compilation of the SDK. To do localization translation, you can only rely on third-party tools.

More interestingly, the WPF program uses the en-US culture by default, regardless of the culture of the current system, and you need to write your own code to set the Language property of the window or control when the program starts. or override the default value in the metadata of its frameelement.languageproperty. Of course, this is not a bug, but by design. The reason comes from the earliest. NET is a design error.

Originally designed in the year. NET, they plan to support globalization and localization support from the Base library section in order to adapt it to the increasingly globalized market in the future, so all string formatting functions are using the current system culture by default. But at this point in all other development languages, the default is en-US standard. As a result, a large number of programs do not consider this difference, the result is a performance loss, considering the cost of localized string processing is much slower than the simple binary string processing, and second, resulting in a large number of different language systems will appear on the bug. For example, in the German system to generate a floating-point "1.23" text, Out is "1,23", sent to the English system read, parsing error. For example, different languages of the case of the corresponding is different, the conversion of the case in different languages of the system may have different results, in the file name, path processing will lead to unexpected bugs. When you develop. NET 2.0. NET developers have been aware of this error, but can not change the existing API, so can only add to these functions with new parameters of the overload, and recommend that you do not use the old API, but to write a very long function, such as String. Equals (String another, StringComparison ComparisonType), with string. Format () is also best used with the overload of the specified culture to take full advantage of CultureInfo.InvariantCulture. The designers of WPF have learned this lesson well, so the default is always en-us, where localization is required to display the designation.

In addition, Ilmerge is not able to properly merge WPF's assembly, because it does not correct the reference string for resources in BAML. It also means that Ilmerge-based obfuscator also has this problem. For Obfuscator, however, it is not easy to support WPF itself. Because WPF relies on data binding, the data binding uses a lot of moniker strings for object properties, and after compilation The XAML is compiled into binary BAML, and the BAML format is non-public. This will not change the referenced object property name.

In short, WPF has a lot to go, the future is bright, the road is tortuous. The future is WPF, and WinForm, but in the final analysis is Korean people?

http://blog.csdn.net/nightmare/article/details/5572556

WPF four, especially insufficient to replace WinForm