Mislabeled menus
We're having menus showing incorrect labels with JRE 1.1.8.008, JRE 1.3.1, JRE 1.4.0beta, all for Windows (using Win Me). I've searched the bug database but found nothing like it (bug has just been reported). Has anyone seen the following, and know of a workaround?
About 3% of the menus in our AWT-based app are drawn mislabeled, showing the label of some menu item somewhere else within the menu bar (I'll call this incorrect label the "phantom label"). Occasionally as well the label of a menu item will be drawn just after the Help menu, although this extra name drawn does not represent an extra menu (it is not selectable, for example). This behavior is inconsistent; you can run the app several times, and each time it will be a different set of menus that are mislabeled, and each time the phantom label is taken from a different ("random"?) menu item somewhere else in the menu bar. The mislabeling doesn't look exactly like a regular label, for the phantom label is offset slightly to the right. Thus, for example, if the menu bar should appear like this:
FileEditWindowHelp
it might appear instead like this:
FileEditBlue Help
where "Blue" is the phantom label, from a menu item somewhere else in the menu bar. The "Blue" menu still behaves correctly, as the Window menu. I do not recall having seen the Help menu suffer phantom replacement, but every other menu seems susceptible.
Also, the width allocated for the label is correct for the true label, not for the phantom label. This causes long phantom labels to run past subsequent labels. Thus, if in the above example the phantom label had been "Activate Navigation" then you would see:
FileEditAct Help e Navigation
This is not the result of the menus being actually mislabeled. If, after building the menu bar, I ask our app to cycle through the menus using MenuBar.getMenu() and ask for each menu's label, it reports to System.out.println the correct label even while the phantom label is drawn in the window.
Our app is run as a standalone app started by an executable installed by InstallAnywhere. It uses AWT and almost no calls from JDK 1.2 (a bit of Java 2D is blended in).
I doubt that I can construct a simple piece of source that displays this behavior. Our app is big (>100,000 lines) and its construction of the menu bar is intimately tied to the rather large core architecture of the system. It may be downloaded from http://mesquiteproject.org (this is an old version, which also shows the same problem -- a new version with source is planned to be available 24 July 01). I'm happy to give instructions as to how to reproduce the problem.
Our app may be peculiar in its exuberant rebuilding of the menu bar: with changes in user choices, the appropriate menu items change, and for reasons tied to the system's architecture it is much more convenient (and far better from a performance point of view) for us to rebuild a new menu bar from scratch, and then substitute the old menu bar for the new menu bar. I wonder if our app is burdening some menu recycling system beyond what most apps do.
