Community
Participate
Working Groups
Its not clear what a wizard writer is supposed to do to for notification of page transition. This is important for complex wizards which have to compute expensive information based on a previous page, or where it must compute something expensive for availability of the next page. The goal is optimal delaying of computing information and of setting page control state (e.g. setting input on a tree). This may just be a javadoc/doc issue, or may be an API improvement issue. I would understand if we were hesitant to change any API here since there are already a lot of wizards written against the current API. At present the writer can do one of two things: 1. supplement DialogPage.setVisible(boolean) - Although the javadoc says you can supplement it, it feels like a hack to do so (I assumed it was wrong until I saw the javadoc and spoke with Randy). Perhaps its just because it looks more like a setter than a notification of visibility. I have a bit of concern that the framework may wish to distinguish notification from setting of a field state. It would be clearer to have methods like: entering() leaving() which are more clearly there solely for notification. 2. The other trick is to override getNextPage(). There are two problems here: - the API isn't clear that its ok to compute information for the next page by overriding this method. Its also not clear that you could dynimally compute the next page using this. The javadoc comment in the method in IWizardPage isn't clear, and the class javadoc for WizardPage doesn't list it in the section titled " * Subclasses may override these methods if required:" - this method gets called a lot (e.g. to determine if Next> should be enabled). Optimal use would involve overriding other methods which by default send it. The javadoc should at least say that if you override it to do real work, you need to override other methods as well. This is indicative of a problem in the framework though. For example, if the method was called computeNextPage(), it would be clear that senders should minimize their use and that implementors can rely on that.
Should clarify / enhance API for 2.0, time permitting.
*** Bug 16803 has been marked as a duplicate of this bug. ***
So many people are requesting this (take a look at the newsgroup)...we should really provide an API for this.
This will need to happen for a time when we can add API - post 2.1.
I have been working around this problem for a while. I'd also like to request a programatic way to push the next/back buttons - there are times when the default button() won't get called, such as: focus is in a text field (not multi-line), enter key is hit....I want to press next(), but I can't seem to do this in a realistic way.
Not for 3.0.
Created attachment 24492 [details] Adds Page Changing Events This patch adds a new IPageChangingListener and associated events/provider classes. The code was modeled after the page changed events mechanism added in 3.1. The intention of this addition is to allow pages to perform intensive processing between page navigation, and specifically allow pages to prevent page navigation is this processing fails. For example, I have a wizard where a user types in database connection parameters. Connecting to a database server is a relatively time intensive tasks (at some customer sites, over WANs and such it can take as much as 20 seconds), therefore I cannot try the connection and perform the validation as the user types. Instead I need to wait until the user clicks Next, validate the connection, then allow the navigation to the next page, or if the connection failed, stay on the same page.
*** This bug has been marked as a duplicate of 20319 ***
Sorry meant to dupe the other way around
*** Bug 20319 has been marked as a duplicate of this bug. ***
Thanks for the patch Chris. I prefer the idea of the listener myself (like you have in your patch) but my question was how you expect wizards to register themselves? Right now they only have access through the IWizardContainer. Are you suggesting calling getWizardContainer and then checking instanceof IPageChangeListener? If we went with the other option of adding API to WizardPage this check would require us to see if the currentPage was a WizardPage (or some other interface) before we applied it. My feeling is that we should go with the event listening idea and implement a method getPageChangingProvider() in WizardPage that can this casting and checking for you. This is a nice idea that is long overdue - I am upping priority. Let we know what you think and we can proceed.
Tod thanks for looking into this. I have the same concern. I would definitely agree that adding getPageChangingProvider() to WizardPage is the way to go. I hesitated doing that originally because it wasn't done for the page changed provider. I was/am wondering if I missed anything. Perhaps the use case for the page changed provider is different, or perhaps there is some other method to get the provider that I'm missing. Or maybe not, and we should add getPageChangedProvider() to WizardPage as well.
*** Bug 46385 has been marked as a duplicate of this bug. ***
*** Bug 77426 has been marked as a duplicate of this bug. ***
We also need control over the pages List themselves, Wizards should have the ability to add/remove pages dynamically based on questions being asked of the users. Currently, we can only Add pages, we cannot remove them/replace them.
Craig, the wizard framework was not designed to dynamically add and remove pages in the manner you mentioned, so retroactivally adding this function will likely be an intensive effort and difficult to get right without breaking existing function. Your request should be logged as a separate bug (an enhancement request) with keyword 'helpwanted'.
Created attachment 51264 [details] updated patch for 3.3; apply patch to org.eclipse.jface Here is an updated patch of Chris' original patch submission. I want to look at it a bit more and see if JUnit tests can be created for it before releasing.
Created attachment 51375 [details] apply patch to org.eclipse.jface Here is the patch I propose we use. I renamed the provider/listener/event classes to use the word 'transition' instead of 'changing', since I think it will be easily confused with the page changed listener/provider/event classes. Also, I removed the Finish event type since validation can be done in Wizard#performFinish().
released to HEAD for build > 20061004
Created attachment 53025 [details] simple new wizard to demo page transition listener/provider/event *File > New > Other > Bug 16179 Sample > Page transition listener test. *Enter a non-number to see the page transition listener fail on Next case, enter a number and click Next to advance to last page. *Enter a non-number then click Back to see the page transition fail on Back case *Enter a non-number on last page and click Finish to see the page transition listener fail on finish case. *Enter a number then click Finish for success - a project called Test# will be created.
verified in I20061031-0656. It would be great to get some feedback from clients by the end of January (2007) on this.
See bug 168888 for changes made to the original patch.
