As I get myself ready to move my Winform applications to XAML, I was wondering what are the must-have third party XAML controls that will save me developing time and will make my app look shiny with little work?
Thanks,
Nestor
XAML is markup language rather than a platform. In fact, you don't even have to use XAML to write WPF applications if you really don't want to. Since you're talking about converting from WinForms I believe that the question you're asking is more one of which third-party WPF control kits exist, so I'll answer on that assumption.
There are a few companies that have pretty extensive suites. As Shoban mentioned above, Telerik is one. You also have Infragistics, Actipro, Component One, to name just a few.
There are also quite a few specialty libraries to aid in Business Intelligence, Graphics Processing and more.
In other words, it's not possibility to make a good recommendation as to specific control libraries, but I can point you in a couple of directions.
WindowsClient.Net attempts to maintain a control gallery (not just for WPF, either). That's a good place to start. There are also software sales companies such as ComponentSource which can also set you in a direction or two.
I tried to link the other companies, but SO apparently thinks I'm too much of a noob to be trusted with high-security stuff such as multiple hyperlinks. :)
Check out Telerik. They have some nice controls.
Related
I'm writing my first WinRT app for Windows 8 in C#/XAML managed code and I obviously have to handle the UI in the different sizes and orientations that could occur (FullScreenLandscape, FullScreenPortrait, Filled and Snapped).
Most people seem to suggest handling the UI changes through the Visual State Manager in XAML, however me being more comfortable with writing the code-behind rather than XAML, I thought I would simply handle the Current_SizeChanged event with a switch statement for each of the states.
I tried both ways and both seem to work for me (though the VSM was decidedly more work - at least for me).
Can someone tell me why I should use the VSM over code, or what benefits I would receive?
It's a good question, and certainly one that entered my head when starting WPF & WinRT development. Having coded C# projects for years, it seemed a strange concept to start building UI logic in the Xaml (which is usually more lines than C#, but also more declarative).
In actual fact (if you don't mind me saying) I think we can abstract your question out to 'Is there any benefit to writing UI code in Xaml over C#/VB.net?'.
Let me give you an example, in work I'm on a project team with several developers, and several graphic designers. The designers are pretty awesome at laying out that Xaml, and creating a consistent feel for the application (something I can't say I would be that good at) - but will have little idea when it comes to writing web-services and Data Access layers - which is our job as developers. And that's how it should be right?
Well whenever you start writing a lot of View/UI related logic in C#.net, this can lead to all sorts of problems. The designers all of a sudden can't focus on the Xaml at hand, and must get up to speed with OO programming. In our project this isn't that much of a concern, as the designers are actually pretty competent developers (must have been all that UI code I forced them to understand last year :)) But what I think it boils down to is a 'Separation of Concerns' at a job description level. If we take the paradigms associated to WPF I think things like Databinding 'guides' developers down a road where they create separated, testable UI and Business layers - the same way that the nature of Xaml allows for a very declarative approach to writing UI where the View Logic is created and maintained in a very readable manner without getting too much into the nature of OO programming.
So, coming back to your question - No, I don't think there any immediate benefits, and if you come from a mainly .Net background to write a lot of these things is Xaml can be little tricky. However, if you are in a team of people - or if you find best-practices a very important factor in development, then writing View related code such as Visual State manager configuration in Xaml is the way to go.
One last point - you'll notice I used the terminology 'View related logic' a lot. This is because it's widly viewed that writing UI related code in code-behind is acceptable (if not best-practice) but sometimes due to the nature of the WPF or WinRT framework you are dragged down this route for some functionality. However, if you are writing business logic in the UI files codebehind this is viewed a particular no-no. This breaks the 'seperation of concerns' and can make testing very difficult. If you are following the MVVM pattern (as many WPF or WinRT projects do) then this is what the ViewModel is responsible for.
My team is currently working on windows forms project using VB.NET. We are curently focused on functionality and the UI seems to very basic (if you drag and drop from the toolbox to your windows forms)
Is there any recommendations or standards when it comes to UI for windows forms development? I want to ensure that the client gets a great UI.
I appreciate your support.
Yes, it's a simple standard: make sure that you follow the Windows User Experience Interaction Guidelines.
There's absolutely nothing wrong with "simple". In fact, in many cases, simple is good!
Your focus should be on making things easy, intuitive, and conform to user's expectations. Modeling your app after other applications, particularly those included with Windows, is a good way to make sure that you're on the right path.
Breaking new ground is dangerous territory; leave that to the big shops like Microsoft. Even new UI concepts that have panels of user interface/experience experts behind them like the Ribbon are slow to be accepted and even slower to be adopted. This isn't where a small software shop wants to be. There's no advantage in being out on the leading edge here.
The recommendations you'll inevitably get to use third-party controls are well-meaning, but ultimately misplaced. There's nothing wrong with the built-in controls and a lot of reasons to prefer them.
Once you've got a functional UI that conforms to the standard guidelines for your platform, the next step is real-world testing with actual human users who have never worked on any aspect of your application.
If they like it and they find it easy to use, then you know you're on the right path. I've never heard a user complain that something looks "too simple". Google Chrome is a huge hit precisely because it's simple. Remember that you're not designing a web page here. Desktop applications are very different.
In fact, it blows my mind how often questions like this one get asked here. Why do desktop app programmers spend so much time wishing that their app looked "cooler"? These are often the same developers who complained loudly because Visual Studio 2010 switched to WPF, broke a lot of their standard expectations, and got a lot slower, with little noticeable benefit. Sure, it looked cooler (unless you didn't like the color blue), but there was little in the way of functionality that the UI change alone was responsible for. Look at the apps you use every day. Do you really pine for a more whiz-bang UI? Or do you appreciate them and integrate them into your workflow because of how they work—because they conform to your hard-learned expectations of how a standard Windows application should work?
Make your app work like that.
Believe it or not, UI is very important to the end user. Its good you focus on functionality first, but when its done, make sure the user will have a good experience with your system. Make it as easier as you can, keep in mind that every user does not know everything about softwares, dont let him/her make a mistake, the look and feel must be very nice from the user's point of view, its not important to the system but it is to the user.
I use to use third party controls that manage the look and feel (DevExpress) you can try but if you are going to try some third party controls, you will have to do it at beginning of development, because the functionality may change.
I hope it can help you some.
Regards.
i'm assigned to research something about how to use “addons” on building a program.
Basically, I have one main program that checks for the available components (ocx, dll, etc). Depending on what components there are, it will dynamically create the menus and load the components.
is this possible using .net Framework 2.0 or later
I think you might be looking for the word "plugin" and it is definitely possible with .Net.
For example: http://www.codeproject.com/KB/dotnet/PluginManagerClassBrk.aspx
One thing you could check out is the Microsoft Enterprise Library "Composite UI Application Block." This framework is designed to help build GUIs by combining separate UI components by composing them together based on various conditions.
I'm not sure if I'm a huge fan - it's pretty complicated and seems clunky to work with, but if you work through some of the examples, it might be worth looking into.
http://msdn.microsoft.com/en-us/library/aa480450.aspx
Can you point me to good non-Windows looking GUIs choices for VB.NET? I'm needing free but with licenses that allow closed proprietary code. Thank you.
From your previous question:
I'll definitely want an attractive looking GUI. And nothing "Windows" looking.
Generally speaking, this is bad. Windows apps should look like windows apps. Otherwise hell will break loose:
alt text http://forum.computerbild.de/attachments/pc-hardware/realtek-hd-audio-manager-front-panel-problem-1470d1205060406-r.jpg
alt text http://www.techfuels.com/attachments/applications/1262d1207391664-gigabyte-easytune-5-pro-gigabyte-easytune-5-pro.jpg
Consider WPF to get a rich UI framework, though.
Well, for what it's worth, I'd advise against using custom-looking controls for the most part, since you're only confusing users (and thinking of several GUIs that use such a thing I can't really say they look more appealing and are easier or better to use).
If you can use .NET 3 or 3.5 you can use the Windows Presentation Foundation (WPF). By default it looks Windows-like but can very easily be styled to your needs (which is what WPF internally uses anyway for trying to look like Windows).
It has a very steep learning curve, however. But once you understood the basic concepts it's a very nice framework to work with and pretty easy to integrate custom looks for controls.
We are migrating our applications to VB.Net 2008 from Classic VB and I need to create a base namespace and business layer. My method of approach is going to be to visit our top BA and identify the common areas of our (Fixed Income) company and try to form a decent inheritence model with as much of the code in generics as possible.
What's everyone's experience of doing this and also as a second part of the question, we are looking at incorporating Web Focus into the OLAP side, how would this affect the design of the corporate namespace and it's derivatives?
I think the best way to begin to create a corporate .NET framework is to begin by harvesting existing code out of current corporate projects. Building a framework from scratch by talking to a BA without writing code for a specific, concrete project might lead you to over design the framework in some areas and totally miss some necessary features in others (as well, it might place artificial constraints on your framework clients for no good reason).
See Fowler's entry on Harvested Framework and this blog post for a more complete explanation.
I'm not familiar with Web Focus but I'm guessing it would affect it in some way, however, if you go with a Harvested Framework, your usage of it in the first few applications you build will shape how you use Web Focus within the framework.
Jereme has it right on the framework. I'll briefly mention something obvious about namespaces.
Always remember what a namespace is for - it's to provide a "space" in which names will live. In particular, it's meant to provide a space small enough that the people creating names within that space will be less likely to produce duplicate or confusing names.
This can only work if the namespaces are organized along patterns of organization, or of domain knowledge. A simple example often used is a pattern of Company.BusinessUnit.Application. The theory is that within the set of developers working on a given application, there is less chance for name duplication. This will not be true for a large application, where you would want to break it further based on layer or area. Similarly, of the business unit is too large, you'll want to break that down.
But in all cases, you're really trying to partition sets of brains, as it's the brains that create the names.
If your application is under VB6 (not VB3) then I strongly recommend that do the redesign to a class hierarchy in VB6 first. The reason for this is that in any conversion you try to preserve the behavior of the old application. Is stretches out the project time to do this and do a redesign at the same time.
By making the design changes in the applications original language first then you are assured that any bugs that result are due to the design not the conversion.
I done three major conversions of our software in the past 20 years; (DOS to VB3) (VB3 to object oriented design in VB6) and (VB6 to VB.NET).
Finally it is straight forward to make a design in VB6 that is ports over to VB.NET readily. The trick is to hide the specific VB6 APIs and constructs behind a interface (graphics, printing, etc)>
When do the conversion I recommend working from the top down. Change over your forms first to .NET which calls the VB6 COM DLLs. Then convert each layer over until you reach the bottom DLLs.
Again, if you try to change the design AND convert to another language for any complex application you will double the conversion time.