Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[UWP] Fix Input.Number validation logic to ensure value is a number #4432

Merged
merged 2 commits into from
Jul 21, 2020
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
42 changes: 18 additions & 24 deletions source/uwp/Renderer/lib/InputValue.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -253,40 +253,34 @@ HRESULT NumberInputValue::RuntimeClassInitialize(_In_ IAdaptiveNumberInput* adap
HRESULT NumberInputValue::IsValueValid(_Out_ boolean* isInputValid)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this something that can eventually land as part of shared code in the shared model at all?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could theoretically put a helper method for this and/or other validation methods in the shared model. I'm not sure how much we'd get out of that, because some portion of what's going on here is getting things out of xaml controls and whatnot, and what we have in hand is a UWP number input object not a shared model one. We could convert back, or just get the min and max values to pass to a helper, but the actual shared code is probably just a few not very interesting lines. (Although, admittedly, I'm fixing a consistency bug in those few lines so i guess they're at least a little interesting :)).

Probably not worth doing now, but it's something we can keep in mind if we start seeing more consistency issues in this logic or if our local validation becomes more complex.


In reply to: 457623190 [](ancestors = 457623190)

{
// Call the base class to validate isRequired
boolean isBaseValid;
RETURN_IF_FAILED(InputValue::IsValueValid(&isBaseValid));
boolean isValid;
RETURN_IF_FAILED(InputValue::IsValueValid(&isValid));

// Check that min and max are satisfied
int max, min;
RETURN_IF_FAILED(m_adaptiveNumberInput->get_Max(&max));
RETURN_IF_FAILED(m_adaptiveNumberInput->get_Min(&min));

// For now we're only validating if min or max was set. Theoretically we should probably validate that the input is
// a number either way, but since we haven't enforced that in the past and the card author likely hasn't set an
// error message in that case, dont't fail validation for non-numbers unless min or max is set.
boolean minMaxValid = true;
if ((min != -MAXINT32) && (max != MAXINT32))
{
HString currentValue;
RETURN_IF_FAILED(get_CurrentValue(currentValue.GetAddressOf()));
HString currentValue;
RETURN_IF_FAILED(get_CurrentValue(currentValue.GetAddressOf()));

if (currentValue.IsValid())
// If there is a value, confirm that it's a number and within the min/max range
if (currentValue.IsValid())
{
int currentInt;
try
{
int currentInt;
try
{
std::string currentValueStdString = HStringToUTF8(currentValue.Get());
currentInt = std::stoi(currentValueStdString);
minMaxValid = (currentInt < max) && (currentInt > min);
}
catch (...)
{
minMaxValid = false;
}
std::string currentValueStdString = HStringToUTF8(currentValue.Get());
currentInt = std::stoi(currentValueStdString);
isValid &= (currentInt < max) && (currentInt > min);
}
catch (...)
{
// If stoi failed this isn't a valid number
isValid = false;
}
}

*isInputValid = isBaseValid && minMaxValid;
*isInputValid = isValid;

return S_OK;
}
Expand Down