8 Answers, 1 is accepted
In the current version of RadEditor, it is not possible to customize the size of the built-in dialogs because they are included in the Telerik.Web.UI.dll file.
Nevertheless, we plan for Q1 2008 release (due in April) of RadEditor "Prometheus" to provide external files for the built-in dialogs which will allow you to customize their appearance and dimensions.
Best regards,
Rumen
the Telerik team
Instantly find answers to your questions at the new Telerik Support Center
I actually want to reduce the size of some of the dialogs, as I use the editor mostly in popup windows. Some of the dialogs are far to large to use in popup windows as the quite often bigger the window itself.
Yes, in the RadEditor "Prometheus", scheduled for tomorrow, we will provide external files for the built-in dialogs (except the file browsers) which will allow their customization. We will provide later external files for the file browser dialogs.
Kind regards,
Rumen
the Telerik team
Instantly find answers to your questions at the new Telerik Support Center
http://www.telerik.com/community/forums/thread/b311D-baeehk.aspx
No answer on the other thread yet so I'll keep the dialog going here.
I've tried to wrap my head around another possible solution in hopes of finding one sooner. One of the issues I'm dealing with is the fact that I open the Image Manager using two different sources: 1) The editor itself, but also 2) Directly from a DialogOpener. There are times in both cases when the size of the Image/Document/* Manager is larger than that of the RadWindow in which it is opened, which causes the *Manager to be cropped by the RadWindow.
One of the solutions proposed in the other thread was for the Dialogs to check whether or not they are opened from the _top page, and adjust accordingly if they are not. This would require the top level page to be an aspx page, which, as stated in the other thread, may not always work (although it would in my case).
So then I thought, what if they RadWindow that opened the Image Manager was temporarily resized while the Dialog was open, and then returned to its original size when closed? Since this resize would only be slightly larger than what is needed for the Dialog, breaking the layout of the calling RadWindow page wouldn't matter since it's covered by the Dialog anyway. So, I started down that path, using the scenario where an Image Manager is opened directly using a DialogOpener:
Old JS:
function OpenImageManager() { $find('<%= DialogOpener1.ClientID %>').open('ImageManager'); }
function set_Image(sender, args) { var selImage = args.SelectedItem; get_ImageImg().src=selImage.getPath(); originalAttribute="src" originalPath="selImage.getPath();" get_ImageTxt().value = selImage.getPath(); }
New JS:function OpenImageManager() { set_SizeForDialog(); $find('<%= DialogOpener1.ClientID %>').open('ImageManager'); }
var oldH = null; var oldW = null;
function set_SizeForDialog() { var rw = get_RadWindow(); var h = rw.get_height(); var w = rw.get_width(); oldH = h; oldW = w; if (h < 540) { h = 540; } if (w < 740) { w = 740; } set_WindowSize(740,540); }
function set_Image(sender, args) { set_OriginalSize(); var selImage = args.SelectedItem; get_ImageImg().src=selImage.getPath(); originalAttribute="src" originalPath="selImage.getPath();" get_ImageTxt().value = selImage.getPath(); }
function set_OriginalSize() { set_WindowSize(oldW, oldH); }
The "set_WindowSize()" function is something I use to set the size of the window when it is first opened. It simply checks the size of the browser window first. You could use the set_Height() and set_Width() functions of the window object instead.
Needless to say, this works and works quite well if the user selects an image... BUT... There are other issues that I can't figure out. For instance, say the user opens the Image Manager; which therefore resizes the RadWindow (good). Then the user either clicks "cancel" or clicks the close button of the Dialog (silly user - why did you open it!). I can't find in the documentation anywhere a way to trigger the set_OriginalSize function upon the closing of the Dialog since the ClientCallbackFunction is only executed upon the user clicking the Insert button. So the dialog is closed but the RadWindow remains the wrong size. Darn!
My next step will be to see if I can use the OnClientCommandExecuting function of the RadEditor to trigger the set_SizeForDialog() function if one of the Dialogs is being opened. I'd imagine that it will work, but I don't know what's going to happen when the user closes the dialog without selecting something. Plus I'm not sure if the OnClientCommandExecuted function happens at the right time. I'll try that next and re-post my findings. For now I wanted to keep the dialog going on this since it has been a pain in my backside for about a year now.
My current solution is an ugly one - always making sure that the RadWindow is big enough to house a Dialog. Ugh!
In any case, the reason I post all this gibberish is to propose a possible solution to this problem which should hopefully be acceptable in all situations. If the Telerik guys could implement something like this in their Dialog Handler:
1) Is the opening frame a RadWindow? If yes, continue to #2, if no, then continue as normal.
2) Is the RadWindow big enough for the Dialog? If yes, continue as normal; if no, then resize the window, store the original size, and continue to #3.
3) For every possible way that the user can close the Dialog, first call the function that resizes the RadWindow back to its original size before continuing.
This makes more sense than to try to resize the dialog windows since they are pretty much all optimized for a specific size. Running this code in the dialog handler also makes it super easy to handle a wide variety of scenarios and dialog sizes.