C# blokkere bokstaver i en textbox

[Thurban]

Hei!

Jeg kom opp i IT 1 idag og fikk i oppgave å lage en applikasjon som skal hjele barneskoleelever til å lære å multiplisere. Jeg hår et problem, det er at hvis jeg taster inn noe annet enn tall i textboxen så krasjer programmet. Noen som kan hjelpe meg en måte å unngå dette på?

 

 

Her ser dere feilmeldingen jeg får opp.

 

Tusen takk for all hjelp!

[cronbach alpha]

Du konverterer til en Int, så om du skriver en bokstav eller noe annet kan ikke dette konverteres. Lag en metode som separerer ut tallen du ønsker, eller lignende.

 

Kan være greit om du legger ved koden så kan folk komme med endringer, tips, evt løsning på problemet ditt.

[Lycantrophe]

Feil underforum.

 

--

 

Gå gjennom strengen og sjekk at alle ting er tall (mellom '0' og '9') før du faktisk prøver å gi den til parse.

 

Hvorfor bruker du Int16?

Endret 13. juni 2014 av Lycantrophe

[Gavekort]

Moderatormelding

Tråden er flyttet

Tilbakemelding tas på PM

[Thurban]

Sorry, det gikk nok litt rakt i svingen igår.

 

Kan du si en enkel måte å sjekke at det er tall som tastes inn?

 

Her er koden min.

 

public partial class Form1 : Form

{

Random rnd = new Random();

int ledd1;

int ledd2;

int antRett;

int antForsøk;

public Form1()

{

InitializeComponent();

ledd1 = rnd.Next(0, 11);

ledd2 = rnd.Next(0, 11);

label1.Text = ledd1 + " * " + ledd2;

button2.Visible = false;

}

private void label1_Click(object sender, EventArgs e)

{

}

private void svar()

{

if (ledd1 * ledd2 == Convert.ToInt16(textBox1.Text))

{

label1.Text = "riktig";

label2.Text = ++antRett + " av " + ++antForsøk + " rette";

}

else label2.Text = antRett + " av " + ++antForsøk + " rette";

label3.Text = "Rett svar er " + Convert.ToString(ledd1 * ledd2);

}

private void button1_Click(object sender, EventArgs e)

{

svar();

button2.Visible = true;

}

private void button2_Click(object sender, EventArgs e)

{

ledd1 = rnd.Next(0, 10);

ledd2 = rnd.Next(0, 10);

label1.Text = ledd1 + " * " + ledd2;

textBox1.Text = "";

button2.Visible = false;

}

}

Takk for svar!

[Lycantrophe]

Jeg har allerede gjort det.

 

Gå gjennom strengen og sjekk at alle ting er tall (mellom '0' og '9') før du faktisk prøver å gi den til parse.

[Thurban]

Kan du hjelpe meg med noen funksjoner som kan gjøre det?

 

Jeg kunne vel brukt char, men tenkte ikke på det når jeg begynte.

[Lycantrophe]

TryParse er det vel en som heter. Alternativt kan du skrive en selv.

[Thurban]

private void Form1_KeyDown(object sender, KeyEventArgs e)

{

if (e.KeyValue >= 48 && e.KeyValue <= 57)

textBox1.Text = textBox1.Text + (char)e.KeyValue;

else textBox1.Text = textBox1.Text;

}

Burde ikke dette funke?

[Lycantrophe]

private void _Keydown( object sender, KeyEventArgs e ) {
    if( e.KeyValue < '0' || e.KeyValue > '9' ) 
        return;
    box.Text += (char)box.KeyValue;
}

