I am starting a WPF project, which will be fairly complicated in complexity and will make use of a lot of modern UIs, like outlook bar, grids, tabs, etc... I've looked around in the marketplace and there aren't too many control suites. Some of the available ones are either Beta or CTP. Others don't look too polished. Yet others are pretty nice looking.
At this point, today, should I buy or, bite the bullet and build my own? What are the experiences people are having with 1st generation control suites?
The thing to remember is that WPF is very different from WinForms, you can do amazing things buy just re-skining existing controls, when you are starting your first WPF big project you don't yet understand WPF and you don't know the possibilities and pitfalls of the system.
I suggest you start developing the project without those controls and add them later, that way when you get around to adding those controls you will have a better feel of what controls you need and what controls are a trivial customization of an existing control.
If you need anything that isn't trivial it's better to buy - but only if the component you buy is good, so evaluate carefully.
and read Joel's "In Defense of Not-Invented-Here Syndrome" at http://www.joelonsoftware.com/articles/fog0000000007.html
One of the best things about WPF (and XAML in general) is that it makes customizing the available controls a whole lot easier than it was back in WinForms days. Everything depends on the level of customization that you need. If you just have to tweak the look-and-feel of the standard controls, you can do that using a tool like Expression Blend and you don't need any third-party stuff. If you have a good designer on your team (or if you are one yourself), that shouldn't be a problem. And if what you need is some advanced functionality that isn't provided by the standard controls out-of-the box, I'd still recommend trying to customize the standard controls. It's really amazing to what extent you can change the appearance and behavior of a control in WPF by tweaking things like the ControlTemplate, DataTemplate, etc., and/or by subclassing. Besides - now that is just a personal opinion - depending on third-party custom controls generally sucks...
In general, I program in C# so that I don't have to 'reinvent the wheel' every day. I'd recommend using of the shelf components whenever the features provided justify the price there asking for.
That being said… be careful, WPF has not been around long enough for the components to have matured yet.
One of the questions I'm always asking myself is, "what are we in the business of making?". I ask this especially when I'm about to do something that's time-consuming vs buying a 3rd party solution.
Are you in the business of making 3rd party controls? Or does it make more financial sense to buy a package and save your precious time for other stuff?
I would say to take a look on what it is already in there. In my point of view I am pretty much covered with the available ones, and especially in .NET 4, where the DataGridView, Calendar, and DateTimePicker are included (finally).
But if you want also take a look in the components from a company named Infragistics. They are very powerful, but the documentation of them really sucks!
Related
I'm looking for best practices for sophisticated UI logic implementation. I'm working on a Windows Forms application, but I believe there should be generic patterns for solving this problem on any platform.
I have a number of controls on my form, there are lists, buttons, tables and a tree view. So, the idea is that depending on "context" some of the controls are enabled, while others are disabled. Some of them can provide some features for the moment and others don't.
Currently it's implemented "as is". I handle events, check for changes (new tree node selected, couple of nodes selected, etc.) and then decide whether some of the controls need to be disabled or enabled. I don't really like this approach because the Form code looks to complicated. And if I need to add more logic, it becomes even more complicated. I'm really concerned, since we're quite agile and new features or lots of changes are the daily norm.
I'm thining of separating all this logic into parts (Features), where each feature is an object that know how to check its state, and depending on this state, enable or disable the related controls.
Don't really want to invent anything new and trying to find any good ideas that are widely used. Please, don't recommend single UpdateUI() method approach, I believe that won't change anything in the long term.
Thanks.
This blog series may be what you are looking for:
http://codebetter.com/jeremymiller/2007/07/26/the-build-your-own-cab-series-table-of-contents/
(may look like a lot of material, but start just with the "Humble Dialog box", based on Michael Feathers great article). This is all about "how to separate your logic from your UI code", which may solve most of your problems.
User interface data binding and encapsulating your business logic into business objects is the way to go. CSLA.NET framework by Rocky Lhotka has a lot of great features built-in as well as a number of sample applications. I've used it in a medium-size WPF project and a huge WinForms/CAB application and really enjoyed it.
i am a junior c# programmer and would like to learn silverlight.
is silverlight for progrmmers or for designers?
It is for neither - Silverlight is simply the branding for the runtime engine, library set, etc. The only thing that "uses" Silverlight directly is (broadly speaking) the browser.
The important thing for developers is Visual Studio (regular or Express:Web), and for designers: the Expression suite. Both can contribute to a Silverlight project. Also consider that you may be targeting Moonlight, so even "Silverlight" becomes misleading.
Silverlight is for both developers/programmers and designers.
The User Interface of a Silverlight application is defined in XAML script, which is based upon XML.
Microsoft explicitly target the Microsoft Expression (specifically Expression Blend) suite of products at designers, whilst Microsoft's Visual Studio is aimed at developers (although Visual Studio 2010 can be used for design work as well).
If you have a designer and a programmer working together to create the overall Silverlight application, you can utilise a programming design pattern called MVVM (Model-View-ViewModel) to help separate the concerns between the UI and the back-end functional program code. This effectively allow the programmer to not really care about the names and ID values of specific UI elements that may have been defined by the designer, but simply to "bind" together specific User Interface elements with their "back-end" program code counterparts to create the complete Silverlight application.
It is for both.
Both,
As a programmer it's good to be familiar with the programming model, the related MVVM pattern, the object model etc.
As a designer you can build your designs in Blend and XAML. Then integrate them with the rest of the software
Both.
Usually a developer will do it all, but using the Expression products, designers and developers can work on the same project to utilise their skills.
I guess like most peep said, it is for both.
Being a developer myself, I tend to sway towards the coding.
But when I want to do animation, I will go back to xaml, which is way more simpler than doing in the code behind.
One good thing about silverlight that certainly prove that it is suitable for both is that, no matter how a designer place his UI and animations, and no matter how a developer codes, as long as 1 focus on functionality, another focus on UI.
Things will work out perfect, unless the designer deleted some UI that is suppose to have functionality. :)
It's for both.
However you're also going to need both developer and designer to make it quite good.
I'm about to start developing a small Windows application using Microsoft Visual C# 2008 (Express edition). I'm very new to C# and .NET, so this is a newbie question. Should I start with WPF or should I stick with the old WinForms?
My application has several screens, all having several text-boxes, check-boxes, combo-boxes, not anything more. The application will retrieve data from several COM objects, and communicate through standard TCP/IP sockets, both of which are unrelated to the UI.
The UI is not fancy in any way (and I don't need it to be). However, the world seems to be moving to WPF. What are the considerations of choosing WPF over WinForms for my case? What's the recommended approach?
Thanks
I have not used Forms enough to say anything about which is better, but I have found WPF to be easy enough to use for minor applications.
I figure that if it's the standard people are moving towards and it's not difficult, then it's good practice to start using it.
WPF = Future + Fancy stuff
WinForms = WYSIWYG greatness
Choose whichever of the above you find the most atractive :)
It depends. Stick with WinForms if you're comfortable with it.
If you want to be able to have a better look-and-feel with more customized controls, and you're willing to spend the time to learn XAML and the differences between WPF and WinForms, then go for it. But expect it to take some time, there is a learning curve.
Interesting, how all answers target the developer: familiarity with a framework, the learning curve, the technical features of a framework etc.
If it's a simple application, none of the technical aspects really matter. You sound like you have some experience programming, in that case the chosen framework doesnt really matter. Focus on your users instead.
Can you guarantee that your users have the latest .net runtime installed? Are they willing/able to install it if they dont?
Will your users be put off by an "outdated" look and feel?
The way you phrased your question, i think you should use WinForms. You seem to imply ("stick with winforms") that you have experience in WinForms and that you dont have any fancy demands for the UI, so i see no reason to put yourself on a steep learning curve that WPF can be.
I personally like alot of the things that WPF provides. It has easy data binding, validation, and customizing UI things is simple. Plus with the new Expression Blend 3.0 that was released yesterday they have sketchflow WPF apps that you can share with others and get feedback files from. It is a pretty interesting little addition to the WPF world.
The nice thing is that if you find a Winform control or something that needs to be WPF and you picked the other way, they seem to work well with each other now.
It's a trade-off.
You will most likely be more productive starting off in Windows Forms because the programming paradigm is closer to most other UI development libraries you might be familiar with. There are also many libraries of UI control available for WinForms (including ActiveX) that make creation of attractive, functional UI easier. Unfortunately, MS has indicated that WinForms will not see any more advancement in the future because their emphasis is on WPF.
WPF, on the other hand, is more more sophisticated and robust and can help you create very attractive, rich interfaces. WPF sometimes requires the use of more sophisticated back-end programming paradigms like MVVM to create effective applications. Also, as a newer technology, there are fewer mature libraries and tools to help you develop WPF apps. For development tools you have VS2008 and Expression Blend (which is quite nice BTW). Advanced graphics features like gradients, color themes, skinning, control customization are all more powerful in WPF. But this power comes at a price - most developers find WPF to have a more significant learning curve that WinForms.
WPF is something completely new if you are used to WinForms, so it'll take quite a while to get used to it. But i prefer WPF not because of the looks, for me it's more the great layout system (once you got used to it), its databinding infrastructure and in combination with patterns like MVVM, the separation of UI and business logic.
.Net is a huge framework with some functionality that appears to target beginners or becomes problematic if much customization is involved. So what functionality available in the .Net framework do you feel professional developers should avoid and why?
For example, .Net has a wizard for common user management functions. Is using this functionality considered appropriate for professional use or a beginner only?
One component/feature/class, etc per answer please so votes are specific to a single item.
Typed DataSets
ASP.NET *View Controls
ASP.NET *DataSource Controls
MS Ajax
jquery, and other js frameworks like prototype etc., are a more lightweight and flexible alternative. The MS Ajax controls may seem great initially, until you really need a custom behaviour out of the scope of the controls.
Microsoft themselves have recognised this to some extent in that jquery will be bundled with upcoming versions of visual studio, with intellisense support.
I think generally most controls/features that do a lot of work "behind the scenes" can cause a lot of trouble. No problem using a GridView if that layout is exactly what you want - but it very rarely is, and a Repeater is probably a better choice. UpdatePanels can save you lots of work if you want an ajaxy feel to your site, but compared with a jQuery AJAX call they - sorry to say so - suck. The user wizard you mention can be really useful during development, but if membership functionality is required in the project it should be built as an integrated part of it.
So in summary: Professional programmers should do the job themselves and write code that specifically satisfies their clients needs, and only take in ready made parts of the .Net Framework when that is in fact exactly what they need.
Thread.Abort
Here is an excellent article by Ian Griffiths about Why Thread.Abort is Evil and some better alternatives.
Remoting is generally a good one to avoid, at least if you're targeting 3.0 or above and can therefore easily host messaging endpoints in-process.
Linq To XML
XmlDocument/Xpath is easier to use, if you want strong typing to parse your document use xsd.exe or Xsd2Code.
EDIT
which one do you prefer ?
IEnumerable<XElement> partNos =
from item in purchaseOrder.Descendants("Item")
where (int) item.Element("Quantity") *
(decimal) item.Element("USPrice") > 100
orderby (string)item.Element("PartNumber")
select item;
or, with XmlDocument and XPath
var nodes = myDocument.SelectNodes("//Item[USPrice * Quantity > 100]");
.Net is a huge framework with some functionality that appears to target beginners or becomes problematic if much customization is involved.
It's the "appears to target beginners" that's the real problem.
Typed data sets are a great example. VS provides a nice simple UI to functionality that should be used only by rank beginners building extremely simple demo applications and experienced professionals who understand every nuance of the ADO.NET object model and what typed data sets are actually doing. Nobody in between those two poles should touch it, because there's a good way to learn every nuance of the ADO.NET object model and typed data sets aren't it.
Or take LINQ. It's seductively easy to write LINQ code without having a good understanding of IEnumerable<T>. But it's not so easy to write maintainable LINQ code without that knowledge.
You can think of .NET like an onion with many layers. For example the .NET compact framework is a subset of full .NET. Further there are "extra" layers on top on .NET in the form of "Extensions" which are optional installs for new features which have not yet been made part of .NET proper. An example of this would be when Microsoft released ASP.NET 3.5 Extensions which has now been rolled into .NET 3.51.
Another way to think of .NET is as a set of "libraries" you can use. For example there are a set or routines to support RegEx. If you want or need regular expressions, then you use these functions, if not you can simply ignore them. SImilary functions for things like trigonometry or security.
So I guess it really boils down to what do you need for your application? If you are doing scientific programming you may well want the trig functions. A graphical app will require functions that a console application would not. Web apps probably do not need to use the clipboard functions etc.
I really don't think there are any bad APIs in .NET, just programmers who use them in inappropriate ways.
There is lots to avoid in the WinForms library.
Avoid DataBinding to most standard WinForms controls. There are many bugs in that area which will lead to lots of head scratching. Or at least that has been my experience. NumericUpDown is a good example of this buggy mess.
Also avoid the standard WinForms controls when dealing with large datasets. They do a lot of data copying and can't deal well with large datasets.
Avoid ListView in "Virtual" mode as it is full of bugs.
In general I just recommend staying away from WinForms. If you have the option go for WPF or at least buy a good, well supported (and hopefully less buggy) 3rd party forms library.
I am a long time MFC programmer and know it quite well. Recently we are planning for a large desktop application. In order to beat competition, one requirement is polished UI. We narrow down the choices to three:
WinForms
MFC
QT4
We looked at some big WinForms applications, such as Paint.Net, and feel that it still lacks power of performance. The startup takes a while and some UI parts do not look very nice.
We had great hopes in QT4, but after writing several programs on it, we find that the looks of a QT4 application is not at par with native Windows UI. It still looks differently. Also we worry about about lack of widgets (for example, the color picker and calendar control in the library quite suck).
MFC is a safe bet, especially with components from Codejock.com. The UI interface looks quite polished with codeJock toolkit. And all widgets needed are there. The problem is that its coding style is quite outdated.
What will you choose for your next desktop application?
WinForms is effectively at the end of its life now. You should look at WPF.
See WPF: Any cool UI ideas i can look at? for links to some nice examples.
WinForms is really easy to get into if you know MFC (it's still based on the core Win32 concepts, so you don't need to learn much to get up to speed). Compared to MFC, you can develop much faster, and there is so much more library support for everything in .net that you have to write for yourself or find 3rd party libraries for in MFC. Often I find the .net solution to a big problem is around 3-10 lines of code, whereas the equivalent MFC solution would be hundreds or thousands of lines. I wouldn't even consider MFC a starter now that I've used WinForms in C#.
We're building some very large C# applications and the performance is perfectly fine. If any small part of the program is really performance-critical, it's really easy to plug in a bit of unmanaged C++. I found startup times abysmal in XP in the early days, but with more recent .nets and Vista, startup time is comparable to MFC apps.
So I'd go for WinForms/.net at a minimum.
WPF is also a sensible future-facing approach to consider.
WPF is a good option if you've got design skills or can ask for someone to prettify your UI. I think it's definitely one of the most versatile options.
You could also use components like DevExpress or Telerik, both have an extensive library of WinForms controls and as of recently WPF controls. I've used DevExpress myself and am rather pleased with the looks. Although these library don't come cheap, but they do carry quite a lot of functionality.
I've never worked with QT4 so can't judge that.
For my next desktop app I would use:
on Windows:
Probably the old fashioned Windows API (without MFC) because I am familiar with it.
Maybe Qt, because I'd like to try it out.
on MacOSX: Cocoa
on Linux: Qt
Not that I am very fond of MFC, but if you are comfortable with it, go ahead. It is not going away any time soon, although it surely won't be updated and improved as much as WPF.
Having spent 12+ years developing MFC applications, and now using WPF for less than a year, there is no way I would go back to MFC. At previous employers, we would spend countless hours customizing UI behavior and getting the right graphical look that would take a fraction of the time in WPF. Not to mention the added flexibility of being able to work with the UI as XAML (XML,) as opposed to the rather outdated resource editor.
If your application has to be C++ (as opposed to C#,) then I assume that using WPF would be a little more non-trivial. I haven't done .NET inside of C++, but I remember the overviews presenting it as a fair amount of extra work.
We at my work are currently revamping a GUI app from VB6 to make it look "prettier". We've chosen the .NET winforms platform for our upgrade since most of our coders are familiar with it. .NET has a few libraries dedicated to graphics, and there is a wide range of nice-looking user controls already built into the library. Asside from those, there are many, MANY custom-made controls out there such as the ComponentONE library, and there are a lot of opensource controls for enterprise use that look nice as well (you can search CodeProject.com's articles section for some free, downloadable controls that look very vista/windows 7-esk).
The framework also natively doublebuffers windows, and has bufferedGraphics classes that you can use to manually handle doublebuffering if you so choose.
However, windows forms do still ghost when dealing with high res images as background pictures and the only way to really fix it seems to be to use the DirectX libraries to draw using the graphics hardware on the machine (which is difficult, but atleast its free).
Hopefully that helps your decision on the platform form the windows-forms side.
I would still consider MFC. It's far from dead and especially with the new 2008 feature pack. You get a host of updates and can now create those fancy ribbon UI elements. If you already know MFC then you know the pitfalls (old but some are still there) and can knock out the work quite quickly.
There a ton of UI components you can buy for MFC and it has the benefit of being fairly close to the metal as far as speed goes. There is no need for your end users to install a framework or anything else.
I write C# for my day job, but all my personal projects are MFC/C++ since they don't require my users to have additional frameworks,libraries,etc installed.