United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-4926566 The embedded frame classes do not implement setLocation
JDK-4926566 : The embedded frame classes do not implement setLocation

Details
Type:
Bug
Submit Date:
2003-09-23
Status:
Resolved
Updated Date:
2003-12-18
Project Name:
JDK
Resolved Date:
2003-12-18
Component:
client-libs
OS:
linux
Sub-Component:
java.awt
CPU:
x86
Priority:
P2
Resolution:
Fixed
Affected Versions:
1.4.2_01
Fixed Versions:
5.0 (b32)

Related Reports

Sub Tasks

Description
When embedding a Java frame into system windows, using e.g. sun.awt.windows.WEmbeddedFrame or sun.awt.motif.MEmbeddedFrame, the resulting container can be sized, but not moved. That is, setPosSize() changes only the size of the embedded frame, not the position. And setLocation() does nothing at all.
###@###.### 2003-09-23

                                    

Comments
SUGGESTED FIX

To not break existing code, I would propose a new set of classes in the sun.awt.* namespace, which copy the behaviour of the original embedded frame classes, only that those implement setLocation correctly.
###@###.### 2003-09-23
                                     
2003-09-23
EVALUATION


Name: dmR10075			Date: 10/04/2003


Do I understand correctly that you need to call this method from outside of EmbeddedFrame(on its instace)
and when you know actuall class of the embedded frame(MEmbeddedFrame, for ex.)?
For backward compatibility I think we should create a protected method so that descendants are able to 
make public method for changing location. I don't think changing setLocation is safe since the applet run 
inside the frame might call setLocation. On other side, setLocation already works well in AppletViewer.

BTW, what is setPosSize method you mention? I don't see such a method in our code.

I tried to make necessary changes to XAWT to allow setLocation for EmbeddedFrame but it doesn't work
in Mozilla due to some reason. It looks like it bounces us back to the same location/size as we were initially.
And after that EF reports very strange size/location in Java. So it seems that solution should be made 
specifically for the case of embedding into StarOffice, and later it might be extended to other cases.

Do you have a test we can use to work on the fix?
###@###.### 2003-10-4



======================================================================

Name: tb120290			Date: 10/08/2003

Yes, that's correct. A protected method will do for us, only that we need it also on WEmbeddedFrame. Sorry for the setPosSize confusion, meant setBounds (we've a setPosSize at an awt::XWindow, thus the error). Regarding a testcase: that will get rather involved, because one would need a full developer build of StarOffice. If you _really_ need one, I could mock something up, but this will of course require some effort on my side.
###@###.### 2003-10-08

Ok, I have created a pretty decent testcase for this. Also I took out the code
from XAWT that prevents the location from being set for EmbeddedFrame. But I
suspect that this is not possible on Motif without causing a few regressions.
See 4652685 and 4419207. The testcase I have works great with XAWT. So It might
be that we can only fix this with XAWT. I also need to test on Windows.

###@###.### 2003-11-03

I tested the setLocation on windows as well, it works well on windows as well.
I am attaching the testcases.
 
###@###.### 2003-11-05

Informed submitter that the bug can only be fixed on XAWT and Win32. They are OK with it.

###@###.### 2003-11-26
                                     
2003-11-05
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
tiger-beta

FIXED IN:
tiger-beta

INTEGRATED IN:
tiger-b32
tiger-beta


                                     
2004-09-17



Hardware and Software, Engineered to Work Together