Issue Details (XML | Word | Printable)

Key: IZPACK-93
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Critical Critical
Assignee: Julien Ponge
Reporter: Jeff Gordon
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
IzPack

Re-enabled button does not gain focus

Created: 22/May/08 09:22 AM   Updated: 25/Sep/08 02:45 AM
Component/s: Installer
Affects Version/s: 3.11.0
Fix Version/s: 4.1.0

Time Tracking:
Not Specified

Environment: Tested on Windows XP and Server 2003


 Description  « Hide
When the Next Button on a panel is disabled, the Cancel Button gets focus then when the Next Button is enabled again it never receives focus properly. Currently, the requestFocus() method is used and I tried switching it to the requestFocusInWindow() as is advised now, but it does not change focus properly either.

The end result is that end users try and press Enter to progress through the installer and after the installation progress (InstallPanel) they hit enter and the installer just "goes away" leaving a half-baked install. This behavior should be the case for ANY panel that disables the Next Button during the install.



 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Jeff Gordon added a comment - 23/May/08 01:51 PM
This is fixed by setting the nextButton as the default button after requesting focus.

Any objections?

  • Jeff

public void unlockNextButton(boolean requestFocus)
{
nextButton.setEnabled(true);
if (requestFocus)
{
nextButton.requestFocusInWindow();
getRootPane().setDefaultButton(nextButton);
if (this.getFocusOwner()!=null) { Debug.trace("Current focus owner: "+this.getFocusOwner().getName()); }
if (!(getRootPane().getDefaultButton()==nextButton)) { Debug.trace("Next button not default button, setting..."); quitButton.setDefaultCapable(false); prevButton.setDefaultCapable(false); nextButton.setDefaultCapable(true); getRootPane().setDefaultButton(nextButton); }
}
}


Julien Ponge added a comment - 24/May/08 04:08 AM
No objection here.

Julien Ponge added a comment - 29/May/08 02:57 PM
The fix shall be committed in the 4.0 branch.

Thanks Jeff!


Julien Ponge added a comment - 21/Jul/08 03:14 AM
The issue is rescheduled to 4.1.0 as it could not make it for the 4.0.1 cutoff.

Julien Ponge added a comment - 09/Sep/08 09:24 AM
This issue has been originally scheduled for inclusion in version 4.1.0, to be released on october 2nd 2008.

If you believe that it cannot be resolved on time, then could you please move it to 4.2.0? Otherwise, I would appreciate if you could give me a time frame for scheduling purposes

Thanks a lot!