-
Notifications
You must be signed in to change notification settings - Fork 188
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inconsistent display of menu tooltips #2483
Comments
Indeed. The miniscule, should-be-irrelevant, difference is the separator in:
Once M3 is out I should be able to post a repro that avoids project GIT repos or bad XML. |
In a debug launch, it worked correctly for the text editor. But if EGit is included in the launch it doesn't work. I can see it gets to this state: So it knows the selected item and it is the one with a tool tip text, but the index of that item is 18 even though it is the first item in the menu (which unfortuately is black during the screen capture: So it seems to me the problem is caused by the wrong index, likely because of items that have been removed or filtered or hidden separators. When EGit is not included in the launch, the index is zero which makes sense because it's the first visible item in the menu. I don't have time right now to debug further... |
I'm not suggesting this is the fix, but if I change the code in org.eclipse.swt.widgets.Menu.wmTimer(long, long) like this:
Then the tool tip shows, I believe because the index is correct relative to the actual menu items current in in the menu. With the print statement, without EGit deployed, I see this:
With EGit's feature in the launch I see this instead:
So it's quite clear that the menuItem.index value is simply wrong and this is the reason why the tool tip associated with that menu item is not shown. I'm out of time again for now... |
Thanks. I don't recognize the black area, but
seems very similar to my suspicion. I won't struggle to provide a rival M3 repro using my OCL code. |
Indeed. I can reproduce the problem and will continue to dig. |
I think the design is just wrong/broken. The MenuItem.index is initialized upon construction and is never updated nor maintained. But a MenuItem.dispose can obviously change every other MenuItem's actual index in the disposed MenuItem's containing Menu. |
- Remove MenuItem.index which is now unused. - Remove unused MenuItem.MenuItem(Menu, Menu, int, int) eclipse-platform/eclipse.platform.ui#2483
- Remove MenuItem.index which is now unused. - Remove unused MenuItem.MenuItem(Menu, Menu, int, int) eclipse-platform/eclipse.platform.ui#2483
- Remove MenuItem.index which is now unused. - Remove unused MenuItem.MenuItem(Menu, Menu, int, int) eclipse-platform/eclipse.platform.ui#2483
- Remove MenuItem.index which is now unused. - Remove unused MenuItem.MenuItem(Menu, Menu, int, int) eclipse-platform/eclipse.platform.ui#2483
If I am not mistaken, this has been fixed via eclipse-platform/eclipse.platform.swt#1575 |
I found that some of my tooltips were not being shown and after fixing some bad XML (the editor does not diagnose a gratuitous extra premature ">") I found that just changing the org.eclipse.ui.menus extension point in plugin.xml from
<menuContribution locationURI="popup:org.eclipse.ocl.examples.ui.Menu?after=show">
to
<menuContribution locationURI="popup:org.eclipse.ocl.examples.ui.Menu?after=load">
could make the missing tooltip visible.
Debugging by setting a breakpoint at line 1353 of Menu.class
boolean success = OS.GetMenuItemRect (0, selectedMenuItem.parent.handle, selectedMenuItem.index, rect);
if (!success) return null;
revealed two problems. a) when success is true, b) when success is false.
The first (success true) is reprodible on a basic Eclipse platform. Many menu entries have no tooltip. e.g. Help->Tip of the Day however debugging reveals this is because itemToolTip is null. Surely a missing tooltip should be 'inferred' as the label as is often the case already.
The second (success false) appears to be related to plugin.xml extension of a dynamically defined menu - not reprodicible on a basic platform.
In so far as I can debug this, I suspect that the selectedMenuItem.index argument to OS.GetMenuItemRect fails to account for separators and/or invisible entries and/or sub-menus.
'Repro'. The problems I experience are reproducible using the context menu of the Sample Ecore Editor. Team->Show Local History has a tooltip that is not displayed because success=false. (A repro using my released OCL code will just uncover downstream effects of the bad XML.)
The text was updated successfully, but these errors were encountered: