Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 292804

Summary: TrayDialog help not registering correct event listener
Product: [RT] RAP Reporter: Paul Kendall <pkendall64>
Component: RWTAssignee: Project Inbox <rap-inbox>
Status: RESOLVED FIXED QA Contact:
Severity: major    
Priority: P3    
Version: 1.2   
Target Milestone: 1.3 M3   
Hardware: All   
OS: All   
Whiteboard:
Attachments:
Description Flags
Patch to fix the way that TrayDialog determines which control to send the help event to none

Description Paul Kendall CLA 2009-10-20 14:38:39 EDT 
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.3) Gecko/20091007 Ubuntu/9.10 (karmic) Firefox/3.5.3
Build Identifier: Head

TrayDialog notifies a typed listener of SWT.Help (in the helpPressed
method), but the addHelpListener (on Control) does not register a typed
listener. If I look at the SWT source for control it does register a typed
listener for SWT.Help. The RAP implementation uses a HelpEvent helper class
which uses the untyped event mechanism. Either the TrayDialog or the Control
in RAP needs to be changed to fix this problem. Also, the UtypedEventAdapter
would need to have the SWT.Help case added to it.

Reproducible: Always

Steps to Reproduce:
1. Create a TrayDialog implementation
2. register help with the tray dialog's shell
		setHelpAvailable(true);
		PlatformUI.getWorkbench().getHelpSystem().setHelp(shell, "com.orchestral.core.cache.ui.configuration");
3. Press the help button on the dialog

I put a breakpoint into the helpPressed method in the TrayDialog and see the method called, but there are no SWT.Help typed listeners registered. If you step through the registering of the help you will find that it registers an untyped event, but should (according to the SWT implementation) register an untyped event.
Comment 1 Rüdiger Herrmann CLA 2009-10-22 06:43:53 EDT 
Fixed in CVS HEAD
Comment 2 Paul Kendall CLA 2009-10-22 14:45:10 EDT 
Fixing the UntypedEventAdapter to recognise SWT.Help does not fix the problem completely. The problem now is that Control, Menu & MenuItem are sending typed events and the TrayDialog has a listener that is executed when the help button is clicked, but it then iterates the control stack looking for a control with registered untyped SWT.Help events.

The Fix to this is to change the helpPressed() method of TrayDialog to look for typed events.

I will attach a patch that fixes the problem for me.
Comment 3 Paul Kendall CLA 2009-10-22 14:46:17 EDT 
Created attachment 150287 [details]
Patch to fix the way that TrayDialog determines which control to send the help event to
Comment 4 Paul Kendall CLA 2009-10-22 14:50:34 EDT 
Please ignore my attempts to explain the problem in comment #2!

The problem is that TrayDialog is looking for the wrong type of evenets. It is looking for untyped events when typed events are being fired. I think that this is just a difference in the way that RAP works compared to SWT. So, the patch stands and fixes the problem for me.
Comment 5 Rüdiger Herrmann CLA 2009-10-26 10:50:26 EDT 
Sorry for not getting that right in the first place.
The issue should be solved now. Widget#isListening() is fixed by now also taking typed events into account.