It would be great if Slim::Buttons::Input::Choice would pass the argument part in the plugin.

The problem occurs when I in a plugin like to use the Input::Choice for a menu.

This is some sample code from the Custom Browse plugin:
====================
# Registration part
my %choiceFunctions =  %{Slim::Buttons::Input::Choice::getFunctions()};
$choiceFunctions{'createmix'} = sub {Slim::Buttons::Input::Choice::callCallback('onCreateMix', @_)};
Slim::Buttons::Common::addMode('PLUGIN.CustomBrowse.Choice',\%choiceFunctions,\&Slim::Buttons::Input::Choice::setMode);

# Usage part (more parameters are defied in the real implementation, this is just a sample
my %params = (
	listRef    => \@listRef,
	onCreateMix => 
		sub {
			my ($client, $item, $functarg) = @_;
			# Some code here
		},				
	onPlay => 
		sub {
			my ($client, $item) = @_;
			# Some code here
		},
	onAdd => 
		sub {
			my ($client, $item) = @_;
			# Some code here
		},
);
Slim::Buttons::Common::pushModeLeft($client, 'PLUGIN.CustomBrowse.Choice', \%params);
====================

The problem is that the $functarg parameter to the onCreateMix function is never passed from Input::Choice, instead it only passes the $client and $item.

The result is that you can't define a custom.map IR entry like the following:
0.hold = modefunction_PLUGIN.CustomBrowse.Choice->createmix_artistmix

If the $functarg parameter was passed through, it would for this sample be equal to "artistmix". This is also how the custom.map information is passed through the IR/command mechanism in other situations, but it isn't if you use Input:Choice.

The attached patch solves the problem.