Keskustelu: Ohjelmointikysymykset: VB.NET: [vb2008]Textboxi sekoilua

Moiks,

Olen tekemässä simppeliä yhteenlaskevaa/jakavaa/kertovaa textboxi ohjelmaa oppimismielessä, mutta en saa toimimaan siinä desimaaleja. :/

Tolla val functiolla yhteenlasku toimii mut decimaaleja sehän ei anna..

 ltunti.Text = Format(CDec(tb1.Text, "##,00")) + CStr(tb2.Text) + CStr(tb3.Text) + CStr(tb4.Text)

Kiitoksia jo etukäteen.

Funktio Val vaatii, että desimaalierotin on piste. Funktio CDbl ottaa huomioon Windowsin maa-asetukset. Tällöin jos kieleksi on valittu suomi, oikea desimaalierotin on pilkku.

Seuraava koodi laskee lukujen summan:

Dim a, b As Double
a = CDbl(TextBox1.Text)
b = CDbl(TextBox2.Text)
MsgBox(a + b)

Kiitoksia, toimii loistavasti!!

Mitäs sitten, jos haluan jättää yhden boxin tyhjäksi?

Dim h1, h2, h3, h4, h5 As Double

        h1 = CDbl(tb1.Text)
        h2 = CDbl(tb2.Text)
        h3 = CDbl(tb3.Text)
        h4 = CDbl(tb4.Text)
        h5 = CDbl(tb5.Text)

boxi.text = (h1 + h2 + h3 + h4 + h5)

Eli en laittaisi mitään tohon h5, miten vältän errorin mutta saisin kuitenkin tuloksen?

Yksi ratkaisu on kirjoittaa ennen CDbl-kutsuja seuraava rivi:

On Error Resume Next

Nyt jos tekstikentän sisältö ei kelpaa luvuksi, ohjelma vain siirtyy eteenpäin seuraavalle riville.

Toimii hienosti :)

Sit lisää kysyttävää ois kaavoista, kun en saa toimiin..

Dim vero As Double
        Dim tunti As Double
        Dim ennakko As Double
        Dim palkka As Double
        Dim netto As Double

 vero = CDbl(tbvero.Text)
        ennakko = CDbl(tbennakko.Text)
        palkka = CDbl(tbpalkka.Text)

ltunti.Text = tunti
        lpalkka.Text = (tunti * palkka) 'toimii
        lvero.Text = (palkka / tunti * 100)'toimii


lnetto.Text = (palkka - (vero + ennakko))
' vaikka miten päin ladon noi arvot niin se ei osaa antaa oikeaa arvoa?!?!

Menny päivä pilalle koodatessa innostuin vähän liikaa värkkään tän VB:n kanssa xD

Voisi auttaa, jos ymmärtää mitä lasketaan.

En tiedä mitä lvero ja lnetto ovat mutta, jos esim
tunti = 8h
palkka = 8€/h
ennakko = 10€
vero = 2€
ltunti = 8h
lpalkka = (8h * 8€/h) = 64€
lvero = (8€/h / 8h * 100) = 100 €/h^2
lnetto = (8€/h - (2€ + 10€)) = 8€/h - 12€

hmm...

edit.
Mutta jos
ennakko = 1€/h
vero = 2€/h
lnetto = (8€/h - (2€/h + 1€/h)) = 5€/h

Mutta tuon lveron tulos epäilyttää. Ja kuka ottaa ennakkoa tuntipohjalta. Ja saako sitä ennakkoa enää nykypäivänä kuten vanhoissa suomifilmeissä?

Joo, itsekin lähtisin siitä, että hommahan on todella helppo (2 minuutin) jos tiedetään mitä oikeasti pitää laskea. Nykyisellään monissa noista laskuista ei ole tuon taivaallista järkeä.

Jos teen arvaukset mitä nuo muuttujat voisi tarkoittaa:

Vero = Vero-%
Tunti = Tehtyjen työtuntien määrä
Ennakko = Ennakkoon maksettu rahasumma
Palkka = Tuntipalkka

Tällöin

Bruttopalkka = Tunti * Palkka
Nettopalkka = Bruttopalkka * (1-Vero/100)
Veron osuus = Bruttopalkka * (Vero/100)
Maksettava = Nettopalkka - Ennakko

Todellisuudessahan asia ei ole ihan näin simppeli, vaan työntekijältä vähennetään ennakonpidätyksen (=vero-%) lisäksi myös työttömyysvakuutus ja eläkemaksuja.

Antti Laaksonen kirjoitti:

Yksi ratkaisu on kirjoittaa ennen CDbl-kutsuja seuraava rivi:

On Error Resume Next

Nyt jos tekstikentän sisältö ei kelpaa luvuksi, ohjelma vain siirtyy eteenpäin seuraavalle riville.

Oikea tapa kuitenkin olisi tehdä tarkistus, että onko nuo tyhjiä.

