Community
Participate
Working Groups
I20060321-1210. I started to use the new JFace Dialog support that manages location and size. The problem I run into is that it does not reset the size when the font changes, which makes the dialog look ugly and forces the user to manually adjust/reset the size, which is not an easy task, see also bug 116906.
marking for 3.2 polish
I've got a proposed fix for this, but would like comments from the cc list about the proposal. The issue is that if dialog bounds were stored under a particular dialog font, then the bounds are potentially bogus when the dialog font changes. The proposal is to do the following: - store the font data string of the font used when the bounds were stored, along with the bounds - when a dialog bounds is retrieved: a) if there was no previously stored dialog font, honor the bounds (to retain settings for those who saved the bounds before this fix) b) if there was a previously stored dialog font, and it matches, honor the bounds c) if there was a previously stored dialog font, and it does not match, then do not retrieve the previously stored size. However, the previously stored location will be honored, because it will always be checked and adjusted if it no longer fits on the screen. By preserving the location, we can come closer to remembering the correct location, which is especially important to multi-display users. The downside: - dialog font changes that don't cause ugly/improper layout will still cause the stored bounds to be lost. For example, if the user purposely sizes a dialog to be very large, and subsequently changes the font to be smaller or larger, the dialog will shrink to its default size even though the larger size was still valid for that user.
That suggestion makes sense to me. I'm wondering if the same applies for location: If you detect that screen size, or number of monitors change, do you ignore the stored location? (I think that would make sense)
+1
The location for dialogs is always honored, but it gets adjusted via the normal Window mechanisms. Also of importance is that the location is stored relative to the parent shell, so in a change of number of monitors, the "right thing" happens. This seems to accomodate the scenarios from bug #108801 and bug #33550 comment #15, so I don't see doing any extra work on identifying changes that affect location.
Fixed >20060420.
cc'ing McQ for FYI.
verified on N20060425-0010, Win XP using open resource dialog.
