Debbie Roberts
Top achievements
Rank 1
Debbie Roberts
asked on 12 Apr 2010, 03:07 PM
Hi Telerik,
I wonder if there is a way to achieve this. I currently use the PageTop EditorToolbarMode but sometimes on narrower screen resolutions the toolbar buttons split over several rows and this obscures the form elements on the page, making them uneditable.
I would like to either:
1) Implement a button on the toolbar that when clicked would toggle the toolbar mode from PageTop to PageBottom, or vice versa.
2) Dynamically change the relative position of the toolbar relative to the viewport via javascript/jquery, so that I can position the toolbar anywhere within the viewport and have it remain at that position in the viewport whilst the user scrolls.
3) Alternatively, I would like to be able to enable the 'Telerik.Web.UI.WindowBehaviors.Move' behaviour for the editor toolbar window, so that it can be moved by drag-and-drop.
I prefer the PageTop toolbar mode, as the toolbar remains fixed in its position relative to the viewport, which makes it easier for the user to edit longer blocks of text, rather than your other existing toolbar modes.
Debbie
I wonder if there is a way to achieve this. I currently use the PageTop EditorToolbarMode but sometimes on narrower screen resolutions the toolbar buttons split over several rows and this obscures the form elements on the page, making them uneditable.
I would like to either:
1) Implement a button on the toolbar that when clicked would toggle the toolbar mode from PageTop to PageBottom, or vice versa.
2) Dynamically change the relative position of the toolbar relative to the viewport via javascript/jquery, so that I can position the toolbar anywhere within the viewport and have it remain at that position in the viewport whilst the user scrolls.
3) Alternatively, I would like to be able to enable the 'Telerik.Web.UI.WindowBehaviors.Move' behaviour for the editor toolbar window, so that it can be moved by drag-and-drop.
I prefer the PageTop toolbar mode, as the toolbar remains fixed in its position relative to the viewport, which makes it easier for the user to edit longer blocks of text, rather than your other existing toolbar modes.
Debbie
5 Answers, 1 is accepted
0
Hi Debbie,
Thank you for the very interesting suggestions on improving the RadEditor toolbar functionality.
The requested features are not supported by RadEditor but I logged them in our PITS system for future consideration. I also updated your Telerik points.
Please, note that the addition of extra code for new toolbar features could decrease the loading of the toolbar and the end users could start to complain about this.
For the time being only the Floating toolbar could be moved around the page and it looks much suitable for your scenario.
Another approach is to render the toolbar in a DIV element placed on the desired page location. For your convenience I have attached a demo page here.
Sincerely,
Rumen
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.
Thank you for the very interesting suggestions on improving the RadEditor toolbar functionality.
The requested features are not supported by RadEditor but I logged them in our PITS system for future consideration. I also updated your Telerik points.
Please, note that the addition of extra code for new toolbar features could decrease the loading of the toolbar and the end users could start to complain about this.
For the time being only the Floating toolbar could be moved around the page and it looks much suitable for your scenario.
Another approach is to render the toolbar in a DIV element placed on the desired page location. For your convenience I have attached a demo page here.
Sincerely,
Rumen
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
Debbie Roberts
Top achievements
Rank 1
answered on 16 Apr 2010, 04:28 PM
Hi Rumen,
Many thanks for your demo. Rendering the toolbar in a DIV is perfect. It works really well and makes it looks much better too.
Regarding your other points about the toolbar modes:
1) PageTop is the only toolbar mode that you have which is stabilised within the viewport. I cannot see any reason why anyone would want a toolbar that is not fixed within the viewport, as this makes it very annoying when the user scrolls to edit some text lower down in the page and the toolbar disappears and has to be dragged down manually.
2) It would be better if you combined the PageTop, Floating and ShowOnFocus toolbars into a single toolbar that was fixed within the viewport.
3) You could then provide properties on this toolbar mode to allow it to be draggable or not, always on or show on focus, etc.
4) Could you not make the Toolbar itself a separate control (or controls), rather than bundling with the editor control, as in most cases where multiple editors are used on a page it would make sense to add just a single Toolbar control to the page and then associate the control with the editors? This would allow perhaps different controls to be used for different kinds of toolbar and thus improve the page loading time.
5) The pagetop toolbar is currently positioned using javascript, rather than CSS (position: fixed) in modern browsers. This makes it very jerky when scrolling. Could you use position: fixed in modern browsers to prevent this?
6) On narrower screen resolutions, your other toolbar modes (except pagetop) cause the toolbar to go outside the viewport when editing in the right-hand column of the page. This is very unhelpful to the user. Also, scrolling takes it out of the viewport.
Debbie
Many thanks for your demo. Rendering the toolbar in a DIV is perfect. It works really well and makes it looks much better too.
Regarding your other points about the toolbar modes:
1) PageTop is the only toolbar mode that you have which is stabilised within the viewport. I cannot see any reason why anyone would want a toolbar that is not fixed within the viewport, as this makes it very annoying when the user scrolls to edit some text lower down in the page and the toolbar disappears and has to be dragged down manually.
2) It would be better if you combined the PageTop, Floating and ShowOnFocus toolbars into a single toolbar that was fixed within the viewport.
3) You could then provide properties on this toolbar mode to allow it to be draggable or not, always on or show on focus, etc.
4) Could you not make the Toolbar itself a separate control (or controls), rather than bundling with the editor control, as in most cases where multiple editors are used on a page it would make sense to add just a single Toolbar control to the page and then associate the control with the editors? This would allow perhaps different controls to be used for different kinds of toolbar and thus improve the page loading time.
5) The pagetop toolbar is currently positioned using javascript, rather than CSS (position: fixed) in modern browsers. This makes it very jerky when scrolling. Could you use position: fixed in modern browsers to prevent this?
6) On narrower screen resolutions, your other toolbar modes (except pagetop) cause the toolbar to go outside the viewport when editing in the right-hand column of the page. This is very unhelpful to the user. Also, scrolling takes it out of the viewport.
Debbie
0
Hi Debbie,
The floating toolbar has a Pin button so it is shifted when the page is scrolled. The ShowOnFocus toolbar could be programmatically pinned as well.
In addition, when the ToolProviderID property is set the child editors will use the toolbar of the first one editor, so a separate toolbar control is not needed.
Best regards,
Rumen
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.
The floating toolbar has a Pin button so it is shifted when the page is scrolled. The ShowOnFocus toolbar could be programmatically pinned as well.
In addition, when the ToolProviderID property is set the child editors will use the toolbar of the first one editor, so a separate toolbar control is not needed.
Best regards,
Rumen
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
Debbie Roberts
Top achievements
Rank 1
answered on 23 Apr 2010, 04:21 PM
Hi Rumen,
Many thanks for your help and suggestions in particular for your demo page of April 13th.
I have been trying to use your suggestion in conjunction with the single toolbar for multiple editors (ToolProviderID) and it does not work. Although, it works perfectly in the scenario where each editor on the page has its own toolbar and also in the scenario where only one radeditor is used to edit multiple editable areas by moving the radeditor within the DOM.
I find that the 'window show' event does not trigger until the user clicks into the editor that provides the toolbar. If the user clicks first into an editor that only has a toolbar association, the 'show' handler does not run and the toolbar does not show.
Once the user has clicked into the editor that provides the toolbar, the show event does begin to trigger for the other editors. However, when the show event triggers the 'activeeditor' holds the incorrect value, so the oldToolbar gets lost. From then on, the toolbar is gone foreever.
Is there any way to detect whether the editor is the toolbar provider or not in this script, so that it can use either the activewindow or the actual window in this javascript as appropriate.
Debbie
Many thanks for your help and suggestions in particular for your demo page of April 13th.
I have been trying to use your suggestion in conjunction with the single toolbar for multiple editors (ToolProviderID) and it does not work. Although, it works perfectly in the scenario where each editor on the page has its own toolbar and also in the scenario where only one radeditor is used to edit multiple editable areas by moving the radeditor within the DOM.
I find that the 'window show' event does not trigger until the user clicks into the editor that provides the toolbar. If the user clicks first into an editor that only has a toolbar association, the 'show' handler does not run and the toolbar does not show.
Once the user has clicked into the editor that provides the toolbar, the show event does begin to trigger for the other editors. However, when the show event triggers the 'activeeditor' holds the incorrect value, so the oldToolbar gets lost. From then on, the toolbar is gone foreever.
Is there any way to detect whether the editor is the toolbar provider or not in this script, so that it can use either the activewindow or the actual window in this javascript as appropriate.
Debbie
0
Hi Debbie,
The provided solutions in the attached demo page in my post on April 13th as well as in this KB article: Setting hidden RadEditor in edit mode on click and putting it in non editable mode onblur do not support the ToolProviderID functionality.
If you would like you can configure the editors to use a single toolsfile by setting their ToolsFile property to point to this xml file. You can download the Default toolsfile of RadEditor from this KB article: http://www.telerik.com/support/kb/aspnet-ajax/editor/default-toolsfile-xml-file.aspx
Kind regards,
Rumen
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.
The provided solutions in the attached demo page in my post on April 13th as well as in this KB article: Setting hidden RadEditor in edit mode on click and putting it in non editable mode onblur do not support the ToolProviderID functionality.
If you would like you can configure the editors to use a single toolsfile by setting their ToolsFile property to point to this xml file. You can download the Default toolsfile of RadEditor from this KB article: http://www.telerik.com/support/kb/aspnet-ajax/editor/default-toolsfile-xml-file.aspx
Kind regards,
Rumen
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.