Name: dmR10075 Date: 10/15/2002



Actually, examining the differences between embedded frame and normal frames it
can be seen that embedded frame doesn't have associated native AWT object. It
leads to a several known problems:

1) Embedded frame doesn't have "proxy focus owner" for owning windows so Window with
embedded frame as owner will behave ugly.
2) Modality doesn't work well with it - doesn't always take it into
account. Modality code in awt_Windows.cpp mostly works with HWNDs but
sometimes looks for associated AwtComponent objects. This won't work
for EmbeddedFrame (see 4276029)
3) toBack/toFront doesn't work well with it - doesn't always take it into account.
4) There might be some other situations which are currently not
obvious when EmbeddedFrame is different from Frame when it shouldn't.
I think we should reevaluate the amount of functionality EmbeddedFrame supports.

So far these problems didn't loudly manifest themselves though according to
specification(EmbeddedFrame - descendant of Frame) there are several bugs exist.

It seems that we either should add missing checks into existing code
taking into account that top-level window can be embedded frame or we
can create some native object, descendant of AwtFrame, and current
code should start to work well automatically.

I filed this bug as the union of these problems since they shouldn't be
fixed separately.

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