JDK-6179142 : Should consider hierarchy changes for Print and File dialog windows peers
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 6,7
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • OS: windows,windows_xp,windows_7
  • CPU: generic,x86
  • Submitted: 2004-10-14
  • Updated: 2018-09-05
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Duplicate :  
JDK-6532709 - FileDialog appears at wrong location
Duplicate :  
JDK-6469731 - Windows: getLocationOnScreen throws NPE for a page dialog
Duplicate :  
JDK-6278099 - Native file, page and print dialogs can't be modal blocked on Windows
Relates :  
JDK-7009114 - GTK FileDialog lies about it's Bounds
Relates :  
JDK-6573321 - KFM 'activeWindow' property is not handled correctly for native dialogs, Windows
Description
For some reason WFileDialogPeer and WPrintDialogPeer extend WWindowPeer, 
but, in fact, they are not a real subclasses for it, because they don't
implement number of its methods and also don't have HWND associated with
this peer (they just show nativa dialogs).

This introduce the problem for maintanace because every time we change 
something in WWindowPeer or higher (e.g WComponentPeer) we should check if
such changes are applicable for these classes too (usually they are not).

Perhaps we should change our hierarchy so these classes do not extend WWindowPeer,
but implement appropriate peer interfaces.
###@###.### 10/14/04 13:20 GMT
Comments
EVALUATION One more feature missing for file/print dialogs is described in 6278099.
01-07-2011
EVALUATION The real source of the problem is that WFile/PrintDialogPeer doesn't have any native counterpart as other regular peers (WComponentPeer, WButtonPeer, WWindowPeer, etc.) have. That's why we have to override most of the file/print dialog method to be just no-op to avoid "null pData" exception. Instead of changing the hiearchy, it makes much more sense to introduce the native objects for file/print dialogs. This will allow us to implement the peer interface correctly, including: - setting and querying window bounds - enabling/disabling windows - changing window z-order (including setting it always-on-top) - applying various effects (opacity, shape) - etc. Not everything of above is really useful for native dialogs, but at least the dialog size/location seem to be of high interest, for example, for testing purpose.
24-02-2011