Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 58095 - [Preferences] Selecting pref page moved dialog to other screen
Summary: [Preferences] Selecting pref page moved dialog to other screen
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.0   Edit
Hardware: Macintosh Mac OS X - Carbon (unsup.)
: P4 normal (vote)
Target Milestone: ---   Edit
Assignee: Stefan Xenos CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-04-11 05:24 EDT by Dylan Schell CLA
Modified: 2004-04-20 14:08 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dylan Schell CLA 2004-04-11 05:24:37 EDT
When I move the preferences dialog to my secondary screen and change a prefpage, the entire dialog 
moves back to my primary screen and "hugs" the right border of the main screen.
Comment 1 Tod Creasey CLA 2004-04-12 10:10:44 EDT
Looks like a standard multi monitor issue.

Stefan could you please try this on XP?
Comment 2 Tod Creasey CLA 2004-04-15 09:35:14 EDT
Stefan is this still an issue?
Comment 3 Dylan Schell CLA 2004-04-20 09:08:31 EDT
Maybe this wasn't entirely clear, since I only noticed this today, but the dialog only jumps back to the 
primary display if a pref page is selected that causes the pref dialog to reshape itself ( Which in itself is 
a rather unnerving experience since this also means the tree shifts location )
Comment 4 Stefan Xenos CLA 2004-04-20 14:03:56 EDT
Yes. This is still an issue.

1. If you've manually resized the preference dialog, this doesn't happen.
2. It only happens for preference pages that would cause the dialog to resize.

This seems to be an issue with Window.getConstrainedShellBounds... it tries to
force a dialog to be on the same monitor as its parent window. This was
originally intended to help correct badly-behaved dialogs that try to open on
the wrong monitor, but it is causing this bug as an unwanted side-effect.
Comment 5 Stefan Xenos CLA 2004-04-20 14:08:18 EDT
I've submitted a patch to Window that fixes this. 

getConstrainedShellBounds no longer forces dialogs onto the same monitor as
their parent. The default window location is still calculated for the correct
monitor, however subclasses that override the default location with a position
on the wrong monitor will need to be corrected.