[cocoa] Stop using CancelMenuTracking()
#337
Comments
|
Here's my native snippet I used for testing (compile with SWT snippet is already in the repo, see |
|
I will not be able to handle this soon, so everyone is welcome to fix that. |
|
Can we simply remove Or replace with |
|
Removing |
|
If it's needed, then replacing with |
|
Comment in that part of the code: |
|
Yes, I seen this comment, of course. It doesn't quite explain what does it really fix, and why cancelling tracking is needed in the first place. |
|
Can you make a PR with these changes (and use (I put the javadoc comment here for other people to see) |
|
Here, I removed both: #338 |
|
It was added in 080eb4c |
|
I removed Edit: see below |
Actually I am wrong. I did manage to follow those steps and see the problem. |
|
And I tried the same thing using |
|
The steps in 270379 can be tricky to follow. So in our RCP app we have a Help menu to which I added an public void run() {
Display.getDefault().timerExec(2000, () -> {
MessageDialog.openInformation(null, "Test", "Test");
});
}
|
|
In fact, while testing above with not using |
|
Note that my tests were done with |
|
My conclusion is not to remove
Maybe, but it does still prevent the above situation, so it is doing something. |
|
Thanks for testing! |
|
To make testing even easier I created a simple snippet. Instructions are in the snippet and on the app's label when run. This is to test the effect of removing or commenting out this line in
Click here to reveal the Snippet...import org.eclipse.jface.dialogs.MessageDialog;
import org.eclipse.swt.SWT;
import org.eclipse.swt.events.SelectionListener;
import org.eclipse.swt.layout.GridLayout;
import org.eclipse.swt.widgets.Display;
import org.eclipse.swt.widgets.Label;
import org.eclipse.swt.widgets.Menu;
import org.eclipse.swt.widgets.MenuItem;
import org.eclipse.swt.widgets.Shell;
public class CancelMenuTrackingTest {
public static void main(String[] args) {
final Display display = new Display();
final Shell shell = new Shell(display);
shell.setLayout(new GridLayout(1, true));
shell.setSize(500, 300);
new Label(shell, 0).setText("1. Run this on Mac\n" +
"2. Go to the Help menu and select the \"Open Dialog\" menu item\n" +
"3. Click back into the Help menu so that the Search field has the focus\n" +
"4. Close the dialog that appears\n" +
"5. Notice behaviour of menu bar if OS.CancelMenuTracking() is not called");
// Create Root Menu
Menu rootMenu = new Menu(shell, SWT.BAR);
shell.setMenuBar(rootMenu);
// Add some menu items
for(int iMenu = 1; iMenu < 3; iMenu++) {
MenuItem rootItem = new MenuItem(rootMenu, SWT.CASCADE);
rootItem.setText("Menu " + iMenu);
Menu menu = new Menu(shell, SWT.DROP_DOWN);
rootItem.setMenu(menu);
for(int iItem = 0; iItem < 6; iItem++) {
MenuItem item = new MenuItem(menu, SWT.CASCADE);
item.setText("MenuItem " + iMenu + " : " + iItem);
}
}
// Add the Mac Help Menu Item which will have a search text field
MenuItem helpMenuItem = new MenuItem(rootMenu, SWT.CASCADE);
helpMenuItem.setText("Help");
Menu helpMenu = new Menu(shell, SWT.DROP_DOWN);
helpMenuItem.setMenu(helpMenu);
// Add a menu item which will open a modal dialog after 2 seconds
MenuItem runItem = new MenuItem(helpMenu, SWT.CASCADE);
runItem.setText("Open Dialog");
runItem.addSelectionListener(SelectionListener.widgetSelectedAdapter(e -> {
Display.getDefault().timerExec(2000, () -> {
MessageDialog.openInformation(shell, "Test", "Test");
});
}));
shell.open();
while(!shell.isDisposed()) {
if(!display.readAndDispatch()) {
display.sleep();
}
}
display.dispose();
}
} |
|
As POC, replace static void cancelRootMenuTracking () {
NSMenu menubar = getCurrent().application.mainMenu();
menubar.cancelTracking();
}
Edit - nope. Menu items are left hanging in the air in my test snippet. I should have tested this more before commenting here. Ignore above. |
In Bug 578171, a crash was discovered. Back then I didn't realize that it's triggered by
CancelMenuTracking(), and thought that it was triggered by showing aShellwhen browsing menu bar.Today I spent time to make a native snippet to report bug to Apple, but when doing so, I found that
CancelMenuTracking()menubar.cancelTracking()doesn't trigger itI also found that
CancelMenuTracking()is not supposed to be called from 64-bit code, seeXcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/Headers/Menus.h:Here, note
[32-bit only]and#if !__LP64__.In order to circumvent that, SWT uses dynamic linking to access the API:
To summarize:
The suggested fix is to
CancelMenuTracking()The text was updated successfully, but these errors were encountered: