When setFont(font) is called on a MenuBar item, the font does not change.

The customer supplied a test case to demonstrate the problem.  The 
application allows the user to change the font type or font size.  Upon
changing the font, an event occurs which causes a call to the 
setMenuBarFont( Font font ) method.  This method iterates through the
MenuBar calling setFont(font) on each menu and menu item.  However, the
font change does not occur.

The change can be forced by removing the MenuBar and then re-adding it,
which the method forceMenuFontChange() does.  Run the application with and
without the command-line option "FORCE" to see the difference.  This
workaround is not an acceptable solution however, because it causes an
undesirable side-effect as described in BugId 4028130.

=================================================
[another user.    xxxxx@xxxxx   1997-11-21]

Windows 95 allows the user to specify the default
font. Sun's AWT doesn't honor this choice. Menus
appear in the same font regardless of the user's
choice of fonts.

Remove the MenuBar and then re-add it.  This forces the change to occur.
See the method forceMenuFontChange().

setFont call doesn't actually result in call to peer. Instead setFont in MenuComponent (and Component) merely sets a member variable. If the peer is created at this point the call has no visible effect unless the peer is recreated.
======================
On Win32 at least, it seems the menu font can be change on the fly since all the menus are owner-drawn. If this works in Motif as well, then perhaps setFont could be changed to call the peer. The real problem, is that none of the Menu peer interfaces have setFont methods right now, and it would be difficult to add it at this point.

  xxxxx@xxxxx   1998-02-11

06/25/1999   xxxxx@xxxxx  : This bug is fixed on Sun4 Solaris 2.6 as of JDK 1.1.8. But the bug is reproducible on Win NT 4.0 SP4 with JDK 1.1.8 and JDK 1.2.2. The fix for this bug under Windows seems to be fairly important.


Committing to Merlin - high CQI value.  
  xxxxx@xxxxx   2000-01-31




When a menu item decides which font to use, it first attempts to retrieve the
proper field font (java.awt.MenuComponent) instead of calling getFont().  The
difference is that getFont() retrieves valid font from its parent (MenuBar),
and the field font of course doesn't.  But we can't directly call this method
from native code (because it is non-final public so it could be overridden), so
we should call getFont_NoClientCall() isntead.

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

I see the same problem in TextArea. I was writing a simple word 
processor. I was going to let the user change the font type/style/size 
for the whole document (not as cool as per paragraph, word, or 
character, but that's  a lot more work :-). When I call setFont() on 
the TextArea, there is no update. I understand that this is because there is 
no call to the peer. It would be nice if there was. It's misleading to see 
the call in the API but then realize it doesn't work after construction.

I also see the same problem in frame.