vertical scrolling with RadToolBarDropDown

[Francisco]

Hello,

How do I add the support for vertical scrolling of the dropdown menu to RadToolBarDropDown like you have in your RadMenu component?

Regards.

[Veselin Vasilev]

Hello Francisco,

RadToolBar does not support scrolling as RadMenu does. To get the standard vertical scroll you need to set the DropDownHeight property of the RadToolBarDropDown or RadToolBarSplitButton.

Best wishes,
Veselin Vasilev
the Telerik team

Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.

[Francisco]

Thanks for the quick answer.

I implemented your suggestion but it was not acceptable to my client.

We really like the RadToolBar.  We also really like the way the RadMenu handles scrolling (as opposed to the scrollbar way the RadToolBarDropDown handles scrolling).

Any other suggestions?  Has anyone tried placing a control on top of an empty area of the toolbar so that the control appears to be part of the toolbar?
Or how about right beside the toolbar so that the new control looks like its part of the toolbar.  Do you have any previous examples of this?  Unfortunately I am not a css pro so any hints/samples you have would be very much appreciated.

Regards,
Francisco

[Atanas Korchev]

Hi Francisco,

You may consider adding RadMenu inside a button template as demonstrated in this example.

Greetings,
Albert
the Telerik team

Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.

[Joseph Bonanno]

Hello-

I've added DropDownHeight as specified above, but it does nothing, it doesnt set the height at all:

<telerik:RadToolBar ID="m_UIPageToolbar"
                  runat="server"
                  SkinID="PageToolbar"
                  EnableViewState="true"
                  OnClientButtonClicking="OnToolBarButtonClicking">
                  <Items>
                      <telerik:RadToolBarDropDown DropDownHeight="200px" ></telerik:RadToolBarDropDown>
                  </Items>
            </telerik:RadToolBar>

I found that by defining a height on the div.RadToolbarDropDown class I could set the height, but I am not getting any scrolling. I defined an Overflow: scroll; property on the class but that does nothing as well.

div.RadToolBarDropDown
{
      border-color: #6788be;
      background-color: #fff;
      background-image: url('ToolBar/rtbDropDownBg.png');
      background-position: -1px 0;
      height: 300px;
      overflow:scroll;
}

Any suggestions on getting this menu to scroll?

[Kate]

Hi Joseph,

You can set the DropDownHeight property in the following way:

<telerik:RadToolBar ID="RadToolBar1" runat="server">
      <Items>

          <telerik:RadToolBarDropDown runat="server" Text="DropDown 0"  DropDownHeight="40px">
              <Buttons>
                  <telerik:RadToolBarButton runat="server" Text="Child Button 1">
                  </telerik:RadToolBarButton>
                  <telerik:RadToolBarButton runat="server" Text="Child Button 2">
                  </telerik:RadToolBarButton>
                  <telerik:RadToolBarButton runat="server" Text="Child Button 3">
                  </telerik:RadToolBarButton>
                  <telerik:RadToolBarButton runat="server" Text="Child Button 4">
                  </telerik:RadToolBarButton>
                  <telerik:RadToolBarButton runat="server" Text="Child Button 5">
                  </telerik:RadToolBarButton>
                  <telerik:RadToolBarButton runat="server" Text="Child Button 6">
                  </telerik:RadToolBarButton>
              </Buttons>
          </telerik:RadToolBarDropDown>

      </Items>
  </telerik:RadToolBar>

All the best,
Kate
the Telerik team

[Albert Shenker]

Why must one set a "DropdownHeight" property in any of your controls in order to get scrollbars to appear appropriately? There is no DropDownHeight property in RadComboBox.. your original dropdown control. So why was this property created for other controls that include dropdowns... RadToolBarDropDown, AutoCompleteBox, etc? If a user really wants to limit the height of a dropdown, one can maybe justify having this property. But I think in the VAST majority of cases, users want their dropdowns to fill whatever vertical space is available and display scrollbars when there is insufficient spaces. This is not apparently possible with RadToolBarDropDown.

I suppose its only been 6 1/2 years since this particular issue was brought up.

[Plamen]

Hi,

The DropDownHeight property was desired by lots of customers and that is why we have added it in the controls. As for the exact scenario that is not supported by RadToolBarDropDown I would recommend you to submit a feature request in our feedback portal about it so we consider its implementation.

Regards,
Plamen
Telerik

[Albert Shenker]

I'm getting kind of tired of the whole "submit a feature request in our feedback portal, and we'll consider it" line. Do you guys have it on some sort of keyboard shortcut?

