Last November we introduced the Silverlight Toolkit, an open source project designed to provide additional Silverlight controls and functionality between versions of Silverlight. Since then, we have received significant positive feedback and have already released a 2nd revision in December.
The December release contains even more themes, a new sample app, fine-tuned components, and a bunch of features and fixes requested from the development community. We’re also shipping designer DLLs to integrate the experience some, plus unit tests and the latest release of the unit test framework.
For those of you familiar with Windows Presentation Foundation, you’ll recognize the names of some of controls available in the toolkit. The controls in the "Stable" quality band are AutoCompleteBox, DockPanel, HeaderedContentControl, HeaderedItemsControl, Label, NumericUpDown, TreeView and WrapPanel. Controls in the "Preview" quality band include Charting, Expander, ImplicitStyleManager and Viewbox.
Using the controls is a matter of adding references to the assemblies in the toolkit and using them as regular controls in your Silverlight application. Below, you’ll find a few examples.
NumericUpDown
NumericUpDown is a TextBox that only allows numeric values while also providing the ability to nudge values up or down using either the mouse or keyboard. Setting various properties allow you to control Minimum, Maximum, Value and by how much to Increment. In the following Xaml, you can see how easy it is to use the NumericUpDown control.
And, the result would look as follows:
This is a great control to use when you want to constrain user input to numeric only while also providing a quick means to adjust the value.
Charting controls
Silverlight chart is a set of completely new classes that enable developers to easily create professional-looking column, bar, pie, line, scatter, and bubble charts. These different re‑stylable and re‑templatable charts are exposed as series controls that the chart control can host, allowing you to combine them.
Here's all it takes to create a simple column chart in XAML (note that there's no code required):
Let's take a look at a simple example:
The XAML above produces the following chart:
Themes
In addition to the controls listed in this post, you’ll also find ten themes available for your applications within the toolkit. Below, you can see a screenshot of what these themes look like.
You can learn even more about these controls and the Silverlight Toolkit on CodePlex here.
Namaste!
"Here's all it takes to create a simple column chart in XAML (note that there's no code required):"
Kind of splitting semantic hairs there. I see 13 lines of code - XAML code. How is that different from this pseudo-C# code:
ChartControlColumn ccc = new ChartControlColumn();
ccc.Items.AddRange(new Object[] { 1, 2, 3 });
ChartControl cc = new ChartControl();
cc.ChartType = ChartType.Series;
cc.Columns.Add(ccc);
this.Controls.Add(cc);
And this example is kind of contrived - the moment you need to do anything active, you'll need code-behind, which means you'll be working in two disconnected languages: XAML and C# or VB.
That's kind of what bugs me about this new found evangelism for XAML. There's an awful lot of handwaving to make some basic issues (like the lack of a good designer system integrated into Visual Studio and the weird upside-down object design relative to .Net Forms) go away.
@Jeff.
The XAML is created for you by a designer working with Blend (and I dont think of XAML as being code. Code can be executed, while XAML must be translated to code first before it can be executed. XAML is a markup language that makes it much easier to read/declare your UI then it is with code).
In the code behind a developer only works with the objectmodel of the created XAML code.
It all feels really natural to me, and I don't see a problem at all.
In fact it promotes even more the separation of design and logic, which is a good thing.
At the same time, in your view you shouldn't have much code to start with. If that is the case, then your UI controls are filled with logic that should not be there. A Silverlight developer is still mainly a .NET developer. Most code will/should be placed in business layers, not in your View.
@Jeff - working with XAML effectively involves several new concepts, and that's hard to communicate with a "hello world" sample. Actually, you would typically not use code behind for this sample, but rather you would databind to your Chart rather than creating the collection. If you have a DataContext set, with a Data property that's an array of numberic value, the above XAML collapes to:
<charting:Chart Title="My First Chart">
<charting:Chart.Series>
<charting:ColumnSeries ItemsSource="{Binding Data}"/>
</charting:Chart.Series>
</charting:Chart>
The only line in the code behind would be:
this.DataContext = new MyDataSource();
Hope that helps.
Shawn
Soma, it is still very difficult to add text with hyperlinks in Silverlight. TextBlocks do not support hyperlinks (This is possible in WPF). There is no richtextbox in Silverlight except those made by individuals. Any news if SL 3.0 will provide support for these?
Will SL 3.0 provide Authentication (Login) controls in the box, so that Silverlight is independent from ASP.NET for Authentication/Authorization, etc?
Other than that, Silverlight and the Toolkit is execellent stuff from Microsoft and the open source community.
The biggest thing I'd love to see would be a rich text editor that allows the user to add text and images and then save the results as HTML.
With the end result being to get the entered markup and images stored in a database.
That would be a truly awesome addition to Silverlight or ASP.NET.
We are working on adding support for embedding UI elements into TextBlock. With inline UI elements you can put images or even HyperlinkButton elements in there.
I can't guarantee yet if this will be in Silverlight 3 yet but I'm working on trying to make it happen.
-mark
Silverlight Program Manager
Microsoft
This post is provided "as-is"
Another suggestion: Why not release a Silverlight version of Live Hotmail? This can help both Silverlight and Live Hotmail and provide users with rich email experiences. Am more than willing to help out in this endeavor! :)
@Mark
That sounds promising Mark. I'm very glad it is being looked in to. I'm anxious to hear more about the Silverlight roadmap so I can better plan what tech I want to use for future projects.
None of the technologies are integrated well nor is there a concise development environment to handle XMAL, SILVERLIGHT, CODE BEHIND and MVC or even a technology strategy that makes sense, if you really think about it integration is a major challenge. It appears they are just throwing, whatever is in some state of being marginally completed (I use the term completed very loosely) against the wall and seeing what sticks.
I really don't believe anyone can get excited about an up and down numeric textbox. Moreover I hardly call this blogworthy. This was called a spinner control in late 90's and it is just now making it's way into the silverlight dev tools. It's implementation is more accurately called catch-up!
Personally I wouldn't use any of this tech for the next several years and take a wait and see approach - I think jury is still out if any of this will make any major inroads.
@Mark Gordon: Who are you to decide what is blog worthy or not? Stay out of it if you don't have anything to discuss or worthy to say. Stick with your Visual FoxPro and don't comment on advanced technologies whose potential is beyond your comprehension.
Sam - what you said, twice over.
Sam,
You cheerlead products that simply create more work, and are poorly implemented. More importantly these products utilize a paradigm geared, not in productivity, but designed to protect the window os monopoly by linking, through the .BLOAT framework, our applications directly to the OS. Furthermore VS is attempting to destroy native application development.
If you argue with this thought process look at what has already transpired, Microsoft has bought out and killed every development kit it possibly could that competes with VS. The have written the best they could airtight EULA restricting cross platform development and definately not seriously playing in the open source arena. Don't you get it, it is competition that fosters innovation not monopolies and in the absence of competition the only avenue left is criticism which for the most part in their arrogance they ignore. If it wasn't for competition Microsoft would not be implementing MVC and Windows would not exist given what some may call it's close resemblance to the mac.
Moveover the core of the .BLOAT framework is NOT new that is the ironic part. .BLOAT is merely OS API wrappers and WPF is just a different way of getting at directx while pathetically wpf is not even tightly integrated into VS! Where is the innovation, giving something that already existed a new name or the fact Microsoft wrapped the API in classes and put a big red bow around it and forced developers to use it!
If you really look at this, the very foundation of the OOP programmming model is based on polymorphism, encapsulation and inheritance. And while c# is being called a true oop language and .BLOAT is being called a framework by some, VS doesn't lend itself to these principles just look at the code it generates and the class browser. Moreover LINKTOSQL from a puriest point of view doesn't scale since it excutes commands on the sql box. So microsoft is basically redefing the OOP foundation to fit into it's VS paradigm. This is going backward not forward. I truely believe why they are getting away with this is new VS programmers DO NOT understand what OOP programming "REALLY" is or fully comprehend the concept of reusability (true frameworks) and it's overwhelming benefits since VB never fully implemented an OOP programming model.
What is really great in 5-10 years when this all plays out everyone will owe me a huge apology as everything I said will be right on the Mark as usual. Programmmers will get tired of maintaining VS spaghetti code and either a new development platform will be released to compete with open source and allow native development while implementing oop correctly and/or .NET will finally refocus on reusability and return to the foundation of the oop paradigm, personally I think the later will occur. All you early adapter cheerleader types will be stuck maintaining thousands of lines of obselete code/xmal and your customers will love you for throwing them under the bus..... In the mean time I will continue fixing the messes "you technology experts" make using proven paradigms.
"First they ignore you, then they ridicule you, then they fight you, then you win." --Mahatma Gandhi
@Mark Gordon: Read your post with patience and tolerance, which by the way, you do not deserve. I haven't seen another epitome of double standards as you anywhere in the world. One of your posts on your own blog a while ago was bad mouthing developers of India. Now you use a saying of Gandhi to end off your article?! You bad mouth Microsoft and you use some of its products for a living?! Whatever you said in your previous post is your twisted opinion to vent frustration because you do not understand current technology. You don't understand the usefulness of LINQ and can't get to use LINQ properly! You are stuck with VB and Visual FoxPro and tend to live in that horrible world of messy scripting and un-usable code. You remain ignorant and cannot educate yourself with C#, etc. So, don't go about ranting non-sense on a Microsoft blog and tell us what OOP really is. Write your own framework and try building a company like Microsoft or Google if you are so full of conviction with your ideas. Don't rant crap here.
@Soma: We can do without Gordon. Instead of having fruitful discussions and discussing technology with others that understand .NET, why are we made to read Gordon's nonsense? It's not that he leaves any constructive criticism. He's out here to demonstrate to the world what an idiot he is.
Why do you allow his posts?
@Sam this is a fruitful dicussion and I really don't think you read my comments!
I don't complain about c# or sql server in my comments or blog. Of course there are minor issues with them but nothing worth wasting my time blogging about. You question my skills which I already went into but you not answering what type of programming you do or if you work for Microsoft?
Perhaps if I was just an a cog programmer in an IT department paid hourly to churn code or worked for Microsoft. I wouldn't be concerned about how much extra work a development tools costs me. But since I'm actually in the field selling solutions based on this nonsense development toolkit this is a huge concern. These tools are adversely affecting my profit margins!
I moved in VFP and VB for select applications because those are "THE RIGHT" tools for small and medium size businesses. Using these tools you are able to quickly generate a true OOP N-TIER applications that scales very well and provide customers a solution with low a cost of ownership. This is in part due to the fact VFP has a "true" data centric language and VB/VFP has a royalty free distribution. You CAN NOT DO this with Visual Studio. If you feel the urge to dismiss this claim go ahead build a desktop VS winform/SQL application with 20 user support and I will duplicate it in VB/VFP and prove you wrong! As I know for a fact it can't be done! VS requires more code which equates to more time besides the fact you need to add into your quote the sql server licensing and new hardware. You will lose this bet. But we all should dismiss this arugement because they are Microsoft right?
As far as these new technologies go like WPF which you are so fond of, given it has been out for more then 2 years don't you find it even the least bit interesting it is not highly utilized in Windows 7? Moreover while it is supposed to be used in VS 2010 Soma's blog indicates it will not be fully implemented in the production release of VS. '
There are two logical reasons for this
1) The VS source has the tiers completely intermingled. Since this is the default behavior for most VS applications this could very well be the case.
2) Not even Microsoft can use WPF to create a completely standalone UI layer. Given the number of programmers they can throw at this I find it very interesting. As in all the application I write the UI is completely seperate from the business rules and it can be swapped out with very little work.
Given the fact the class browser in VS is pathetic with regards to subclassing UI controls and you have to deal with a host of bugs to even code a ui layer out most programmers don't even bother generating a complete UI layer for their application. I'm fully aware of these issues as I use a true UI layer in all the applications I develop. Since VS is supposed to be an OOP environment and Microsoft calls every wrapper they produce a framework I find this poor implementation at the UI level mind-boggling. This terrible UI implementation even gets worse in Web-Forms and even their latest MVC "FRAMEWORK" doesn't fully address the seperation issue completely. This is inexcusable. The funny part the legacy application VFP has this implemented correctly, UI framework layers work perfectly! I guess we just dismiss this flaw in VS as well right, as who needs a UI layer in a business framework right?
My comments about linktosql are founded in fact as even you admited in a prior rant to me linqtosql is not a middle tier technology and since it generates SQL Server script it can not scale unless you chain sql server boxes together which is not scaling an application. Since I'm obviously completely right as usual where do you get off saying I lack experience in this technology? The fact is Microsoft's latest greatest data access technology is a LEGACY two teir solution. How is that progress? Or should we just dismiss this too because they are Microsoft and continue to cheerlead this "advancement."
What is wrong with wanting tools that work! It is perfectly fine that I deliver applications that meet my customers needs but how dare I point out Microsoft's shortcomings especially given they killed an environment platform that meet my customers needs without a suitable replacement. Therefore the best you can do it flame me on a board and attempt to dismiss these bugs how is that helping the development community! It isn't it is cheerleading!
@Mark Gordon: Read my direct responses to all your "opinions":
These tools are adversely affecting your profit margins because you don't know how to use them or perhaps you don't believe in them and want to cry over n over instead of taking the time to learn how to use your tools before you use them to sell solutions.
VFP and VB may be "the right" tools in your fantasy world of the past. It is mighty hard to get developers who will code in VFP. Today, small and medium sized businesses either opt for Windows Server 2003/2008, with SQL Server and VS.NET (C# or VB.NET) for development. Designers have tools like Expression Blend, Design, or products from Adobe. I know several hundreds of businesses using these tools today. Who uses VFP and VB? May be 1 or 2 companies where you provide your twisted opinions. Today small businesses have the option to go for the Bizspark program that Microsoft offers - hence giving them 3 years of free server and development software. There is virtually no cost to a small or startup business.
Are you telling the world that you can build a more scalable, robust, fault-tolerant, SECURE and efficient application in VFP and VB vs. using .NET and SQL Server? Any beginner will beat your most sophisticated application written in VFP. Sure, someone stuck in the past can write programs in C or Pascal as well, but requirements in today's world are more sophisticated and complex than when C, Pascal or VFP were created. Those things are not designed to solve "real world" problems of today. 20 user support applications are what you can make in VB and VFP. SQL Server is not for you Mr. Gordon. Did you know it can handle thousand to millions of users?
Windows 7 is an operating system. Do you know what that means? Or do I have to define it for you? WPF is a front-end technology for writing applications that can run on Windows 7. As of today, VS 2010 shall contain bits written in WPF.
About your point:
"2) Not even Microsoft can use WPF to create a completely standalone UI layer. Given the number of programmers they can throw at this I find it very interesting. As in all the application I write the UI is completely seperate from the business rules and it can be swapped out with very little work."
Look at it this way, every project has a requirements phase. Those who invest time to do this properly rarely ever need to change their UIs. If you can get this right, there should be almost no reason to swap out WPF UI for WinForm or vice-versa. Even if there is need to, it can be done without problems assuming the business tier/layer was written to take changes into account. Microsoft is not a company with unlimited resources. Why do you have unrealistic expectations from them? They provide us with tools - it is up to us to choose them judiciously. You do not like WPF, don't use it. But don't give me or others who work on it foolish assumptions coming from figments of your imagination.
I don't know what programmers you deal with or how those poor programmers deal with you. It is obvious that you do not understand how to write UI for applications using today's technologies since your stuck with VFP. As for MVC, I haven't looked into that yet - so I won't comment on it. I'm not a big fan of MVC style as yet.
As I re-call correctly, I showed you how to use LINQ-to-SQL correctly. However, given the little sense you can make out of today's technologies, it isn't a wonder that you still don't get it. I also mentioned that for more complex scenarios you could use N-hibernate, Entity Framework (which I admit needs more work) or simply, ADO.NET. What leads you to believe that executing SQL scripts on SQL Server does not scale an application? Isn't that the purpose of SQL Server - to execute SQL and provide you with data? If LINQ-to SQL generates SQL for SQL Server, whats wrong with that?!!! You can jolly well have a server farm for your business logic that can both scale and add efficiency for your applications. Unless you have more than a few hundred "simultaneous users", even that is NOT necessary. LINQ is a superior programming technique Mr. Gordon. There are many more uses for it. Go and learn and educate yourself before you dismiss it.
Finally, there is nothing in wanting tools that work! That's why millions of developers around the world are happy with VS.NET. Again, your expectations out of Microsoft are unreasonable. Your customers need to move on with times and adopt current technologies because these are made to deal with requirements of today's world. You keep them in the dark because of your fondness with ancient technology then, you are just blinding your customers for the sake of your own profits! So, stop cheerleading the past technologies and move on!
Don't stand against the path of innovation and evolution just because you love ancient technology. Some of the new technologies will be here to stay and some won't be. If we knew what the future has in store, then the present would not be interesting!