Comment 1 Mladen Mihajlovic 2006-01-14 13:35:42 EST

Created attachment 33031 [details]
Eclipse's way

This is how eclipse shows it (wrong)

Comment 2 Mladen Mihajlovic 2006-01-14 13:37:03 EST

Created attachment 33032 [details]
Firefox's way

This is the way Firefox does it (right)

Comment 3 Florian Priester 2006-01-18 00:11:53 EST

It's possible to get the desired effect right now by not returning from the
selection event handler until the user has dismissed the pop-up menu, e.g.

  toolItem.addListener(SWT.Selection, new Listener() {
    public void handleEvent(Event event) {
      if (event.detail == SWT.ARROW) {
        // open menu
        // ...
        
        while (!menu.isDisposed() && menu.getVisible()) {
          if (!display.readAndDispatch()) display.sleep();
        }
      }
    }
  });

If there is another drop-down item on the tool bar, and you click on the
arrow of the second item while the menu of the first one is visible,
you'll end up with two depressed arrow buttons, though. I did not find
an easy way around this. In contrast, Windows Explorer has some kind
of restriction in place that prevents you from, say, activating the
drop-down arrow of the "Forward" item while the menu of "Back" is visible.

Comment 4 Florian Priester 2006-01-18 00:40:05 EST

(In reply to comment #3)
> It's possible to get the desired effect right now

Okay, sorry, that's wrong.

I had forgotten about the fact that I had made a change to my local copy
of org.eclipse.swt before running the code given above. The change was to
replace the following line in ToolBar.wmNotifyChild -> case OS.TBN_DROPDOWN:

  child.postEvent (SWT.Selection, event);

with

  child.sendEvent (SWT.Selection, event);

With this modification it works as described.

Comment 5 Steve Northover 2006-01-18 13:14:06 EST

Yes, I was aware of that.  Once upon a time, there was a cheese bug where the pushed in tool item didn't redraw.  We worked around that in another bug report.  I'm afraid of changing the post to a send though.

Florian, you are GOOD.  Where did you learn so much about Windows and SWT?

Comment 6 Florian Priester 2006-01-18 16:39:05 EST

(In reply to comment #5)
> Florian, you are GOOD.  Where did you learn so much about Windows and SWT?

Thanks, but that's really too much honour. Actually, my knowledge
of Windows programming is rather limited, the last time I called
system routines on a regular basis was back in the MS-DOS days.
Nowadays it's easy to concentrate on actual application code thanks to
helpful people like you who take care of the low-level GUI stuff!

As for SWT, whatever I know about it comes from ~3 years of using
the toolkit, following its development to a certain degree and,
most of all, having the source code available. Whenever I'm curious
as to how something works, I can just go and take a look.

With respect to this bug report, when first discovering SWT's API for
drop-down tool items, I somehow expected to find an accompanying method
like ToolItem.setMenu that would handle all of the menu logic for the user,
much like Control.setMenu does. I imagine that having this code on the
SWT side might also make fixing a bug like this easier, but I assume
there's a reason it wasn't done that way?

Having said all that, I have just now discovered that there's a bug
(bug 18403) that already had all of the investigation. Oh well...

Comment 7 Lars Vogel 2019-09-04 02:58:27 EDT

This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it and remove the stalebug whiteboard tag. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--