Can someone suggest a good UI framework for WinForms development? What I'm looking for is something that is fairly mature (=bug-free), renders well and quickly, and does not bloat my program with 10Mb assemblies.
Me and my team all use Telerik. The result is a stunningly good looking GUI, the controls are very mature and easy to use.
I've purchased the developer express report control and it does not scale well at all. It maxes out the CPU on our webservers when producing a report with 10k+ rows on it. So I can't recommend developer express.
I use developer express. IMHO cleaner more rational API than infragistics, fewer bugs with visual studio and help integration. I never look at the size of assemblies.. it's not a really useful metric for me in .net installs. Just to install hello world you are looking at massive downloads and long .net framework installs.
I’d suggest looking at DevExpress WinForms UI library which ships with over 190 high-performance and fully customizable UI controls and over 50 amazing application themes.
DevExpress is the only UI component vendor to offer WinForms DirectX rendering support. By moving to DirectX, their controls have achieved the highest possible performance and brilliant High DPI rendering quality.
You can try all DevExpress products for 30 days for free at https://www.devexpress.com/try
You can also consider Nevron Open Vision for .NET (https://www.nevron.com/products-open-vision.aspx).
It contains 70+ UI components, plus advanced Chart, Grid, Diagram, Rich Text Editor, Gauge and Schedule components. All components can be integrated into any WinForms, WPF, Xamarin.Mac and Blazor - WebAssembly project.
The solution features hardware acceleration on most platforms (renders really fast), and is very lightweight.
Related
I'm evaluating Silverlight for a RIA right now. A large amount of the Gui is to be designed by people without programming skills. Visually the application should be very appealing, animations, smooth transitions and so on are a big plus for us. Blend and Silverlight seem to be tailored very well to fit this requirement. However it does need the runtime which is somewhat acceptable for us but also a little disadvantage.
So, do you know an mature Ria-like alternatives (similar ease of development, all-in-one-happy-package without runtime) outside of this ecosystem? I had a look at Qt and the designer but I'm not sure what to make of it in the moment with all the buzz about it and if it is fitting to our needs.
Are there other alternatives you can recommend?
Thanks in advance.
If you're familiar with .NET technologies and looking at Silverlight from that perspective, its may be the way to go in that you will be using the same tools. Silverlight is also cross-platform on desktops.
Adobe Air as far as I can tell can be many things, one or more combininations of flash, flex, javascript, html. This is also cross platform in terms of desktop machines.
Html/jQuery/Javascript is another option, this also enables usage on mobile devices.
There are 3rd party plugins/add-ons and components for most of these technologies that help with both features and the visual aspect of the interface.
There is Adobe AIR, but I'm not familiar with it.
Just so I understand, here is what I hear you saying: you want designers to design the UI and developers to develop the code.
Your problem is that developing for Silverlight requires the Silverlight runtime? I'm not sure I get this, but here are some thoughts:
1) If your designers are running Windows you can install just Expression Studio and Blend should include all you need for them to do their work in Blend.
2) If your designers are NOT running Windows, they can't use Blend. They can still do their design work in Adobe Illustrator and Photoshop because those assets can then be imported into Blend. Of course, whoever does the import will need a Windows machine with at least Blend installed: in that sort of scenario we call that person an "integrator", and there are folks out there who specialize in that sort of work.
3) If your developers are going to create Silverlight applications, they will need Windows and .NET developers tools (preferably Visual Studio). To paraphrase what AnthonyWJones said earlier: how can you develop for a platform without having the platform?
In my mind, having Visual Studio and Blend is the "all-in-one happy package", but that's just me. :)
I am a 6-years .Net Developer, and want to know which is better to start learning first, Silverlight or WPF.
I know this question seems a little-bit argumentative but since Silverlight is a mini-version of WPF. I think this takes away the argumentation.
So in the light of that, if I considered start learning:
Silverlight First: Because it would be easier to learn than its big brother.
WPF First: Because it would be easier to know the basic concepts and event-model of WPF before moving to SL.
Learn Silverlight first so you won't be annoyed that you cannot use useful things like RelativeSource and x:Static in Silverlight :P
Silverlight will be fused with WPF in a couple of years.
Study Silverlight first, i recommend the book Pro Silverlight 4 in C# from Apress, the unique that have color pages.
If in future you'll need some extra Windows functions, go to the much complete WPF.
With Silverlight you can also develop Windows phone 7 applications, and Xbox 360 (rumored). In windows 8 will be a Silverlight Marketplace (valid rumor), and you can create very rich applications / part of website / full websites instead of using the slow, crappy and "browser inconstistent" JQuery+Canvas that have no tools at all for design (and when it will have, Silvelight 5 will have real 3D and better tools).
Also the fact to use the same language for client and server is priceless.
Well Silverlight and WPF is "pretty much" the same actually. As you said Silverlight has only a subset of the .NET framework but it doesn't make it "simpler" than WPF.
The biggest leap you will have to make in order to learn those languages is learning XAML, which is the same in both.
It all depends on what you need to do. Do you want to publish your project to the web, then go with silverlight (you can do a XBAP project in WPF to publish it to the web, but clients will need Full .NET Framework). If you need advanced .NET functionnality, then use WPF.
Silverlight first. It is easier to add the extra WPF features than to unlearn things when doing WPF first.
Having said that, it doesn't matter that much. There is more on Silverlight on the web these days.
What kind of applications do you want to write ? Desktop applications that need local access or web based applications ?
If it is a matter of learning, I would learn both in parallel. Keeping your application consistent to run in both run times will force you to learn all of the little differences. Once you get past the main SilverLight features, shift into the features only provided by WPF (though I would start with the libraries likely to be included with SL5, first, such as 3D).
Go with Silverlight first, although it is not as feature rich as WPF it is simpler. Also Microsoft are actively evolving the platform. Silverlight is not a true subset of WPF as it had things like a DataGrid control first.
Good learning resource: http://www.silverlight.net/learn/ together with the Pro Silverlight book which you already have.
The further advantage of starting with Silverlight is that it will be easier to develop for the new Windows phone (broadly it uses an older version of Silverlight).
Learn both at the same time! Not one or the other, but both. There's plenty of overlap between the two technologies which should make it more practical to focus on both at once.
Recently I've stumbled over surface. It's incredible and so easy to develop small applications with surface. Surface is build upon WPF, so surface uses XAML. My idea is now to develop applications with surface. I've searched for some information about this topic. There is nothing about that. My question is now, why nobody uses the surface SDK with WPF to build cool applications. Are there any disadvantages?
I don't really understand your question. But here are some answers to what you may be asking:
Why aren't there more surface applications out there?
Most likely because of the price and the availability. It costs $15,000 for a developer unit and you have to be a business to even get to order it.
Why isn't the surface SDK used to build normal desktop apps
Because it doesn't make sense. The surface SDK contains Surface specific, and multi touch specific additions to the plain WPF stack so it is only useful for surface applications running on a real surface device (or simulator, but that isn't feasible for deployment)
Now if you are building a multi touch application for windows 7, there is a surface toolkit which is based upon the surface SDK. It has most of the nice multi touch enhancements but lacks the hard dependency on the surface hardware. It is very useful for general purpose multi touch development on .NET and is as far as I can tell also used quite much for this purpose.
Do you mean building Windows applications in WPF using the Surface toolkit? There is no reason not to do this. There is a 'good, better, best' model when developing multitouch apps, and if you want to create a true multitouch friendly application, then the Surface toolkit is a good way to go.
I have created an application using the surface toolkit but for normal wpf application.
You have just to have a multitouc tactil monitor.
and every thing will be fine.
It works :)
I am at the initial stage of designing a client application. However, being new to WPF and having already gained some experience in Win forms development, time pressures on the project means that there is a risk to going down the WPF route. If time were no pressure, then I would say forget forms and design with WPF. However, I am not lucky enough to have this luxury. Having spent a little time investigating the Composite Application Block for Forms, I have decided that I will definitely develop the application within this framework. However, there are 2 versions of the CAB, 1 for WinForms that targets the .Net 2.0 runtime which has now been retired, and then the WPF version which targets .Net 3.5. Not being a fan of 'retired' code libraries, I would prefer to use the WPF version of CAB. This may be a silly question, but is it possible to use the WPF version of CAB for Win forms application developement? I do envisage at some point in the future moving to towards WPF. If I could use the WPF version of CAB I am hoping that this would make it easier to migrate the forms application to WPF.
It looks like somebody had the same idea that you did.
I found it by reading this thread on the CompositeWPF codeplex forum, discussing this very issue.
You should be able to do this without too many issues. We are currently using CAB to enable us to display SQL Reporting Services reports in WPF (along with a couple other items). It's a pretty simple implementation, but our architecture is WPF-based, not WinForms. As far as we've been able to tell, there wouldn't be much of a problem were it the other way around, and displaying both types of forms is done the same way.
Silverlight 3.0 beta has just been announced at Microsofts Mix Conference in Las Vegas.
Two features of the new beta are 3D-graphics and the ability to run applications outside of the browser, which to me seemed to be two of the major features that WPF (Windows Presentation Foundation) previously offered over silverlight.
I am currently evaluating WPF and Silverlight for possible use in our companies future development activity, and this announcement has left me confused as to the intended direction of these two UI technologies and why I would choose one over the other.
Has anyone implemented a new application using WPF recently, and if so, what drove you to that decision? Given the announced changes to silverlight, Would your decision have changed had you made it now, and if not, why?
Any advice would be appreciated.
The biggest difference I find is the asynchronous model you have to adopt
in your Silverlight application.
It does seems like an advantage (and it can be), but it does make
life very difficult sometimes.
There are also some limitations that can be a real challenge like the absence
of print support.
I would recommend Silverlight over WPF when:
- There is no need for best possible performance (graphics included)
- Can get around the absence of print support (it will come, we just don't know when)
- Camera/Microphone support is not needed
- Can tolerate the assync app/development model
- Can tolerate limitations on WCF (no support for WS-Security at this point)
- There is no need to store huge amount of data on the client.
- There is no need to direct integration with client side applications like Office.
- Has a server to host your application
I would say the main difference is that WPF requires the client to have the .Net 3.0+ framework. Silverlight only requires the runtime. Now that being said, WPF is geared more for controlled environments such as an intranet. Silverlight is meant for the public web. Another difference is that Silverlight is cross platform (Windows, Mac, Linux in the future & Cross browser). WPF is meant for Windows only.
The .Net framework can be a huge download for some users. Silverlight is only 4-5MBs. This is a big difference to run your app on the web, but not a big issue if its an internal application at your company.
Silverlight is Sandboxed which is meant for web use. So if your app requires more permissions you will need WPF.
There are also some differences between Silverlight code and WPF. But from what I've heard, the ultimate goal is to get a Silverlight to run inside of WPF with minimal code changes. But they aren't there just yet.
I have just worked on a WPF project that in hindsight we feel we might have chosen SilverLight for. It is probably more important to know the differences and select the one that is most appropriate for what you're doing.
Here's my starter for ten on some of the important differences - there were originally some differences in the available controls, but that has largely been smoothed out now.
Silverlight
Runs entirely on the client with AJAX
calls to the server for data
Can run on any server, including Windows and Linux / Apache
Uses COMPACT .NET framework
WPF
Runs on the client... usually calls services for data
Runs on Windows XP / Vista with .NET 3.5
Utilises the entire .NET framework
Silverlight is basically a stripped down version of WPF in order to make the runtime libary download as small as possible.
As a result, WPF simply has a lot more functionality available in it and tasks that are simple in WPF often become not so simple in Silverlight.
If running as a web app is not a requirement then the decision is a no-brainer - WPF all the way.
Has anyone implemented a new application using WPF recently, and if so, what drove you to that decision: Well since WPF was desktop only (or browser based using XBAPS - but that was more a deployment system than a real system) that was a good reason to it.
"Would your decision have changed had you made it now, and if not, why?" - No Silverlight, even on the desktop in v3, is still highly sandboxed and so certain functions are going to be hard/impossible to do due to the sandbox. Also the ability to use DirectX parts in WPF will still give another optimisation area which Silverlight and it's 3d won't be able to use.
It's worth noting that Silverlight's 3D is not the full 3D support of WPF, but only projection of 2D into 3D - i.e. take the 2D plane and allow rotation in X, Y & Z directions. WPF has full 3D modelling with materials, view ports, lighting and camera positional support etc.
I'm well along in the development of our first WPF app for release. Silverlight 3 looks great, but for this application I would still have chosen WPF. The application centers around presenting and manipulating very large sets of images hosted on a central server on our clients' networks. Additionally, the software update/change rate will be minimal. Mass import of new images from a local drive, no Internet connectivity requirements, performance concerns, etc. make this a project well suited for WPF.
One of our upcoming projects, however, will require many remote users to access a single data store on our network. The data they work with requires significant validation and error handling, so running that code locally is ideal. They will need the ability to work both on and offline and remain in synch (probably with SQL Data Services). SLOOB (Silverlight Out Of the Browser) will most likely be our choice for that one so they can have all the Silverlight advantages but use it like a regularly installed application, even without an Internet connection.
Both formats have their place: the trick will be to avoid using Silverlight for everything - we have more tools than just 1 hammer. :-)
Another difference is that with SL you only have one 'window', you can't have dialogs (they can be simulated but their size is limited to the main window) and you can't add multi monitor support.
If you have to interact with existing business applications (e.g. open a document in the archive viewer) you need to use WPF.
I recently have built several internal tool using wpf, and I chose it simply because It was easier for me coming from win32 work. I don't really think that the differences are major, and really... everything i have seen/heard indicates that porting between wpf and silverlight is quite easy.
Storage: You only have 25MB of isolated storage out-of-browser. If I remember correctly from some mix09 video, this limit is lower if your app is in-browser.
http://bliny.net/blog/post/Out-of-Browser-with-Silverlight-3.aspx
No FlowDocument: So there are limitations there too.