Add support for other fields like select.

Select elements can have string keys as well. We should add some validation to make sure the element only has number keys.

I understand your request now. This is already supported in the 'Options/Checkbox with number limit' handler. There, you can choose an options element whose value will determine the limit. You can choose different limits per option or a default that's used when no specific option limit is chosen.

I'm sorry for replying this late.

What I'm actually trying to accomplish is for example a registration form where visitor can register a number of attendees for an event. The field to indicate the number of attendees would be a select field.
In this case I would use a select field with the options 1,2,3,4 and the NumberLimitWebformHandler.
So instead of a webform element Number, I would like to use a select element just to enter a number.

Would you mind I reopen this issue for this specific case?

Probably I'll have to extend the patch and check if the select only contains numeric options before it is marked as a valid field instance to use in the NumberLimitWebformHandler.

Did you read my last comment? This is already supported in the module through the 'Options/Checkbox with number limit' handler.

Yes, I did read your last comment, but I'm not sure how I would accomplish this with the following settings.
Maybe I'm missing something.

Well, you create a select field that holds the different (textual) options, but not the limits. You choose that select element in the handler and in the limit fields you configure the different limits per option (1, 2, 3 and 4 as in your example).

Then I still think we're talking about a different use-case.
In my case I don't want to set the a limit per option, but the selected option (1,2,3,4) is added to the number of allowed subsciptions, as would a number field in the NumberLimitHandler.

If I have f.e. an event with a maximum of 20 seats, and each registrant can reserve 1-4 seats (select field) then:

• I can have 5 registrants (form submissions) who select each 4 seats
• 10 registrants who select each 2 seats
• 3 registrants who select 4 seats and 2 registrants who select 3 seats and 2 registrants who select 1 seat
• ... and various other combinations.

I'm sorry if I'm wrong but I don't think I can accomplish this in

Understood! I updated the issue title/description to make it more clear.

Could you test the MR? Now any options element can be used as number element, in both handlers.

I've tested the MR with both the Number Limit handler and the Options/Checkbox with number limit handler
The Number Limit handler works as expected!

On the Options/Checkbox with number limit handler there 's a little bug that allows you to select more places then available.
I think it's something ajax related. I'll check if I can find more details why it's failing.

I modified the MR to solve the issue I mentioned about the possibility to select a an option that's greather than the remaining number.

By changing getValue() to getUserInput() I now get the following notice when on the test page of a form:

Warning: Undefined array key "number" in Drupal\webform_number_limit\Plugin\WebformHandler\OptionsNumberLimitWebformHandler->alterForm() (line 177 of modules/contrib/webform_number_limit/src/Plugin/WebformHandler/OptionsNumberLimitWebformHandler.php).

I'll see if I can reproduce your issue.

I fixed that issue by checking the user input and falling back to the form values.

I removed the code you added that removes options. Instead, I changed it so the [x remaining] copy considers the currently selected value of the number element. When the value of the number element is too high, the options whose limit is exceeded are either removed or disabled, depending on how the handler is configured. That feels more in line with how the Options/Checkbox limit handler works. What do you think?

I'm sorry for replying this late. It seems good implementation. I'll test it right away.

I made some small changes to the if statements to check if a value exists in the form_state input / values array on the given key

@kensae there were already checks to see if the value exists in the form_state input / values array, that's what the ?? operator is for. Or do you have a specific reason to replace that with an empty() check, was anything broken?