DisplayEnds property missing

[Matthew]

I've been using the RadToolbar for Asp.Net with the DisplayEnds property set to false so that I could blend the toolbar into the background image.  Basically, I want the toolbar to look like it extends the entire width of the container.  I'm not able to do this with the ASP.NET AJAX version since there doesn't appear to be a DisplayEnds property and setting the width to be 100% doesn't make the toolbar 100% wide.  Is there another way I can accomplish this in the ASP.NET AJAX version?

Thanks,
Matt

[Alex Gyoshev]

Hi Matt,

I created the styles needed to remove the rounded corners of the default skin, and make it span to 100% of its container's width:

div.NoRoundedCornerEnds,
div.NoRoundedCornerEnds .rtbOuter,
div.NoRoundedCornerEnds .rtbMiddle,
div.NoRoundedCornerEnds .rtbInner
{
    padding-left: 0;
    padding-right: 0;
    margin: 0;
    display: block;
    float: none;
}

div.NoRoundedCornerEnds .rtbInner { padding-left: 5px; }

div.NoRoundedCornerEnds .rtbOuter { background-position: 0 0; }
div.NoRoundedCornerEnds .rtbInner { background-position: 0 100%; }

The styles will work if you set the CssClass of the RadToolBar to "NoRoundedCornerEnds".

The styles should be the same if you use another skin, yet if you encounter any problems, please let me know.

Best wishes,
Alex
the Telerik team

Instantly find answers to your questions at the new Telerik Support Center

[Matthew]

That CSS change does remove the ends and make it 100% wide; however, I'm using the WebBlue skin and adding that css class causes a horizontal white space to appear in the center of the toolbar (I'm using Firefox).  Let me know if you need a screenshot.  I didn't see a way to upload the screenshot while replying to a thread.

Thanks,
Matt

[Alex Gyoshev]

Hello Matt,

Indeed, the WebBlue skin follows a different background pattern than the Default skin.

Removing the last two lines of CSS (those who set the background-position property) will remove the issue.

Regards,
Alex
the Telerik team

Instantly find answers to your questions at the new Telerik Support Center

[Matthew]

That worked great!  Thanks.

[Albert Shenker]

This solution does not seem to work for the Officce2007 skin. The left upper corner image still appears and the internal font styles of the toolbar buttons get screwed up.

Also, why was this property removed?

[Alex Gyoshev]

Hi Albert Shenker,

For the Office2007 skin, please use the following CSS:

div.NoRoundedCornerEnds,
div.NoRoundedCornerEnds .rtbOuter,
div.NoRoundedCornerEnds .rtbMiddle,
div.NoRoundedCornerEnds .rtbInner
{
    display: block;
    float: none;
    margin: 0;
    padding: 0;
}

div.NoRoundedCornerEnds .rtbOuter
{
    padding-top: 2px;
    background-position: 0 0;
}

div.NoRoundedCornerEnds .rtbInner
{
    background-position: 0 100%;
    padding-bottom: 2px;
}

The DisplayEnds property has been removed because it can be achieved easily by means of CSS styling.

All the best,
Alex
the Telerik team

Instantly find answers to your questions at the new Telerik Support Center

[Albert Shenker]

Thanks for the solution, however, this still does not work with the Office2007 skin. On the left hand side of the toolbar there is a small segment of border in the upper left hand corner which shouldn't be there. I will submit a help ticket so I can supply a screen capture.

As for your claim that the DisplayEnds property isn't necessary, I would think this thread is a clear example that this is false. Any solution that requires css is obviously more complicated than simply setting a control property. Furthermore, this particular solution means providing different css depending on which skin is being used, and it appears, having to try each skin out and posting to this thread to get the proper css styles. I would think you would see that this fact alone makes the new implementation far worse than the old.

Lastly, we all have a whole bunch of code that uses the syntax of your previous control versions. When you remove a property like this, even if the method of reproducing the effect is straightforward (something I think is not true in this case), we still have to go through and change all that code in order to upgrade. Unless there is a very good reason to depracate a property, and I'm not quite sure you have provided one, I would think you would want to try and maintain it from version to version, just for upgradeability-sake.

[Erjan Gavalji]

Hi Albert,

I just wanted to follow this post up regarding the DisplayEnds property (I noticed Alex already helped removing the upper left hand corner border segmend).

Despite our efforts to make the things right from the very first time, it always happens that we miss a small thing or new requirements pop up. While developing RadToolBar for ASP.NET Ajax, we decided that we'll try to make the control cleaner and we will remove properties, which can be easily worked around. Such a property is the DisplayEnds one. I don't want to say that we disregard the backwards compatibility. Just the opposite - we always strive keeping it, but we decided that the move to the new framework used in RadControls ASP.NET Ajax was the right time to do this breaking change.

Finally I'd like to mention that it is our mistake to not add the workaround to the initial documentation, but we've fixed that and the service pack will have this information.

Kind regards,
Erjan Gavalji
the Telerik team

Instantly find answers to your questions at the new Telerik Support Center

[Albert Shenker]

As you said, this issue has been resolved and is working fine, however I feel that the concept, even when moving to a new framework, is not a sound one. Backwards compatibility aside, I think just leaving the solution to "workarounds" is a less-than-elegant way of going about things. The whole purpose of using control suites, and Telerik makes particularly nice ones, is to encapsulate functionality. Surely there is a "workaround" to do just about anything. But for developers, it is almost always an easier and cleaner process to just set a property. This thread is a good example. After a few back and forth messages, we have figured out how to set a handful of custom classes to obtain the desired effect. So, now I have to define these custom classes somewhere. If I decide to use a different skin in another implementation, or heaven forbid try to change skins, then I have to define a separate set of custom classes, which apparently don't even have the same structure. What happens the next time there is a major update to this control, or if you decide to change your skins like you have on other controls? Will the existing solution continue to work? All in all, if I could just set a property, like DisplayEnds=False, and let you guys worry abbout what is going on underneath the hood, that seems like a far better approach from the developer's point of view. You obviously can't have a property for ever single permutation of appearance or functionality that perople might want. I don't think the DisplayEnds example is one that falls into the category of being peripheral. It seems like pretty basic functionality and it made sense to have a property.

[Erjan Gavalji]

Hi Albert,

Thanks for sharing your opinion with us.

The fact is that we haven't received other complaints about that particular property, which makes me believe we've taken the right approach. We just don't want to keep the control simple and have its properties target its main functionality.

Here is an example of a simple scenario: It could be a nice idea to expose a complex property (e.g. Appearance) that can contain some important appearance-related sub-properties. On the other hand, such a property would increase the complexity of the control in terms of quick operation and code volume (the embedded JavaScript code could become needlessly large). We just have to take into account all the aspects of a change.

Regards,
Erjan Gavalji
the Telerik team

Instantly find answers to your questions at the new Telerik Support Center

[Blaize]

Hey guys, would you post the workaround for the upper left corner image with the Office2007 skin?

Just wanted to vote for simplicity - the KISS rule rules :).

Thanks in advance,
Blaize

[Albert Shenker]

Well, I think you always have to balance functionality with performance. If you guys determine that particular piece of functionality would hinder the performance of a control, then I'm not going to debate your decision not to encapsulate the functionality. In this particular case, if you never had a DisaplyEnds property, I would not be clamoring for you to create one. However, having had the property, depracting it becomes more of an issue. On the other hand, I do appreciate the efforts you have made to find the work-arounds.