Second option for progress bar update (would fix #2)

[lvmajor]

This option adds the possibility for the user to specify its own handler for the progress update event. If none was specified, we trigger the custom plugin event, else we call the specified function, still passing the current progress percentage as a parameter.

Usage example for initialization:

$(".msf:first").multiStepForm(
    {
        progressHandler: function (progressValue) 
        {
            // This is an example for bootstrap 4 progress bar 
            $progressBar.attr('aria-valuenow', progressValue + '%').css('width', progressValue + '%');
        }
    } 
);

[mgildea]

I think these are all great ideas; I'll take a closer look these this evening. We may want to consider triggering different events (or accepting function) for clicking back vs next vs submit as well as the change/progress event.

[lvmajor]

Effectively. Also, it could be nice to find a way to let users navigate through the steps in the order they want by clicking on the header icons... don't know if that would be useful for a lot of people though....

[mgildea]

I think i like the first option where we just trigger an event, we will then want to provide as much relevant data as we can (index, previousIndex, numViews, etc) and let the user listen for that event and do with it what they need. If we start accepting functions as parameters we may go down a path where we have to accept a long list of functions for different scenarios. What do you think?

[lvmajor]

It would effectively open the door to multiple functions passed from user to handle different events. I don't really have a strong opinion on what's best between simply triggering the event and letting the user do what he wants with it VS accepting handlers at initialization... I guess I will go with whatever you consider is best for your plugin's future :P