I'm a consultant. When you guys start paying me my hourly rate, then maybe I'll spend more time in your feedback portal - the place where, as far as I can tell, ideas and productivity go to die.  But until then, I'm perfectly fine pointing out how you're screwing up in forums and tickets. This issue was brought to Telerik's attention 6 1/2 years ago. It is not some pie-in-the sky, complicated feature request which requires significant internal debate. It is a simple behavior that is common to all controls with drop-down elements. And it certainly exists in your other dropdown-related controls - RadComboBox and RadMenu. Maybe someone might have thought about taking a look at the functionality of those controls before developing a dropdown control for RadToolbar. That just seems logical. But what do I know?

Anyhow, regardless of the reason why this feature was omitted from RadToolbarDropdown - and that's exactly what it is, a glaring omission - if the quality of your underlying code is even half-decent, the problem would not be hard for you to fix. But alas, this issue is just one in an ever-growing number of examples of Telerik's ASP.NET Ajax development ​resources lacking the numbers, communication infrastructure or quality control processes in order to truly "Deliver more than expected". At this point, the thing I expect most from Telerik is you will deliver products with bugs and or glaring functionality omissions and then spend years sitting on your hands or developing large, complicated development platforms to make you marketing department happy until some magical number of developers complain enough in your "feedback portal".

As far as I'm concerned, that's nothing more than abuse of your install-base. Maybe you can survive, or even flourish doing that for a while in an industry with high switching costs. But people will eventually catch on. They always do. You guys need to seriously re-think how you manage you ASP.NET Ajax products. I was hoping things would change with the Progress merger. But the continued tendency to sweep things under the rug tells me nothing has really changed.

[Nencho]

Hello Albert,

I am sorry to see how you feel about the feedback portal, where the new features are submitted and revised. However, I have to assure you that we are closely revising them and consider whether they should be implemented.

There are numerous criteria that one feature request should meet before its implementation - like will it be helpful for a large amount of the scenarios where the control is used, or is there a possibility to break some other features of the controls and so on.

In addition, the requests are prioritized using the voting feature, in order to get some additional information on the amount of scenarios that such functionality can cover - not to determine whether to implement them at all.

As for your frustration about the bugs with our products - I am sure that you would agree that each software have some and ours is no exception. However, we are constantly improving and fixing the issues, not only regarding the newly released browser versions but with regarding functionality of the controls as well. This fact could be verified with a simple revision of our release history below:

http://www.telerik.com/support/whats-new/aspnet-ajax/release-history

Once again, I would like to assure you that the feature request, submitted in the feedback portal are strictly revised, which is why I would like to encourage you to submit the one, which was previously discussed.

Regards,
Nencho
Telerik

[Albert Shenker]

Everything you have said notwithstanding, I will mention, once again that this issue was brought to your attention 6 1/2 years ago. This particular issue doesn't represent a bug. It is an oversight on the part of your team. Things like this should not require customer feedback portals and extensive internal debate. All that is necessary is the realization that the control is deficient. This functionality should have been implemented when the toolbardrowdown was first released since it is the natural behavior of all dropdown-like controls. But it wasn't. And now, 6 1/2 years later, it still isn't.

If this were the only example of such oversights and apparent reluctance and/or inability to remedy them, I wouldn't be so frustrated. But this is not the only example. And they appear to be growing in number.

[Nencho]

Hello Albert,

As previously mentioned we are prioritizing the feature requests or the logged bugs. This is why I want to point out again that the period of the logged items could be overlooked if there is something more important, critical or simply more requested that needs to be implemented. 

Regards,
Nencho
Telerik

[Albert Shenker]

I get it. Producing high quality, compatible and consistent controls is not a Telerik priority until such time as some magical number of people complain about something or your marketing department takes a break from diverting resources towards the latest techno-fad enterprise product.

With all the growth ​Telerik has experienced in the last 5 years I would have thought that the quality of the ASP.NE​T Ajax controls suite would improve. Alas, it looks like that growth has benefitted some other segment of your company. Because it seems like as your install-base and code-base size have increased, the resources you have to managing it have not kept pace... hence the incomplete product/feature releases and hesitance to remedy them.

[Marin Bratanov]

Hello Albert,

As we have discussed before, implementing a feature depends on many factors and its impact is one of the most important. Even if a request is brought up, we cannot guarantee we will implement it, because there are many requests that are sought after by more people.

I must also point out that the fact that one control has a certain feature (the screen boundary detection of the ComboBox for example) does not mean that all controls must have that feature. Often simplicity has more value than a new property that can be replaced with a bit of CSS or JS.

To get back to the opening case, we have provided a template where you can put a menu and get the desired behavior. This means that we do not need to make the toolbar more complex by adding unnecessary properties that will have very little impact.

As for improving the suite

