had a quick google for this but no luck ( well not what i wanted).
checking input is a textbox is valid i.e. is a character or numeric value.
any way to do this without importing user32.dll for the IsChar etc functions ?
Printable View
had a quick google for this but no luck ( well not what i wanted).
checking input is a textbox is valid i.e. is a character or numeric value.
any way to do this without importing user32.dll for the IsChar etc functions ?
http://msdn.microsoft.com/en-us/libr....tryparse.aspx
http://msdn.microsoft.com/en-us/libr....tryparse.aspx
you can then use each classes' .Parse methods to capture a string from a field. Also you may want to look into the ErrorProvider class which executes validation logic in a control's validation events automatically.
1) Use int.TryParse
2) Traverse each character and test with char.IsNumber
or just Convert.ToX and catch exception(s)
ok expanding on this a little
im am using Leave event from the textbox to check the input.
sender is my textbox and should i beleive hold all the relevant information about the control. i have checked this and can see the values in the IDE.Code:private void textBox1_Leave(object sender, EventArgs e)
{
......
}
My question is how do i access them ?
if i try sender.text.tostring(), it complains that text isnt valid
if i try sender.tostring(), i get the object reference and the text it holds as a single string.
i need to segregate the actual text in the textbox from sender args - is this possible ? if so how ?
Sender is an "object", you need to cast it to a textbox:
Code:var MyTextBox = sender as System.Windows.Forms.TextBox;
var MyText = MyTextBox.Text;
//Do something with MyText here
ok i was playing around with this ( and kind of came up with Magos' suggestion)
but want i want to know is this the right way to do it ? i dont want to use it if it is wrong and i end up with a bad habit :)
this appears to do what i want and automatically updates the text in the textbox which saves me a job :)Code:private void textBox1_Leave(object sender, EventArgs e) // trim leading and trailing spaces
{
test_input.Strip_Spaces((TextBox) sender); <-- call class handler
}
public TextBox Strip_Spaces(TextBox obj) <--- class test_input
{
obj.Text = obj.Text.TrimStart(); << --- can these two lines be merged into 1 statement ??
obj.Text = obj.Text.TrimEnd(); <<---
return obj;
}
Use "Trim()" instead, it's semantically equivalent to "TrimStart().TrimEnd()".
Yeah, it is fine. Would prefer not to use obj for a TextBox, since obj would be like for Object, but details details.
You could use Trim() I guess instead of TrimStart()+TrimEnd(). In which case this would be simpler:
Code:
private void textBox1_Leave(object sender, EventArgs e) // trim leading and trailing spaces
{
((TextBox)sender).Text.Trim();
//or if the above is kind of ugly
//TextBox box = (TextBox)sender;
//box.Text.Trim();
}
Beauty is in the eye of the beholder - and as long as it works and is right - im blind :)
edit:
if i want to use this in the class ( for re-using later) is this a suitable method ?
i can see that ((TextBox) sender).Text.Trim(); does the job fine as it is so is it worth recreating the wheel here ?
edit:
doesnt appear to trim btw (oops sry it does it just needs to be assigned back to the .Text) sry lolCode:private void textBox1_Leave(object sender, EventArgs e) // trim leading and trailing spaces
{
((TextBox)sender).Text.Trim();
}
Code:((TextBox) sender).Text = ((TextBox)sender).Text.Trim();
1) read up on the Validating event.
2) if you have a choice between Convert.ToXXX(...) and XXX.TryParse(...), use the latter because it's faster.
3) if you're dealing with references, the 'as' keyword is faster than a (cast).
The job is fine, you don't need anything more.
I always forget also to assign back values. Which is kind of tricky some time...
Especially for string.Insert()!
So he/she should do?
Why is it faster, btw? The "as" also checks if the cast is compatible, but the cast just casts...Code:private void textBox1_Leave(object sender, EventArgs e) // trim leading and trailing spaces
{
TextBox boxStr = sender as TextBox;
boxStr.Trim();
}
they are faster because they won't throw exceptions. if the cast fails, the result is null.
If the cast is completely invalid (like a TextBox to a PictureBox) you won't be able to compile. If it is "just" invalid then it will throw an exception when something goes wrong.
The difference with as is that it will set the pointer to null instead of throwing an exception. Wouldn't as be the equivalent with this?
Code:try
{
a = (type)b;
}
catch(InvalidCastException)
{
a = null;
}
no it's not. you have a try/catch, which uses extra clock cycles.
since i'm bored outta my mind right now, and to prove the vast difference,
here's the outputCode:static void Main(string[] args)
{
List<int> list = new List<int>();
int count = 0;
DateTime start = DateTime.Now;
for (int i = 0; i < int.MaxValue; ++i)
{
try
{
List<int> cast = (List<int>)list;
count += cast.Count;
++count;
}
catch
{
}
}
DateTime finish = DateTime.Now;
Console.WriteLine(finish - start);
int count2 = 0;
DateTime start2 = DateTime.Now;
for (int i = 0; i < int.MaxValue; ++i)
{
List<int> cast = list as List<int>;
if (cast != null)
{
count2 += cast.Count;
++count2;
}
}
DateTime finish2 = DateTime.Now;
Console.WriteLine(finish2 - start2);
}
using 'as' is 3x faster (under release without a debugger).Code:00:00:03.7344467
00:00:01.2500240
Remove the try/catch (and if(!= null) ) and they're equally fast
Well, compiling and running the above I get:
cast: 4.96
as : 2.46
Without the try/get:
cast: 0.83
as : 1.61
Removing the calculations and the check != null for as (so you have only one cast), I get:
cast: 0.83
as : 0.83
So they are the same if you don't have a try/catch. Putting the calculations inside a catch might be unfair, in the sense it will also "try" to catch exceptions for the calculations as well, without a reason.
Finally, without a try/get a cast is 2x faster. So generally I would say if you know what you are doing, like casting a TextBox in an event handler for a TextBox then the cast is faster, because you won't have to try/catch (if the "risk" is acceptable).
Within a try/get they have the same speed
the point of the calculations was to insure that the compiler doesn't optimize, like what happened when you remove the calculations (since the List<int> isn't used for anything, that code is completely removed from the executable, hence, the same speed).
also, the point of the comparison is to have casting with error checking. removing try/catch on the first, or removing != null on the second defeats the purpose.
Code:So they are the same if you don't have a try/catch
Uh, don't you think you're contradicting yourself here? :)Code:the cast is faster, because you won't have to try/catch
Anyway, change the declaration of the list to:
and you'll get a huge difference in your results. Now a real cast is made (the compiler probably optimized it before since you're casting from the same type as you're casting to).Code:object list = new List<int>();
wow, that's surprising! changing it to object yields roughly the same time on my machine. stupid compiler doing stupid tricks!
Err, yeah. I am :D. I always do all kind of stupid mistakes when writing in English. Don't know why...
So what is the verdict? The have the same speed inside a try/catch with Magos "fix"?
Outside one?
the verdict from all data we have so far is that doing a cast with error check results in an advantage *sometimes* for the 'as' method, depending on the amount of information the compiler has. i'm actually surprised that whatever optimization that applied to the 'as' was not applied to the ().