Nekem pl. dátummal volt problémám mer a 2000 és az XP eredeti beállításai mások a dátumra és az SQL adatbázis is úgy használta ahogy az adott oprendszer használta. Így amit XP alatt írtam 2000 alatt nem működött amíg a 2000-nél is be nem állítottam ugyanúgy a dátum formátumát. Az más kérdés, hogy utána már megírtam úgy a progit, hogy ha nem volt átállítva a 2000 akkor is jó legyen, de én is beleszaladtam ilyesmibe.
szoval a teruleti beallitassal lenne a gond? bocs, de ez hulyeseg!!
Ha valaki ismeri a vb-t, akkor tudja, hogy ha a tizedesvalaszto nem a teruleti beallitasnak megfelelo, akkor el sem fogadja.
tehat peldaul az ilyen sorok hibas bevitel eseten, mint
dim szam as single
szam = csng(textbox1.text)
(ez csak egy pelda volt) egy "Type mismatch" kivetelt okoznak, a hibakodja azt hiszem 5
De ha szeretned, hogy adjak kodot ami az ilyen eseteket kikuszoboli, szoljal es szivesen segitek: kirakom a kodot ha kered
Igen, én spec azért gondoltam minden beállítás átállítására, mert erre a win telepítője is lehetőséget ad, és szvsz egy magyar felhasználó angol windowson telepítéskor a magyar területi beállításokat használja.
Igazatok van ! Basszus a az ő hozzászólását észre se vettem. A rövid egysorosa elsikkadt a többi között. Hogy lehet pontokat visszavonatni? Mert bandix megérdemelné !
Különben bunkóság volt magamnak adni a pontot, mert nyilván több infom volt mint nektek, de ha valaki egy szóval megemlítette volna hogy nézzem meg hogy pont vagy vessző, akkor rég túl lennénk az egészen
A másik windows amin az alkalmazás készült win98 mint említettem, ezen agépen pedig 2000 fut. Egy dolgot nem említettem asszem ezzel kapcsolatban és ezért elnézést kérek, hogy ezen angol windows van. És mivel angol windows, ezért náluk TIZEDESPONT kell és nem pedig a magyar tizedesvessző. És én úgy gondolom, hogy a nyelvnek megfelően kezeli a számokat a windows. Az angol pontot szeretne, a magyar vesszőt. Vagy tévedek?
Nos mindenesetre elnézést kérek hogy nem mondtam a nyelvet, kiment a fejemből.
A lényeg hogy pontot írva a beviteli mezőbe működik. Egy kérdésem lenne, nem tudjátok hogy tudom ezt a problémát kikerülni, tehát hogy pontot és vesszőt is elfogadjon mindkettő?
A legegyszer-bb m=dja, hogy leellen[rizd, hogy a számbevitellel vagy a számolással van a gond, hogy a kezdőértékeket nem beolvasod, hanem a progiban rögzíted és a végeredményt iratod csak ki. Ha ekkor egyezik, akkor a bekéréssel van a baj. Vagy az amit írtam, vagy valami más .
En nem ertek a VB -hez, csak probaltam a hbajavitasgoz tanacsokat adni...
A VB debuggeret mennyire ismered?
Valoszinuleg ezek a gombok mukodnek MS Visual Basic -ben is:
F10 -> lepesenkenti vegrehajtas
Ctrk+F10 -> ugras arra az utasitasra, amelyiken a kurzor all
Ha az egerrel egy valtozo fole mesz, akkor latszodnia kell a valtozo ertekenek
De hasznalhatod a watch ablakot is.
De mondom, en nem ismerem a basicet, egyszer lattam eletemben az MSVB -t, lehet, hogy teljesen mashogy mukodik.
És erre csinálja azt, hogy a tizedestörttel beírt számoknál a tizedesvesszőt eltolja a szám végére.
De ha az a hiba amit most írok, akkor megeszed a kalapod .
Nem lehet hogy az egyik windóznak (gondolom az angolnak) nem tizedesvessző kell, hanem tizedespont?
Bár szerintem ekkor nem kéne tudnia értelmezni a beírt sztringet számként, deki tudja VB ben hogy van (én nem). Talán ezreselválasztónak érvényes a , használata akkor is ha nem az a tizedes elválasztó.
Végülis ezt csináltam eddigis amit mondtál sali_t. Azért biggyesztettem oda kódba minden adatbevitel után hogy Text3.text = we, hogy képet kapjak arról, hogy az lett e a változó , amit én akartam. És erre csinálja azt, hogy a tizedestörttel beírt számoknál a tizedesvesszőt eltolja a szám végére.
Az a kérdés merült fel bennem, hogy a textbox beálításaiban nem lehet a hiba?
Vagy a változó beállításaiban ?
Vagy mivel csak az exe-t hoztam át a másik gépre meg a msstdmft.dll-t,( mert a setup package se működött rendesen ), nem lehet hogy még valami fájl hiányzik a windows-nak?
Nagyon megköszönném a segítséget, mert ez basszus a fizika tanári diplomamunkám mellé lenne illusztráció.
Én a te helyedben a kiiratnam a szamitas reszeredmenyet tobb ponton is. Ahol nem az van egy valtozoban, mint amire te gondolsz, ott van a bibi.
Persze mindig ugyanazokkal a bemeno ertekekkel szamolj (ha nem akarod mindig begepelni a bemeno adatokat, esetleg a program elejen legyen allitsd be a mezoket)
Irasd ki a reszeredmenyeket mindket gepen, es hasonlitsd ossze azzal, amit te szamoltal papiron szamologeppel.
(persze a VB beepitett debuggeret is hasznalhatod, az egyszerubb/jobb/kenyelmesebb, mint kiirogatni minden valtozot, de ahhoz mindket gepen rajta kell lennie a VB-nem)
Nos közben a fenti kóddal tettem egy próbát, mivel ez már javított kiadás, és ez azt csinálja, hogy ha a textboxba 1-nél kisebb számot írok be akkor automatikusan 1-re ugrik we és wm esetében is. Na most a user által megadandó értékek:
we és wm kb. 0-10 és kb 0,1 vagy 0,01 pontosság
Ja és a szél cimke, amire az On error sorok hivatkoznak
Fiúk, mielőtt összevesznétek, mellékelném a forráskód egy részletét.Meg talán ebből kiderül a hiba. A dolog lényege, hogy néhány textboxból kérek adatot, azokkal számolok ezt-azt és azt később kiiratom valahova. A textbok data mezőjébe number van beállítva és asszem 4 tizedesejegyre. ( szerintetek mennyire érdemes és mi van ha a user mást ad meg ? )
Private Sub Command2_Click()
' A számítás a 2. szakaszra '
Dim we As Double
Dim wm As Double
Dim va As Double
Select Case Combo2.Text
Case "Astir"
A1 = -0.00245 ' Vigyázat: m/s -os sebességre érvényesek ! '
A2 = 0.09945
A3 = -1.63211
Case Else
A1 = 0
A2 = 0
A3 = 0
End Select
'A látszólagos átlagos termikerősség'
we = Text3.Text
On Error GoTo szel
If we < 0 Then we = 0
Text3.Text = we
' A tényleges közegmerülés '
wm = Text4.Text
On Error GoTo szel
If wm < 0 Then wm = 0
Text4.Text = wm
z = (-A3 + we + wm) / -A1
v = Sqr(z) ' A legelőnyösebb sebesség '
If v < 20.83 Then Text5.Text = 75 Else Text8.Text = v * 3.6
w = A1 * v ^ 2 + A2 * v + A3 'A merülőseb '
va = v * we / (-w + wm + we) 'Az átlagseb '
1. Matematikai muveletnel: van egy valtozod "a", ami rendelkezik valamilyen hibaval (pl. a valtozo tipus pontosssaga 10^-5 es mi megadunk 10^-10-en pontossagu erteket, ekkor valamilyen uton-modon (kerekites, vagas) belepreselodik a 10^-5 intevallumba). Van egy "b" es egy "c" szamod szinten valamilyen hibaval. Nos ha ezekkel a szamokkal muveleteket vegzel akkor lesz egy vegeredmenyed, ami a pontos ertektol a muvelet hibajaval fog elterni. Ez a hiba ugyanakkora lesz (a/b)*c es (a*c)/b -nel.
2. Tetelezzuk fel hogy az eredmeny nagyon kicsi szam 1^-22 -en, amit bele akarsz preselni egy valtozoba, aminek a megjelenitesi pontosssaga 10^-5 -en akkor a valtozo erteke 0 lesz(kerekites,vagas). Ha viszont az eredmenyt beszorzod elotte 10^20 akkor a valtozo erteke 1^-2 ami 0.01.
Erteleme van kiprobalni, hisz majdnem jo volt az amit irtal, en csak helyesbitettem! Hamarabb lesz ez a hiba forrasa, mint a windows nyelvi elteresei!
Hasznalj zarojeleket mert "a/b*c helyett a*c/b" nem igazan egyertelmu. Valamint, amit leirtal nem teljesen igaz! (a/b)*c es (a*c)/b hibaja ugyanaz, mivel a relativ hiba szorzasnal ill. osztasnal megegyezik!
Az a lenyeg, hogy a matematikai szamitas minel egyszerubb legyen, minel kevesebb muvelettel! Igy lesz legkisebb a szamitasi hiba. Valamint azokat az ertekeket miket nem muszaj ne ments valtozoba es ugy illeszd a kepletbe, hanem rogtona kepletbe kell irni(kerekitesek hibai kisebbek lesznek).
Azt viszont vegkepp nem ertem, hogy mikent kulonbozhetnek matematikai szamitasok eredmenyei OP rendszer nyelvetol!
A nagyon kis szamok beszorzasa jo 5let lehet, csak nem 2^20-al szorozd hanem 10^20-al, mivel gondolom 10es szamrendszerben szamolsz:)
Bocs hogy nem említettem, hogy más gépen történt a dolog. Megpróbálom átnézni a kód hibás részét, és megnézem az osztások szorzások helyzetét. De lenne még egy kérdésem, lehet hogy a beviteli mező data type ja, okozza pl. a hibát vagy más változó típust kéne megadnom?
Kezdhetted volna azzal, hogy nem ugyanazon a gépen produkál eltérő eredményeket.
Az természetesen könnyen lehetséges, hogy az egyik gépen más pontossággal számol lebegőpontos számokkal az FPU, mint a másikon. Szerintem ez valószínübb oka a "hibának", minthogy a windózaid más nyelvűek .
Próbáld ki ugyanazon a gépen a 2 windózzal. Gondolom ilyen gép nincs a közeledben, de azért próbálj meg hozzáférni egy ilyenhez, és írd meg ott mit kaptál.
Ja mégvalamit kipróbálhatnál így látatlanba is:
Ha valahol osztasz a számítások során, azt told ki a számolás végére, amennyire csak lehet. Azaz pl a/b*c helyett a*c/b.
Vagy ha ez már megvolt, akkor próbáld meg a számolásban előforduló kis számot felszorozni jó sokkal (mondjuk 2^20), és nézd meg így mekkora a különbség a 2 végeredmény között. Ez ugyan nem oldja meg a problémát, de talán kiderül belőle 1smás.