Vai onko "Jos tulee virhe niin unohdetaan se ja mennään eteenpäin" hyvän kuuloinen ohjelmointilogiikka?

Varsinkaan VB.Net:ssä tuo ei ole mitenkään oikea tapa.

Näkisin mieluummin esim:

If Not Double.TryParse(tb1.Text, h1) Then
    'Luku ei kelvannut, TODO: informoi käyttäjää
    Return
End If

tesmu kirjoitti:

Oikea tapa kuitenkin olisi tehdä tarkistus, että onko nuo tyhjiä.

Grez kirjoitti:

Varsinkaan VB.Net:ssä tuo ei ole mitenkään oikea tapa.

Miksi esittämäni tapa ei ole "oikea"?

tesmu kirjoitti:

Vai onko "Jos tulee virhe niin unohdetaan se ja mennään eteenpäin" hyvän kuuloinen ohjelmointilogiikka?

Tämä oli tulkintani mukaan haluttu toimintatapa.

Miksi virhe pitäisi muistaa ja miksi ei saisi mennä eteenpäin?

Jos virhe estää haluttujen laskelmien tekemisen, on minusta aivan selvää, että kuuluu keskeyttää suoritus ja ilmoittaa käyttäjälle, että syötetyt tiedot ovat puutteelliset. Jos kuitenkin laskelmat on mahdollista tehdä tästä huolimatta, niin ainakin pitää varmistaa, että muuttujassa on jokin järkevä arvo kuten nolla. Ei ole oikein hyvä, jos muuttuja sisältää jonkin aivan satunnaisen luvun ja saadaankin aivan kummallisia tuloksia.

Lisäksi on ongelmallista, jos tuo On Error Resume Next on kovin kaukana itse ongelmapaikasta. Voi olla, että joku koodia myöhemmin muokkaava ohjelmoija ei ole tietoinen tästä kikasta ja olettaa, että kaikkiin muuttujiin on syötetty arvo.

Antti kirjoitti:

Miksi virhe pitäisi muistaa ja miksi ei saisi mennä eteenpäin?

No, toki jos tarkoitus on ottaa luvuksi nolla mistä tahansa virheestä niin tuo toki toimii.

Täytyy kuitenkin muistaa, että kysyjä halusi huomioida tilanteen jossa tekstikenttä on tyhjä. Nythän tuo reagoi täsmälleen samalla tavalla jos käyttäjä syöttää vahingossa ylimääräisen merkin niin ettei syötetty luku kelpaa yms. Tuollaisessa tilanteessa käyttäjä voisi kuvitella tuloksen olevan oikea vaikka se ei olekaan.

Toki omakin esimerkkini oli virheellinen, pitäisi olla

If (tb1.Text <> "") AndAlso Not Double.TryParse(tb1.Text, h1) Then
  'Luku ei kelvannut, TODO: informoi käyttäjää
  Return
End If

Antti kirjoitti:

Miksi esittämäni tapa ei ole "oikea"?

No edellisen lisäksi karsastan tuota tapaa samasta syystä mitä Metabolix:kin sanoi, että se tuottaa koodista spagettimaista. Toki tämä on hieman mielipidekysymys.

Jos virheen haluaa vaan "syödä" niin kirjoittaisin kooodin seuraavasti

Try
  h1 = CDbl(tb1.Text)
Catch
  'Jos luku ei ole ok, niin oletetaan aikaisempi arvo (nolla)
End Try

Tuossa olisi etuna, että syöntialue on selkeästi määritelty ja Catch'em'all -lohkossa on sentään kerrottu mistä on kyse.

Toki ongelmana tuossa kirjoitustavassa on, että jos kaikille viidelle tekee saman, niin tulee aika pitkä.

Metabolix kirjoitti:

ainakin pitää varmistaa, että muuttujassa on jokin järkevä arvo kuten nolla. Ei ole oikein hyvä, jos muuttuja sisältää jonkin aivan satunnaisen luvun ja saadaankin aivan kummallisia tuloksia.

VB.Net kuten muutkin .Net -kielet alustaa doublen aina nollaksi jos käyttäjä ei määrittele muuta alustusta.

kayttaja-2499 kirjoitti:

Voisi auttaa, jos ymmärtää mitä lasketaan.

Ja saako sitä ennakkoa enää nykypäivänä kuten vanhoissa suomifilmeissä?

Saa, riippuen tietenkin yrityksestä.

Ohjelman on tarkoitus laskea tunnit, jotka on merkittävissä textboxeihin. Sen jälkeen "laske" painikkeella saadaan tuntien määrä/brutto/tuntipalkka, joka on myös mahdollista merkitä textboxiin.
Ohjelman ei ole tarkoitus olla hirmuisen todenmukaiken vaan karkea arvio tulevasta palkasta. :)

Jos vielä heittäisin vettä myllyyn, niin onko visual basicillä mahdollisuus tallettaa tiedostot tietokantaan tai tiedostoon. Helposti että tällainen nobokin ymmärtää :)