Definition of 'CenterScreen' in WindowStartupLocation?

6 posts, 0 answers
  1. Stuart
    Stuart avatar
    12 posts
    Member since:
    Feb 2009

    Posted 07 Apr 2010 Link to this post

    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]
  2. Miroslav Nedyalkov
    Admin
    Miroslav Nedyalkov avatar
    1718 posts

    Posted 08 Apr 2010 Link to this post

    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.
  3. DevCraft banner
  4. Stuart
    Stuart avatar
    12 posts
    Member since:
    Feb 2009

    Posted 08 Apr 2010 Link to this post

    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.
  5. Miroslav Nedyalkov
    Admin
    Miroslav Nedyalkov avatar
    1718 posts

    Posted 12 Apr 2010 Link to this post

    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.
  6. Stuart
    Stuart avatar
    12 posts
    Member since:
    Feb 2009

    Posted 12 Apr 2010 Link to this post

    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.

  7. Miroslav Nedyalkov
    Admin
    Miroslav Nedyalkov avatar
    1718 posts

    Posted 13 Apr 2010 Link to this post

    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.
Back to Top
DevCraft banner