Please note that the code you pasted does not contain the functionality I showed in my previous post - for example - the window.resize event is not handled at all.
The basic functionality of the RadWIndow can be controlled via its server-side properties, and the only compulsory JavaScript is the show() method.
#APPCODE FOLDER IN ASP.NET FULL#
I am not sure what you mean under internal and external JavaScript, but our controls can be used with little JavaScript as well as by utilizing their full capabilities via writing a lot of script. I hope you will find it easy enough to implement with my sample. This is also one of its main advantages over the standards ASP controls - it offers a rich client-side api that allows you to control it without a postback - less network delay and less server load.įor your convenience I created and attached a simple example of resizing the RadWindow to a percentage of the browser's viewport. As for the setActive - this method is related to other RadWindows, not to the controls from ACT.Īs for the JavaScript - I am sorry that you feel this way, but this is the way RadWindow works - it is purely a client-side object and thus is manipulated via JavaScript. Regardless of the cause of the behavior you describe without examining it I cannot say what the reason might be. I am still thinking that somehow the RadWIndow's initial z-index might be incorrect. This means that a RadWindow with the correct z-index should popup above them. Please compare it with yours and try to locate any major differences that may be causing this.What I see is that the AjaxControlToolkit's modal popup extender has a z-index value of 10001 and its modal background - 10000. I tested this with the latest AjaxControlToolkit dll and I was not able to see this behavior. do your other controls also involve so much external Javascript? Now I know some developers will think that I should be getting more involved with all that stuff - but I'm in a very small company wearing several different web hats with tight deadlines - I can't do everything :) - the simpler you can make your controls to use the better as far as I'm concerned i.e. I was hoping for a control that would largely hide all this Javascript from view for me. Unfortunately I don't have time to go in to all of that now (deadline to meet so will leave it out for now.) - is there any way of incorporating that as a control property that you can set in future editions of Radwindow? It's a good control but, from my deadline/time perspective I have spent alot of time getting in to additional Javascript stuff which I prefer to avoid, as it's not really my area. Secondly thanks for the info on resizing the Radwindow as a percentage of the browser window. You may find useful our jQuery, the pageLoad() function and our static library's getViewPortSize() function. What you can do is attach to the window's resize event, get the viewport size and use the RadWindow's client-side api to resize it accordingly. It is not designed to fit it in the browser's viewport. The AutoSize property is designed to size the RadWindow according to its contents (well, they need to have some dimensions set, if they don't the RadWindow will quite often become as tall as the screen as there is no way to calculate the size of the content). Generally the RadWindow gets a very high z-index when maximized, this can be controlled via the ShowOnTopWhenMazimized property (true by default).Īs for the percentage - the RadWindow controls does not support the scenario where its size is set in percent, it requires pixels.
Once you know the values you can modify them accordingly (at least for the RadWIndow). You can easily verify if this is the case by using a tool like FIrebug for FF or the IE Dev toolbar. If this is the case the most probable reason for this behavior is that the ACT's modal popup has an even higher z-index. I would also advise checking if the RadWindow will hide behind the ACT's modal popup if simply moved, without being maximized.
This means that it will have the default z-index of 3000. What I see is that the RadWindowPreviewSite RadWIndow is not in the RadWindowManager that has the high z-index set.
0 kommentar(er)
