Hello
I'm working on and off a prototype GUI for an existing application using Telerik WinForms Controls for about one year now. Most important controls for me are the GridView and the Docking Controls.
While I'm for the most part impressed by the functionality and design of the controls, I have a deep concern about actually releasing an application using these controls. Here's the reason why: since starting development of the prototype (about 1 year ago) there was no release of the controls that did not at least contain one showstopping bug that would make release of a commercial product based on these controls unthinkable. What's worse, the release policy of telerik forces me to use the newest build with new features to resolve bugs in existing releases. I would prefer a release scheme that separates bug fixing from introduction of new features.
What I would like:
- list of known bugs for each version visible for licensed customers
- high frequency of service pack releases relative to a major release with no introduction of new features or heavy refactoring
- ongoing support and bug fixes for each released major release for at least a year, so that we can get bug fixes without being forced to upgrade to new feature releases (that so far always introduced bugs to previously working functionality)
The current policy forces me to thoroughly retest the application with each SP release and typically forces development of workarounds for new bugs. Also constant changes of end user experience because of changed behaviour is unacceptable for a commercial product.
What do others think? Has anybody actually released a commercial product based on telerik Windows Forms controls to a larger audience - if yes, how do you handle the bug fixing problems with telerik controls for win forms?
Regards
Erwin
8 Answers, 1 is accepted
0
Hello erwin,
Thank you for contacting us.
You put forward some interesting discussion topics and we would love to see what the Telerik community thinks of them. I will try to address the more specific questions you have to give you an insight of why we do things the way we do.
List of known bugs for each version visible for licensed customers
This is in the works. Dubbed as Public Issue Tracking System, it will offer a list of known issues which our customers can review at their leisure. Not only we will list all known issues, but we will also list the features you guys have requested from us.
The system will give you the ability to vote for bugs and feature requests, which will directly impact our decision making process, because we will have a better way of tracking what's the most important bug we will need to address, or the most important feature that our clients would like to see in the next major release. We hope that the Public Issue Tracking System will provide more details on what are working on and will make our job more transparent. The time frame for this is early next year.
High frequency of service pack releases relative to a major release
Our release is as follows: we have three major releases per year, and we provide at least on service pack per major release. If the major releases are 2-3 months apart (short release cycle) we usually ship just one SP. If the time between major releases is 3-4 months (large release cycle) we provide two service packs. If there are showstopper issues in any release, we may provide more service packs to address the problems, however we seldom get to three service pack per major release.
Furthermore, if a customer reports an issue that he thinks is a showstopper for his work, and if we think that the issue has a fairly large impact, we will provide him/her with a custom build, addressing this particular issue. Although this is not a practice we would like to enforce publically (ideally there should not be such issues), we try to get the customer going by helping him out as fast we can.
Unfortunately, such unplanned custom builds usually take considerable amount of time to test and prepare relative to the amount of fix(es) it offers. So the line of whether to provide a custom build or not is very thin, especially towards the end of a major release. We take into consideration our plans for a particular release, time frame till next release, what our customer's expectations are, etc. before we make such decisions.
This said, Telerik has always taken pride of its release schedule, and most of our customers think of it as being aggressive. History shows that we have 3 major releases per year, at least one SP per release, and a minimum of 1 custom build per release, for a minimum of 9 releases per year, which is a duration of 1.5 months per release. Some of our competitors are not able to match this release cycle, at least not for the competitive price we sell our products at.
Still, your opinion seems to differ from the common perception and I will be happy to hear your thoughts on how we can further improve our release schedule to meet your needs.
No introduction of new features or heavy refactoring in service packs
I agree with you totally on this one and it has always been our priority to introduce as little breaking changes as possible in major releases, and none in minor releases. However, as with all software, things evolve: new technologies and methodologies emerge, there are shifts in customer requirements and expectations, code needs to be optimized, performance need to be improved, etc. These are all valid business reasons to do something differently than we did it 3 years ago, so that we can introduce new features and products, and keep our customers happy (and ultimately stay in business). This however has to be true only for major releases and this is what we do - we do not have breaking changes in service packs and if do, we will glady fix them right away. We also stay away of doing refactoring in minor versions, becuase it is bad practice.
If we are to introduce breakign changes, we mark the old properties and methods as obsolete so that our customers can respond to the changes. Our policy is to support obsolete properties and methods for at least one major release, however since this is a bit short in the WinForms world, we usually support them for 2 or 3 major releases, depending on the impact of the change(s).
There is one very important factor which has direct impact on such changes - customer expectations and demands. If we are pushed to introduce a major fix or a feature request in a service pack, say from an enterprise customer, and if the change is fairly minor, i.e. it will not impact the majority of our customers, the chances are that that we will do it - otherwise it will be pushed in a custom build or a major release. Our focus has always been to keep the customers happy and we are following this policy closely.
Ongoing support and bug fixes for each released major release for at least a year, so that we can get bug fixes without being forced to upgrade to new feature releases
We operate in a very intense, competitive and fast-moving environment. We need to be able to provide rapid responses to our customers, both in terms of technical support and new features. We need to be able to stay ahead, or at least in par, with the competition. Since we have limited resources (in terms of developer time, release schedule, etc), we prefer to focus on fixing, improving and providing value to the widest range of customers in the shortest possible release cycle.
I understand your concern and I am sure that support for older versions will be greatly appreciated by you guys, but at what cost? On prima vista it seems that we will have to support at least 4 code bases (three for the last three major releases + one for the next major version) which is very hard. Even if we support old versions and provide custom builds, there is no way of knowing that you would not hit another issue which was consequitively fixed, which makes the bug fixing process unusually complicated and time-consuming. Generally speaking, we would not mind doing this, however this will impact the price of our tools considerably. From this standpoint, we prefer to focus on continuous quality improvements and to offer more service packs, than to support several code bases.
As to bugs - we have nearly 50 products and very large code base, which unfortunately takes its toll on the number of issues that we have. I am happy to say however, that the suite is getting more and more mature with each new release and we are handling issues far better than before. We are dedicating more time for testing and training, without affecting the volume of work. Yes, there are areas we have to improve further and there is always more we can do to improve quality.
In case you guys have any suggestions on what we can do to make you happier, please feel free to share them.
Finally, erwin, please send me a list of issues which need our immediate attention in your opinion so that we can address them as soon as possible.
Greetings,
Vassil Petev
WinForms Unit Manager
the Telerik team
Check out Telerik Trainer, the state of the art learning tool for Telerik products.
Thank you for contacting us.
You put forward some interesting discussion topics and we would love to see what the Telerik community thinks of them. I will try to address the more specific questions you have to give you an insight of why we do things the way we do.
List of known bugs for each version visible for licensed customers
This is in the works. Dubbed as Public Issue Tracking System, it will offer a list of known issues which our customers can review at their leisure. Not only we will list all known issues, but we will also list the features you guys have requested from us.
The system will give you the ability to vote for bugs and feature requests, which will directly impact our decision making process, because we will have a better way of tracking what's the most important bug we will need to address, or the most important feature that our clients would like to see in the next major release. We hope that the Public Issue Tracking System will provide more details on what are working on and will make our job more transparent. The time frame for this is early next year.
High frequency of service pack releases relative to a major release
Our release is as follows: we have three major releases per year, and we provide at least on service pack per major release. If the major releases are 2-3 months apart (short release cycle) we usually ship just one SP. If the time between major releases is 3-4 months (large release cycle) we provide two service packs. If there are showstopper issues in any release, we may provide more service packs to address the problems, however we seldom get to three service pack per major release.
Furthermore, if a customer reports an issue that he thinks is a showstopper for his work, and if we think that the issue has a fairly large impact, we will provide him/her with a custom build, addressing this particular issue. Although this is not a practice we would like to enforce publically (ideally there should not be such issues), we try to get the customer going by helping him out as fast we can.
Unfortunately, such unplanned custom builds usually take considerable amount of time to test and prepare relative to the amount of fix(es) it offers. So the line of whether to provide a custom build or not is very thin, especially towards the end of a major release. We take into consideration our plans for a particular release, time frame till next release, what our customer's expectations are, etc. before we make such decisions.
This said, Telerik has always taken pride of its release schedule, and most of our customers think of it as being aggressive. History shows that we have 3 major releases per year, at least one SP per release, and a minimum of 1 custom build per release, for a minimum of 9 releases per year, which is a duration of 1.5 months per release. Some of our competitors are not able to match this release cycle, at least not for the competitive price we sell our products at.
Still, your opinion seems to differ from the common perception and I will be happy to hear your thoughts on how we can further improve our release schedule to meet your needs.
No introduction of new features or heavy refactoring in service packs
I agree with you totally on this one and it has always been our priority to introduce as little breaking changes as possible in major releases, and none in minor releases. However, as with all software, things evolve: new technologies and methodologies emerge, there are shifts in customer requirements and expectations, code needs to be optimized, performance need to be improved, etc. These are all valid business reasons to do something differently than we did it 3 years ago, so that we can introduce new features and products, and keep our customers happy (and ultimately stay in business). This however has to be true only for major releases and this is what we do - we do not have breaking changes in service packs and if do, we will glady fix them right away. We also stay away of doing refactoring in minor versions, becuase it is bad practice.
If we are to introduce breakign changes, we mark the old properties and methods as obsolete so that our customers can respond to the changes. Our policy is to support obsolete properties and methods for at least one major release, however since this is a bit short in the WinForms world, we usually support them for 2 or 3 major releases, depending on the impact of the change(s).
There is one very important factor which has direct impact on such changes - customer expectations and demands. If we are pushed to introduce a major fix or a feature request in a service pack, say from an enterprise customer, and if the change is fairly minor, i.e. it will not impact the majority of our customers, the chances are that that we will do it - otherwise it will be pushed in a custom build or a major release. Our focus has always been to keep the customers happy and we are following this policy closely.
Ongoing support and bug fixes for each released major release for at least a year, so that we can get bug fixes without being forced to upgrade to new feature releases
We operate in a very intense, competitive and fast-moving environment. We need to be able to provide rapid responses to our customers, both in terms of technical support and new features. We need to be able to stay ahead, or at least in par, with the competition. Since we have limited resources (in terms of developer time, release schedule, etc), we prefer to focus on fixing, improving and providing value to the widest range of customers in the shortest possible release cycle.
I understand your concern and I am sure that support for older versions will be greatly appreciated by you guys, but at what cost? On prima vista it seems that we will have to support at least 4 code bases (three for the last three major releases + one for the next major version) which is very hard. Even if we support old versions and provide custom builds, there is no way of knowing that you would not hit another issue which was consequitively fixed, which makes the bug fixing process unusually complicated and time-consuming. Generally speaking, we would not mind doing this, however this will impact the price of our tools considerably. From this standpoint, we prefer to focus on continuous quality improvements and to offer more service packs, than to support several code bases.
As to bugs - we have nearly 50 products and very large code base, which unfortunately takes its toll on the number of issues that we have. I am happy to say however, that the suite is getting more and more mature with each new release and we are handling issues far better than before. We are dedicating more time for testing and training, without affecting the volume of work. Yes, there are areas we have to improve further and there is always more we can do to improve quality.
In case you guys have any suggestions on what we can do to make you happier, please feel free to share them.
Finally, erwin, please send me a list of issues which need our immediate attention in your opinion so that we can address them as soon as possible.
Greetings,
Vassil Petev
WinForms Unit Manager
the Telerik team
Check out Telerik Trainer, the state of the art learning tool for Telerik products.
0
erwin
Top achievements
Rank 1
Veteran
Iron
Rank 1
Veteran
Iron
answered on 16 Dec 2008, 12:30 PM
Thanks Vassil for your in-depth reply.
I think the open discussion here in your forum is one of the many positive factors about your company. As I said, I really like your product and greatly appreciate the quick support I get here in the forum or when filing a bug report. I see the following problem with your release policy,
from my experience in one year working with the controls:
The Q Release with no service pack is usually so buggy, nobody would ship a product on this release.
If the app crashes with unhandled exceptions, the client is not convinced when told that the problem is beyond my control.
The SP1 one release usually fixes the most blatant bugs, now it's time to discover all the breaking changes from the prior version and educate the client that things do no longer work as before.
Now I'm stuck to wait for the new Q release and the circle restarts.
I'm aware of the conflict between developers that want to build a stable product and marketing that wants new features implemented. Also I'm aware that the controls for win forms are a relatively new product.
But I think developers of windows forms applications need more stability within the product, especially if you think about the expensive deployment cost of rich client applications.
I would like to test new features with the Q1 Release, develop with SP1, beta test with SP2 and maybe ship with SP4 with no breaking changes within the SPs.
Currently most important bugs that impact my application prototype:
Most important missing functionality:
Most important shortcomings:
Nice to have:
I filed all this either as bug reports and/or forum posts.
Would be interesting to hear what other users of the controls are thinking about the current release policy of mixing bug fix and feature releases and how thy tackle the problem of delivering a stable product to the end user, when on one hand you are forced to upgrade to new feature releases to fix old bugs and on the other hand these feature releases break existing functionality.
Regards
Erwin
I think the open discussion here in your forum is one of the many positive factors about your company. As I said, I really like your product and greatly appreciate the quick support I get here in the forum or when filing a bug report. I see the following problem with your release policy,
from my experience in one year working with the controls:
The Q Release with no service pack is usually so buggy, nobody would ship a product on this release.
If the app crashes with unhandled exceptions, the client is not convinced when told that the problem is beyond my control.
The SP1 one release usually fixes the most blatant bugs, now it's time to discover all the breaking changes from the prior version and educate the client that things do no longer work as before.
Now I'm stuck to wait for the new Q release and the circle restarts.
I'm aware of the conflict between developers that want to build a stable product and marketing that wants new features implemented. Also I'm aware that the controls for win forms are a relatively new product.
But I think developers of windows forms applications need more stability within the product, especially if you think about the expensive deployment cost of rich client applications.
I would like to test new features with the Q1 Release, develop with SP1, beta test with SP2 and maybe ship with SP4 with no breaking changes within the SPs.
Currently most important bugs that impact my application prototype:
- Excel ML Export (removed my homegrown code in favor of ExcelML export in Q2, now it's broken in Q3 SP1).
- Column Sizing/Ordering in the Grid broken in Q3 SP1 (when doing drag/drop from column chooser or grouping panel)
Most important missing functionality:
- True master detail support in hierarchical grids (no way for creating new master record and then inserting new details)
Most important shortcomings:
- Performance issues / inefficient painting code in Docking (painting code called for invisible docked areas for example), telerik announced re-engineering of the docking component, now I don't know if that's a good or bad thing.
- ListBox User experience is different from standard Windows Listboxes (Keyboard interface for selecting items by typing first letter)
- UI for filtering in the Grid is confusing especially with check boxes, there is no visual clue if filtering is active nor not
- Docking DropDown List for tab windows does not show icon of the tab.
Nice to have:
- Charting component does not really live up to the expectations, but is ok as a free goodie.
I filed all this either as bug reports and/or forum posts.
Would be interesting to hear what other users of the controls are thinking about the current release policy of mixing bug fix and feature releases and how thy tackle the problem of delivering a stable product to the end user, when on one hand you are forced to upgrade to new feature releases to fix old bugs and on the other hand these feature releases break existing functionality.
Regards
Erwin
0
Davor Brckovic
Top achievements
Rank 1
Rank 1
answered on 07 May 2010, 03:01 PM
I agree with Erwin on every point.
In our company, Telerik became synonym for bug. We've been struggling with bugs, crashes, unexpected behaviours in Telerik components for more than three years, allways hoping that the next version is the one where all bugs will be solved. But in three years, this never happened. As new versions arrived, so did new bugs and whole new set of workarounds we had to learn.
Last year's release was the last time we upgraded because it seems Telerik has no intention of creating a stable product. The biggest reason you release new versions is to implement new half-tested features which look good on marketing materials.
0
erwin
Top achievements
Rank 1
Veteran
Iron
Rank 1
Veteran
Iron
answered on 18 May 2010, 08:07 PM
With the last couple of releases I thought Telerik was on the way for a more customer friendly release policy, but
unfortunately the 2010 Q1 SP2 release was a major step back, in that they decided to change the default Telerik theme considerably.
This means that just to get the roll-up bugfixes of SP2 I now have to maintain my own theme plus have to modify my setup routine to make the app look the same as before or explain to the customer why a bug fix update looks totally different from the last version.
unfortunately the 2010 Q1 SP2 release was a major step back, in that they decided to change the default Telerik theme considerably.
This means that just to get the roll-up bugfixes of SP2 I now have to maintain my own theme plus have to modify my setup routine to make the app look the same as before or explain to the customer why a bug fix update looks totally different from the last version.
0
Hello Erwin,
Please, excuse us for this. We made this change out of sincere believe that we are doing the right thing - our controls have never looked so close to the original Office 2007 Blue theme, that they are trying to mimic. Since we thought that the new theme looks considerably better than before, we decided to use it instead.
I see that you have a ticket opened on the subject and we will try to send you the previous version of the theme shortly, which you can continue to use in your application without modifications. Again, sorry for this - we just want to improve things for the better.
@ Davor: Davor, we did not find any reports/tickets under your account (nor under your company's purchase) which to help us understand and address your concerns. We will very much appreciate it if you be more specific/critical in your feedback, so that we are able to assist you with whatever necessary. Thank you for the understanding.
Sincerely yours,
Vassil
the Telerik team
Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.
Please, excuse us for this. We made this change out of sincere believe that we are doing the right thing - our controls have never looked so close to the original Office 2007 Blue theme, that they are trying to mimic. Since we thought that the new theme looks considerably better than before, we decided to use it instead.
I see that you have a ticket opened on the subject and we will try to send you the previous version of the theme shortly, which you can continue to use in your application without modifications. Again, sorry for this - we just want to improve things for the better.
@ Davor: Davor, we did not find any reports/tickets under your account (nor under your company's purchase) which to help us understand and address your concerns. We will very much appreciate it if you be more specific/critical in your feedback, so that we are able to assist you with whatever necessary. Thank you for the understanding.
Sincerely yours,
Vassil
the Telerik team
Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.
0
erwin
Top achievements
Rank 1
Veteran
Iron
Rank 1
Veteran
Iron
answered on 19 May 2010, 08:40 PM
Hello Vassil,
I'm not saying that the new Theme looks bad. Just that fundamental changes in the UI (such as the theme's default font or default text color) should not be part of a service pack.
Imagine a real world application that consists not only of Telerik based controls but maybe controls by other vendors or own user controls that are shared with other projects. To glue things together again may be a significant amount of work.
Regards
Erwin
0
Davor Brckovic
Top achievements
Rank 1
Rank 1
answered on 26 May 2010, 01:32 PM
Hi!
I'll list some of the issues we've been having over the years. Some of them have been solved in new releases, but each release brought new issues, and it's a neverending loop.
- Sometimes, when we were creating a new tab page in a TabStrip, all controls from existing content panel somewhere else on the form were moved to this new content panel, or we got designer errors, and had to restore old version of the file.
- The process of upgrading Telerik controls to a new version was never straight forward or simple. After every upgrade we had dozens of designer errors (even if we used project update utility). When we fix those errors, some Telerik controls would remain uneditable, and unselectable by VS designer. Deleting resx, files usually solves this problem but this means we have to reapply all resources back to each form.
- Removing title bars from MDI child forms is impossible, Even after setting FormBorderstyle to None and removing Minimize, Maximize buttons, they still appear when the form is maximized inside a MDI parent. The workaround was to add code into SizeChanged event which changes the size of the child form when the parent is resized.
- Each Telerik control has a deep and complex tree of skinnable elements. This is all fine and one of the reason we initially bought Telerik controls, but there are also so many properties which do absolutely nothing. For example, Filter row of the RadGrid control has so many color properties, but 99% of those properties don't have any effect on how filter row looks like.
- Ever since the first version, Telerik had problems with skinning value editors (textboxes which are opened when you click on a editable cell in the grid). Those editors never looked like the rest of the control, because they are fully or partially ignoring the theme of the control. For example, filter editor textbox of the RadGrid control inherits cell fore color but ignores it's back color. So when you have black cell with white text, it's editor will be white textbox with white text. The only way to fix this is to write your own editor and use it in EditorRequired event. But then this editor works only on textual values, so you have to create comboboxes, numerical boxes ... In short, you have to write 200 lines of code just to change the text color of some element.
There were some other issues which I can't remember now, but as with all of them, we've been able to find a workoround on the forums, or create our own workaround so we didn't have to open any tickets. But the point is, when working with Telerik controls, I'm allways affraid that something could break any time.
I think Telerik controls need a period of at least one year of intensive testing, optimizing and bug-fixing without adding any new features. I'd much rather work with stable tool which has 5 features, than with unstable tool with 250 features.
0
Hi Davor Brckovic,
As my colleague Vassil said, the suite is getting more and more mature with each new release and we are handling issues far better than before. We are dedicating more time for testing and training, without affecting the volume of work.
I want to assure you that each new version should pass a serious QA cycle before being released on the market. However, as the complexity of the product is high, some issues might have been missed. This is the point where we expect you - our customers, to share your critical and descriptive feedback either negative or positive. This is the only way we can know about the existence of issues uncovered by the QA cycle and address them accordingly.
I would like to get a list from you about the issues that you have experienced with the latest versions. This will allow us to investigate the cases and provide you with the necessary assistance. Please send sample projects/screenshots where the issues are more complex so that we can reproduce them locally with the help of these resources.
Now directly to your points:
- I would kindly ask you to send me a sample project and a list of steps that we should perform in this project in order to understand the case. This will allow us to address the issue further. Please note that we are developing a brand new control that will support the behaviors of RadTabStrip and RadPanelBar and it will address their known issues accordingly. This control is called RadTabView (a.k.a RadPageView) and you can find more information about it here.
- The Project Update Utility was designed for the purposes of replacing references to assemblies of an older version with the references of assemblies of the latest one. However, this tool does not update your code base related to Telerik. Still, we publish a list of release notes with each new version that comes out. The release notes are marked in red for better recognition. Where the list of changes fails to help, we are always ready to assist you. Just open a new support ticket and send us the necessary data (the designer file which shows errors) so that we are able to help you.
- This issue should have already been addressed. If there is any change that your continue experiencing the wrong behavior in our latest version, please write back providing the necessary information.
- The most of the properties that you see for an element are adequate to what they should do. However, please note that some of them may come from a base element and may not have an actual implementation for that particular descendant. The other case may concern a layout of the control which does not allow a property to reflect on the appearance as this appearance is actually controlled by the layout. Should you have any specific questions or requirements, write back and we will assist you accordingly.
- This styling issue will be addressed in Q2 2010 or shortly after that.
I hope this helps. If you have additional questions, feel free to write back.
All the best,
Nikolay
the Telerik team
Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.
As my colleague Vassil said, the suite is getting more and more mature with each new release and we are handling issues far better than before. We are dedicating more time for testing and training, without affecting the volume of work.
I want to assure you that each new version should pass a serious QA cycle before being released on the market. However, as the complexity of the product is high, some issues might have been missed. This is the point where we expect you - our customers, to share your critical and descriptive feedback either negative or positive. This is the only way we can know about the existence of issues uncovered by the QA cycle and address them accordingly.
I would like to get a list from you about the issues that you have experienced with the latest versions. This will allow us to investigate the cases and provide you with the necessary assistance. Please send sample projects/screenshots where the issues are more complex so that we can reproduce them locally with the help of these resources.
Now directly to your points:
- I would kindly ask you to send me a sample project and a list of steps that we should perform in this project in order to understand the case. This will allow us to address the issue further. Please note that we are developing a brand new control that will support the behaviors of RadTabStrip and RadPanelBar and it will address their known issues accordingly. This control is called RadTabView (a.k.a RadPageView) and you can find more information about it here.
- The Project Update Utility was designed for the purposes of replacing references to assemblies of an older version with the references of assemblies of the latest one. However, this tool does not update your code base related to Telerik. Still, we publish a list of release notes with each new version that comes out. The release notes are marked in red for better recognition. Where the list of changes fails to help, we are always ready to assist you. Just open a new support ticket and send us the necessary data (the designer file which shows errors) so that we are able to help you.
- This issue should have already been addressed. If there is any change that your continue experiencing the wrong behavior in our latest version, please write back providing the necessary information.
- The most of the properties that you see for an element are adequate to what they should do. However, please note that some of them may come from a base element and may not have an actual implementation for that particular descendant. The other case may concern a layout of the control which does not allow a property to reflect on the appearance as this appearance is actually controlled by the layout. Should you have any specific questions or requirements, write back and we will assist you accordingly.
- This styling issue will be addressed in Q2 2010 or shortly after that.
I hope this helps. If you have additional questions, feel free to write back.
All the best,
Nikolay
the Telerik team
Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.