Definition of 'CenterScreen' in WindowStartupLocation?

[Stuart]

Greetings,

I believe that WindowStartupLocation.CenterScreen is implemented to center in the overall height of the page, not the center of either the current display or the visible host (browser) window. This is causing significant problems in our application.

Currently our application makes extensive use of RadWindow, including both Alert/Confirm/Prompt and window / modal window styles. For window / modal window, we have set to display in WindowStartupLocation.CenterScreen. I gather from a related forum post that the Alert/Confirm/Prompt dialogs use the same setting.

However, these dialogs are displayed in what appears to be the center of the page, not the screen as I think of it. I would expect the dialogs to be placed either in the center of the monitor or center of the browser window, not the page. This is a major issue for us as the height of our application is variable, and can be much taller than the visible browser window. As a result, a dialog may display somewhere off-screen based on some user interaction, and it may not be immediately obvious that the user needs to scroll in order to interact with the dialog.

I realize that I can write code to use WindowStartupLocation.Manual for RadWindow instances displayed using .Show() and .ShowDialog(), but that won't help us with the various Alert/Confirm/Prompt dialogs throughout our application.

Is this a known issue, and if so is there any action toward a resolution?

Sincerely,
Stuart Updegrave
Virtuoso, Ltd.
[using q1 2010]

[Miroslav Nedyalkov]

Hi Stuart,

 This behavior is by design - we decided that the default behavior of the window should be to center in the Silverlight application. Your request sounds reasonable, so we will consider adding this feature to the RadWindow control. I created a PITS item for this feature request. Its title is "Window should be able to center in visible area of the screen instead in the Silverligin (if possible).".

Kind regards,
Miroslav Nedyalkov
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.

[Stuart]

Hi Miroslav,

Thanks for the reply. An alternative solution would be to - at minimum - support setting WindowStartupLocation on dialog types. Even if set via style, WindowStartupLocation value appears to be ignored.

[Miroslav Nedyalkov]

Hello Stuart,

 The reason for this behavior is that the Alert method sets WindowStartupLocation explicitly and this overrides the style. What I could suggest you is to use the Opened event and to override the value of the Property.

Hope this helps!

Kind regards,
Miroslav Nedyalkov
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.

[Stuart]

Yes, it's obvious that .Alert(), .Confirm() and .Prompt() explicitly set WindowStartupLocation. I feel that this is the wrong thing to do - that instead this property should be exposed more easily, and then only explicitly set if not user-set.

Also, I realize that I can get a handle on the window using an Opened handler, but that results in the dialog being displayed, then moving to the newly-set location. This is an unfortunate user experience.

[Miroslav Nedyalkov]

Hello Stuart,

 Thank you for your feedback! We will consider fixing this behavior.

Best wishes,
Miroslav Nedyalkov
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.