What about just refusing to allow to complete the creation (instead of crashing) unless a payment method is selected, but not set a default type? That does raise the same issue we have elsewhere of how to inform the user of why the action is disabled - but I suggested in another bug using some sort of notification or status area, especially if there was only one remaining reason the action could not be completed.

In D29776#671741, @ostroffjh wrote:

What about just refusing to allow to complete the creation (instead of crashing) unless a payment method is selected, but not set a default type?

It looks like an equally valid solution to me.
On the other hand, setting a default is how manual schedule creation via Edit Scheduled Transaction Dialog works. My patch conforms to this same UI behavior pattern.

especially if there was only one remaining reason the action could not be completed.

On that Page of the Wizard there is a few fields that require user input. Shall we notify on one / the last remaining?

In the end, this a design choice and I do not consider myself competent to decide so I am willing to comply to what the Core Team decides.

The patch also disallows the user to intentionally set empty payment method. Empty method is not listed. Therefore I consider the fix quite solid.

The Wizard Schedule Page after the fix:

I defer a decision to Thomas, and consistency across the app is good. The issue of how to notify the user what is blocking the desired action is a more widespread problem, and might be better deferred until it can be addressed in general, and not just in specific cases. (That has mostly arisen when trying to delete something, and it is not clear what is preventing that.)

I wondered who added the #if 0 / #endif and traced them back into 2009 but could not go back any further. They existed every since.
It certainly does not make sense to skip adding a method and then later on make it the current one (2nd last line of this method). That is simply wrong. So the fix to add those methods seems valid to me.

@ostroffjh, I agree that your concerns are important. I have just skimmed through the code and came acrosss something that may render useful.
There is a virtual method isComplete() in KMyMoneyWizardPage class.

/**
  * This returns, if all necessary data for this page has been
  * filled. It is used to enabled the 'Next' or 'Finish' button.
  * The button is only enabled, if this method returns @p true,
  * which is the default implementation.
  *
  * @retval false more data required from the user before we can proceed
  * @retval true all data available, we allow to switch to the next page
  */
virtual bool isComplete() const;

The method is overridden in subclass CreditCardSchedulePage which is changed by this patch.
It seems this approach works as expected on the previous page:

@tbaumgart, That's right. I also investigated those #if 0/#endif lines to find out why they had been added before I decided to bring those two payment methods back and found no good reason. It might well have been only temporary and the author forgot to revert the change.

I suppose that the minimal fix to prevent the crash is the best approach here, and the issue of notifying the user of why an action is disabled can be deferred for later discussion of a consistent approach.

OK, I found it.
The 2nd last line of the isComplete() method should be d->m_wizard->d_func()->m_nextButton->setToolTip(msg); instead of d->m_wizard->d_func()->m_finishButton->setToolTip(msg);
Now the tooltip message informs the user why the Next button is disabled.

Should I create a new bug report to fix it or just add the tooltip fix to this patch?

Of course this notification system only applies to wizards and should not be considered a robust and universal approach @ostroffjh is rightly seeking.

Simply add it here.