Bug 57399 - [Wizards] infopops in wizard pages fail if no control is "T-selected"
Summary: [Wizards] infopops in wizard pages fail if no control is "T-selected"
Status: RESOLVED WORKSFORME
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 2.1.3   Edit
Hardware: PC Windows 2000
: P4 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Karice McIntyre CLA
QA Contact:
URL:
Whiteboard:
Keywords: api
Depends on:
Blocks:
 
Reported: 2004-04-04 19:30 EDT by Tom Roche CLA
Modified: 2009-02-26 17:04 EST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Roche CLA 2004-04-04 19:30:42 EDT
WebSphere Studio has defect 270185 relating to a problem with some
(but not all) pages of my wizards: instead of showing the correct
infopop, hitting F1 got the default, "Resources" infopop. 

The etiology appears to be that (at least, on Windows, using a 2.1.3
base) o.e.ui.help.WorkbenchHelp gets confused if a page has nothing
"T-selected": i.e. nothing on the page either

* has a cursor in it, if a Text

* is selected (highlighted), if a Text or a list item

* has focus (haloed) otherwise

Note that after you T-select something, you're golden, 'cause you
can't "un-T-select" as defined above: even if you un-highlight text,
you still have a cursor there, and that's enough.

The problem is that some wizard pages have no controls that are easily
or legitimately T-selected. In any case (IMHO), the connection between
T-selection and infopops is not readily apparent to the developer.
Comment 1 Konrad Kolosowski CLA 2004-04-05 11:09:13 EDT
I think it is an SWT limitation.  If I am correct, F1 events are sent to the 
control with focus.
Comment 2 Grant Gayed CLA 2004-04-05 11:42:05 EDT
Events like this necessarily go to the control with focus, this is by design.  
On a wizard page with no focusable controls initial focus will go to the Back 
button at the bottom.

There isn't anything for swt to do here, so moving back to Help to decide 
whether there's a semantic Help issue here to deal with or not.
Comment 3 Tom Roche CLA 2004-04-05 11:58:40 EDT
I can see 2 (non-exclusive) options:

* allow a wizard user to override infopops set on the outermost
  Composite (presumably the WizardDialog). This may already be
  possible, but I haven't tried it. (A snippet would be nice, and good
  to document as a best-practice. It would also be good to document
  this "gotcha.")

* make Help "prefer" an infopop set on the WizardPage to one set on
  the WizardDialog
Comment 4 Konrad Kolosowski CLA 2004-04-05 13:12:09 EDT
Agree with Tom.
I think, the Wizard should have an API to register help for a page.  When page 
has no focusable widgets, the F1 event received by the back button (that for a 
a user looks like belonging to the page) should trigger help for a currently 
showing page.
Comment 5 Tod Creasey CLA 2004-04-15 09:07:52 EDT
Not for 3.0. We need to avoid new API at this point
Comment 6 Tod Creasey CLA 2004-06-28 11:27:42 EDT
Reopening now that 3.0 has shipped
Comment 7 Boris Bokowski CLA 2009-02-26 17:04:30 EST
I believe this is no longer a problem. Please reopen if I am wrong.