Normally, you will want to use this method for the Finish button only: The Next and Back buttons are usually maintained automatically, the Help and Cancel buttons are unlikely to ever being disabled.

In general, the default button in a wizard is the one which is activated when the user presses the return key while the focus is in a control which does not handle this key itself (such as ordinary input controls).

You can use this method, for instance, to make the Next button the default button on all pages except the last one, where Finish should be defaulted.

Calling this method is equivalent to the user pressing the Next button in the wizard. Consequently, the method will fail if in the current state of the wizard, it is not allowed to advance to a next page.

Calling this method is equivalent to the user pressing the Back button in the wizard.

You can use this method when not all pages of your wizard are necessarily needed in all cases. For instance, assume that your first wizard page contains a check box, which the user can check to enter additional data. If you place this data on the second page, then you will want to enable this second page if and only if the checkbox is checked.

If a page is disabled, it can reached neither by clicking the respective item in the wizard's roadmap, nor by sequential traveling. Still, the page's item is displayed in the roadmap, though disabled.

For instance, the Next button is disabled if the current page's XWizardPage::canAdvance method returns false.

You usually call this method from within a wizard page whose state changed in a way that it affects the user's ability to reach other pages.

Calling this method is equivalent to the user repeatedly pressing the Next button, until the given page is reached. Consequently, the method will fail if one of the intermediate pages does not allow advancing to the next page.

Calling this method is equivalent to the user repeatedly pressing the Back button, until the given page is reached.

If the wizard has been created with multiple paths of control flow, then this method allows switching to another path.

You can only activate a path which shares the first k pages with the path which is previously active (if any), where k is the index of the current page within the current path.

Example: Say you have paths, (0,1,2,5) and (0,1,4,5) (with the numbers denoting page IDs). This means that after page 1, you either continue with page 2 or state 4,and after this, you finish in state 5.
Now if the first path is active, and your current state is 1, then you can easily switch to the second path, since both paths start with (0,1).
However, if your current state is 2, then you can not switch to the second path anymore.

If true, the path will be completely activated, even if it is a conflicting path (i.e. there is another path which shares the first k states with the to-be-activated path.)

If false, then the new path is checked for conflicts with other paths. If such conflicts exists, the path is not completely activated, but only up to the point where it does not conflict.

In this latter case, you need another activatePath method (usually triggered by the user doing some decisions and entering some data on the reachable pages) before the wizard can actually be finished.

With the paths in the example above, if you activate the second path, then only steps 0 and 1 are activated, since they are common to both paths. Steps 2, 4, and 5 are not reachable, yet.