I am creating a Calculator in Windows Store Application. I have successfully created the app in the store.
Now there is a problem in my app, after getting the result from performing any operation whenever I press on any numeric value, that value got append in the existing value.
In the following snapshot: I have added two numbers (1,1):
Now I am entering another value to perform some other option, but the new value got append in the existing value. I am entering 1 here:
What is the code for removing the existing value, if any numeric values pressed?
you could declare a bool value which is false and when you have your calculation done you switch it to true. Then you write a method that checks if the calculation is done or not and if it's done you simply clear the (i guess you use a textblock / box?) output. That would be my way in this situation - maybe there is a better solution for you. I hope it helps you to get a clearer way in mind.
As the author of the Windows Calculator that shipped from Windows 3.0 through Windows Vista, I agree with user3645029's response. You need to work out the input model for the app, so you understand clearly when you begin entering a new number and when you append to the one showing. I suspect that your app logic isn't making this distinction.
Let me be more specific:
If the key pressed is a number and the last key pressed was a number, then you add that new digit, which effectively means multiplying the current value by 10 and then adding the new key.
If the key pressed is a number and the last key pressed was an operator, =, or similar keys, then you're starting a new number input and your current value should be reset to 0 first.
In short, writing a calculator app requires an internal state machines that understands how to proceed from one input to the next. From what you describe, it sounds like you're missing the logic for the = key. Generally speaking, hand-held calculators with an = sign effectively clear the current value if you start entering a new number after =. Only if you press an operator does that value persist, and in that case you're also starting a new current value and keeping the "2" in your case as the first operand.
Related
I'm using Fortify static code analyzer with a C#/.NET project. I'm taking an integer parameter, a year, from user input and starting a process with that:
int y = int.Parse(Year.SelectedValue); //Year is a DropDownList
if (y >= 2017 && y <= DateTime.Today.Year)
Process.Start(new ProcessStartInfo(Server.MapPath("~/bin/SomeProgram.exe"), "/x:" + y.ToString()));
Fortify doesn't like that, throws a "Command Injection" issue:
Data enters the application from an untrusted source.
In this case the data enters at get_SelectedValue() in ccc.aspx.cs at
line 25. Even though the data in this case is a number, it is
unvalidated and thus still considered malicious, hence the
vulnerability is still reported but with reduced priority values.
The data is used as or as part of a string representing a command that is executed by the application.
In this case the command is executed by ProcessStartInfo() in
ccc.aspx.cs at line 28.
There are literally two possible values of input that would cause the process to start (as of this writing) - 2017 and 2018. If the if() statement doesn't count as validation for Fortify, what would?
EDIT: on top of everything, unless you explicitly opt of ASP.NET's ViewState integrity check, DropDownList doesn't allow values outside of the assigned range. With this in mind, I don't see why SelectedValue of a DropDownList is treated as an untrusted source in the first place.
Mark it as a false positive and move on.
I don't think Fortify takes the datatype into account. You are taking the value out of a string to and int, doing validation, then using the int value not the original. So as far as the command injection goes not an issue (in this case).
--
What constitutes a validation?
When it comes to Fortify, there is a difference between what constitutes validation and what will make Fortify stop reporting on it.
Unfortunately, there are some cases (as far as I have found from my time 5+ years of using Fortify) that you just cannot make it happy without writing a custom rule for the analyzer to indicate that some method is cleansing the data.
I'm not authorized to show the code but I have a problem:
When using the recording feature of CUIT on VS 2015, The test yields an error part way through the playback.
A date entry field is a masked input string field like this "MM/DD/YYYY HH:MM". You can type the values freely into the field. The issue is when doing playback, CUIT attempted to enter the string value of what is captured in the control's final state as "05/09/2017 12:42". The "/" and ":" of the string's value causes the cursor to tab through the masked input, resulting in an erroneous entry. The actual string required to account for all of the tabbing is literally "05///09///2017 12::42" but when I use that hard-coded value, it errors out while attempting to check for the longer version. States that it can't set the control to that value.
Is there a way to tell the CUIT to evaluate an overridden value so that it doesn't try to enter the string stored within the control which contains "/" and ":"?
You need to modify the value in the ...ExpectedValues class that holds the recorded date-time. Coded UI sends the recorded characters (or more accurately, the values from the ...ExpectedValues class) to the application and the application you are testing adds the / and : characters in the approprate places. The Coded UI recorder records both the entered and the generated characters.
Change the recorded 05/09/2017 12:42 value to be 05092017 1242. This can be done via the UI Map editor if the same date-time is always needed. Commonly the date-times are provided via the data source of a data driven test, or they are generated by the test itself. In either case it should be easy to provide data without the / and : or to add code to remove them before they are used. The wanted values are then written, when the test runs, into the ...ExpectedValues class.
See here for some additional notes on the ...ExpectedValues class and on data driving tests.
I need to use basic functionality of the MaskedTextBox. I can get use of the 5 digit mask but there are few things that I want to change. Right now the box is looking like this:
and there are two thing I don't like. First - the Prompt char which is undersoce _. I deleted the field value in order to leave it empty (as I would like it to appear) but this gives an error - The property value is invalid. So is there a way to get rid of these underscores? And second - I use this value for one of my entity properties which is of integer type so I make a convertion :
if (txtNumOfAreas.Text != "")
{
string temp = txtNumOfAreas.Text;
bool result = Int32.TryParse(temp, out convertValue);
if (result)
{
entity.AreasCnt = convertValue;
}
else
{
MessageBox.Show(Resources.ERROR_SAVE, "Error", MessageBoxButtons.OK, MessageBoxIcon.Error);
return false;
}
}
else
{
entity.AreasCnt = null;
}
which works fine unless someone decides to make experiments and insert something like _1__5_ then the conversion fails, but at first place I would like to make possible to write the digits only one after another. So is this possible too?
It looks like your MaskedEdit is more trouble than it's worth to deal with your particular range of issues. A better control to use might be the NumericUpDown.
The upside to NumericUpDown:
There are no underscore prompts to try and get rid of
It will only accept numeric input
So there is no need to try and convert the value. You will always have an integer
Setting Minimum and Maximum value properties gives you automatic data entry validation
Provides multiple modes of data entry:
Typing
Clicking up/down buttons with a mouse
Up/down with keyboard
If you like, you could hide the up/down buttons altogether: C# WinForms numericUpDown control (removing the spin box)
So to get the _ to be a space you just need to set the mask character to a single space. And to resolve the conversion error, just set the AllowPromptAsInput property to false so that the user can't actually end up with something like your example.
I have several groupBoxes-controls with a NumericUpDown-control in each on of them. The NumericUpDowns have a small modification - they can also decrement in the negative range of decimal. Here is the code:
//Add KeyDown event to the numericUpDown control
numericUpDownGBPC12_angleRange.KeyDown += new KeyEventHandler(numericUpDownNegative);
The code of the function numericUpDownNegative is as follows:
void numericUpDownNegative(object sender, KeyEventArgs e)
{
NumericUpDown temp = (NumericUpDown)sender;
temp.Value -= temp.Increment;
sender = (object)temp;
NumericUpDown temp = (NumericUpDown)sender;
}
Suggestions for improving the code above are most welcome however I'm more interested if it is possible to enable negative input in a NumericUpDown. The above code works but when I try to put a negative number I get something weird. This behaviour does not apply for a non-modified NumericUpDown.
Example:
Let's say numericUpDownGBPC12_angleRange has a minimum of -70.0000000000 and a maximum of 70.0000000000, which I have set by the Minimum/Maximum property parameters of the control. The starting value of the control is 0.0000000000. If I push the Down-button, I get accordingly -0.0000000001, -0.0000000002, -0.0000000003 etc. until I reach -70.0000000000. However if I decide to type -x.xxxxxxxxxx (let's say -24.2398324119) I get x-0.0000000000 (4-0.0000000000). So not only I cannot enter the full number 24 (it seems the NumericUpDown takes the last typed digit in this case, which is 4), but I get the whole part after the point completely annihilated unless it was set by using the case in which case the problem is only with the part before the point. So only the first digit (on the most left of the number) can be changed. :-/
I was thinking of using textBox-controls however the amount of number fields I have as part of the interface will create a huge overhead because of the parsing of each and every textBox (we all know that sadly many users love to experiment with things that where never intended to be experimented with ;)) to make sure a certain number is entered. Despite the negative-thingy the NumericUpDown has really nice feature such as - only a digit can be entered and you can also specify the precision, the range of values etc.
So again the question is - is it possible for a NumericUpDown to accept negative input by the user?
Problem was in the KeyDown-event (had to remove it completely) and also in the format I was trying to input as a number. I have the ',' seperator and not the '.' in my Visual Studio (due to localization). So typing '.' made the NumericUpDown go berserk.
I have a winform app with a TimeSpan column that displays the hours/minutes part of a date. When the user enters text it is converted to a TimeSpan using TimeSpan.TryParse(). This works as expected when the user input is "11:00" in setting a value of 11 hours. The problem is that if the use enters "1100" it is parsed as 1100 days which is not what I want, nor is simply saying "bad input" in the `CellValidating event satisfactory behavior.
The users input is provided in the readonly property DataGridViewCellValidatingEventArgs.FormattedValue so I can't change the value being passed through the call chain. DataGridViewTextBoxCell.EditedFormattedValue is also read only and I can't find any other event or property that lets override the default behavior.
This is very frustrating. I can write a many stepped fall through validater that can handle multiple user input formats and get the intended value from each; but unless I throw away all the strongly typed data binding that the framework offers and instead create a shim object that stores all values as strings there doesn't seem to be any way to do so.
Somehow among the 10 billion events in the DataGridView I managed to overlook CellParsing. Overriding it lets me do what I need to do.