• we have fixed a huge number of issues in the last year that have had a lot of impact on our customers, even if you have not encountered one of them yourself. This is where a feedback system helps immensely - fixing an issue reported by a dozen people will have much more impact than a request supported by one or two. We appreciate all feedback and it is really important in setting priorities, especially for bug fixes.
• to be concrete, our bug backlog has been reduced by 50% this last year.
• in the last year we have added 7 new controls (wizard, tree map, progress bar, data form, navigation, clientexportmanager, spreadsheet) and I would add the mobile editor that that list as well, because it is huge. I am not even counting the myriad of new features we have added as well.

All that being said, I cannot agree that we do not invest resources and improve the UI for ASP.NET AJAX suite.

Regards,

Marin Bratanov
Telerik

[Albert Shenker]

I don't know where to start, Marin. I like you. I have read your blog posts before. But your comments here do not help the issue at hand, nor do they reduce my frustration.

First off, for some reason you and Nencho are harping on a single thing I said regarding buggy code and are spending a great deal of time defending it. For the record, I am a software developer. I am familiar with bugs and am aware that having them is not some sort of sign of complete incompetence. But mentioning how much time and resources you guys spend fixing bugs is not an indicator of quality. Quite the opposite, in fact. That being said, I'm glad you guys are striving to and, apparently, succeeding in improving the quality of your code

 As for the crux of the matter with regards to this thread, I have to take issue with your statement:

"I must also point out that the fact that one control has a certain feature (the screen boundary detection of the ComboBox for example) does not mean that all controls must have that feature. Often simplicity has more value than a new property that can be replaced with a bit of CSS or JS."

This statement makes absolutely no sense. All dropdown controls should have screen-boundary detection. If that isn't the case, why would you have implemented it in the first place with RadCombobox? Surely that didn't make things "simpler" for you. So, Telerik either doesn't have the technical competence to implement this feature in their other dropdown controls, or they lack the resources to do so. The former is obviously not true, since the feature does exist in other Telerik controls. But for some reason, even after 6 1/2 years, it still does not in RadtoolbarDropdown.

Furthermore, the original responses to this thread were not suggestions on how to implement some javascript or css to serve as a temporary hack while Telerik figures out whether they want to bother implementing the feature. Instead the responses were of the form... that feature doesn't exist.. here's some lame excuse why we didn't implement it... why don't you try a different control. That sort of attitude, and the ubiquitous suggestion your users should submit something in the feedback portal (in essence, go jump in a lake), are what lead to frustration.

 

So, if the official Teleirk stance on this issue is... you should use Rad Menu in a toolbar template, then maybe you guys ​ought to deprecate the RadToolBarDropdown altogether. I mean, what other purpose does it serve? In addition to the screen boundary detection, its also missing a FindItemByValue method, which, again, seems like a glaring omission for a dropdowncontrol. Though I guess after 7 years, it looks like that feature will finally be implemented in the upcoming release...

http://www.telerik.com/forums/radtoolbardropdown-selected-value#oyl5ucNIYkWr3cYaJtBUxQ

Is that the typical turn-around time we should expect for the RadToolbar control?

Lastly, I'm not sure why you feel the need to list the various controls Telerik has released recently. Shear numbers impress no one, but perhaps somebody in marketing. If controls are released with bugs or have incomplete features, it may actually be worse than if they were not released at all. I'm not saying that is the case with the controls you mentioned. But if the pattern holds, it very well might be.

 

 

 

 

 

 

[Marin Bratanov]

Hello Albert,

Let me expand on the feature parity between controls:

• The screen boundary detection is there in the combo box because there has been great demand for it. This is not so with the dropdowns in the toolbar - they are designed for simpler use cases and thus, people have not felt the need to have all the features from the combo box.
• A second reason is simply performance - RadComboBox loads over a megabyte of scripts. It does not make sense to add to the toolbar's scripts much code that will rarely be used. In case complex functionality is needed, the templates are available and the developer can put a combo box there.
• When demand builds up, we implement features according to the impact they have. Implementing FindItemByValue method is not certain at this point. Its status is Approved, but it is not scheduled for a concrete release yet. Once we are certain, the portal page will be updated. I realise this is not what you want to hear right now, but it is the naked truth.

As for typical turnaround times - there is no exact figure that can be provided. Each case is reviewed by itself according to its value and some ideas may be implemented in much shorter timeframes than others.

Usually, there is a way to achieve certain functionality even though it is not available in a control and even if we do not have immediate plans on adding it as a built-in feature. To this end, we try hard to offer ideas and options and it is our official stance that these suggestions are valid approaches and that we cannot promise that we will implement every request we receive. A general rule of thumb is that the easier solution/workaround is available, the less likely it is to become a built-in feature.
 

Regards,

Marin Bratanov
Telerik