synes jeg er en bedre formulering (note: men jeg kan egentlig ikke C#).

 

Alternativet er å post-validere - ta villkårlig input, men gi en feilmelding dersom, når du scanner strengen, finner noe annet enn tall.

 

C# har regex:

 

class {
    private static Regex is_number = new Regex( "^\d+$" );
}

test med:

 

is_number.IsMatch( text );

Dersom denne returnerer false - gi error.

[snippsat]

Vil tro at feilbehandling(try,catch) skal være greit.

try
{
    if (ledd1 * ledd2 == Convert.ToInt16(textBox1.Text))
}
catch(System.FormatException)
{
    MessageBox.Show("Only numeric input");
}

Hvordan C# ser på "Exception handling",

kan sikkert en C# person svare beredere på.

 

Vet at i mange språk så er dette ikke så populært og bruke.

I Python som jeg bruker en del er dette veldig vanlig og anbefalt.

Write Cleaner Python: Use Exceptions

Many programmers have had it drilled into their head that exceptions,

in any language, should only be used in truly exceptional cases.

They're wrong.

The Python community's approach to exceptions leads to cleaner code that's easier to read.

And that's without the monstrous hit to performance commonly associated with exceptions in other languages.

 

[Thurban]

Brukte try-catch, det er det jeg lettest kan forklare på eksamen.

Tusen takk for alle svar!

[etse]

Exceptions er ikke den riktige måten å gjøre det på i .NET, det er en python-ting. I .NET verden skal exceptions kun brukes i tilfeller hvor uforventede feil skjer. Men i dette tilfelle kan man nesten forvente at enkelte ganger vil man kunne få tekst som ikke er gyldige tall - og da skal det helst håndteres uten exceptions.

 

Du har allerede fått nevnt TryParse, som kan være en god måte å gjøre dette på.

 

Denne funksjonen sier ifra om hvor vidt den klarte å parse et tall.

int tall;
if(Int32.TryParse(textBox1.Text, tall)) {
    // Her kommer du kun om parsingen skjedde riktig.
}

Edit: Ser jeg brukte funksjonen feil. Rettet opp i det. Endret 15. juni 2014 av etse

[Lycantrophe]

Det gir mer mening i python fordi alle funksjonskall og slikt er megadyrt, i tillegg til at det kan oppstå allverdens feil på grunn av typing. I C#, som er statisk, er det ingen grunn til å bruke exceptions som control flow og input validation (som dette er et tilfelle av).

 

--

 

Snodig interface - hvordan kan en int være null? C# har primal types. TryParse er én løsning, pre-parse validation er en annen. Jeg foretrekker den siste, men det er mulig C# idiomatics sier noe annet.

 

http://msdn.microsoft.com/en-us/library/f02979c7(v=vs.110).aspx

 

Så litt annerledes:

 

int result;
if( !Int32.TryParse( box.Text, result ) ) {
    // error
}
// Result er gyldig.

edit: digger all ninjamoddingen som skjer her.

edit2: etse: der ja. :-D

 

Exceptions er en dårlig løsning and you should feel bad.

 

Lykke til med eksamen.

Endret 15. juni 2014 av Lycantrophe

[Malvado]

edit: digger all ninjamoddingen som skjer her.

edit2: der ja. :-D

 

 

Noen innlegg har blitt fjernet!

Husk å holde en høflig tone , hvis ikke stikker Ninjaene innom og bruker katanaen, hva som forsvinner er avhengig av humøret...

[Thurban]

Som sagt takk for alle svar! Problemet med det dere sier nå er at jeg, som ikke er en toppkarakterfyr, ikke klarer å forklare det dere sier, jeg kan ikke så mye. Try-catch eller exeptions som dere sier er noe jeg har lært og kan forklare litt om.

[Lycantrophe]

Du vet, akkurat her er det helt greit å si "jeg spurte om internett og fikk tipset at [løsning] var en fin måte så jeg bare brukte det".

[GeirGrusom]

Som sagt takk for alle svar! Problemet med det dere sier nå er at jeg, som ikke er en toppkarakterfyr, ikke klarer å forklare det dere sier, jeg kan ikke så mye. Try-catch eller exeptions som dere sier er noe jeg har lært og kan forklare litt om.

try/catch er ikke så vanskelig. Det er en slags elendig pattern matching dersom et unntak i koden skjer inn i en try-block.

 

Her er et eksempel:

http://csharppad.com/gist/e8f2f098448291158c73

 

Grunnen er at koden inne i try-blokken vil kjøre helt til et eller annet kaster en exception. Deretter vil den forsøke å matche exception typen så tett som mulig (Så dersom det blir kastet en ArgumentNullException vil den foretrekke en catch(ArgumentNullException) fremfor catch(ArgumentException) eller catch(Exception) men tar den som passer nærmest (ArgumentNullException arver fra ArgumentException som avrer fra Exception)

 

Kode i finally blir kalt uavhengig om en exception skjer eller ikke, noe som er nyttig for å rydde opp etter at koden er blitt kalt.

 

Typisk bruksområde for catch er logging og dersom en faktisk kan redde koden fra en exception. Men exception skal ikke brukes for kontrollering av applikasjonsflyten. Grunnen til dette er at en exception er prosessormessig ekstremt dyr. Dette fordi en throw vil kreve at runtimen stopper opp og blar seg oppover i operasjonsstacken for å samle opp informasjon om hva som gikk til helvete og danner en stack trace fra dette og rydder opp i minnet. En såkalt stack rewind.

 

Exceptions skal kastes dersom programmet ikke har noen forutsetning for å unngå problemet. Eksempler på dette er timeout fra en nettverkstjeneste eller en annen ressurs som ikke lenger er tilgjengelig.

 

FormatException kan i de fleste tilfeller unngås, eksempelvis dersom du har regex-sjekket at tallet som kommer inn er et integer vil jeg påstå det er anbefalt å bruke int.Parse fremfor TryParse. Grunnen er at dersom parsing feiler av en eller annen grunn er det på grunn av en programmeringsfeil tidligere i koden som må rettes, og da er det langt bedre å få en exception enn at programmet feiler i det stille, og i verste fall bruker default(int) som er lik 0 (noe int.TryParse faktisk vil sette verdien til).

[delfin]

*poof*, svar gitt...

Endret 3. juli 2014 av pifler

[Oyand]

"Late in".. Kanskje noe referanse i det her: http://msdn.microsoft.com/en-us/library/ms229644(v=vs.90).aspx

Endret 28. juli 2014 av Oyand