Mina vb-program skriver decimalkomma när de skickar ett
Single-värde til en textruta. Men om programmet ska
läsa ett single-värde från textrutan fordras decimal-punkt.
Kan man ställa om VB till att skriva decimalpunkter isället
för komma?
Jag använder textrutor för att mellanlagra värden.
VB6.

Det är troligtvis inställningarna i systemet som gör det, jag är inte säker på om det finns någon inställning för det i VB dock.

Du skulle kunna använda Replace(Text1.Text, Chr(44), Chr(46)) för att ersätta kommatecken med punkter, förutsatt att textrutan heter Text1 (annars är det ju bara att ändra naturligtvis).

Varför mellanlagrar du värden för övrigt? Det är bättre att mellanlagra i exempelvis en ny variabel..

mvh
Christian

Tackar
Jag ställde om i kontrollpanelen till att använda punkt som
decimaltecken och då funkar det. Men visst, det är nog
bättre att använda en variabel deklarerad med Static för att
mellanlagra decimaltal.

Att ställa om i kontrollpanelen är ingen bra ide.
Att använda Static är ingen bra ide.Det blir bara onödigt krångel med stacken

I moderna språk tex Vb.net finns inte Static längre,
det blir onödigt mycket efterarbete att porta om.

Har skrivet det tidigare det gäller att hålla en konsekvent linja.
Använd alltid (.) punkt som decimalavskiljare i VB.
Använd Val för att omvandla strängar.

Woops nu hände det igen jag postade 2 ggr.

Med Replace kan man se till att alltid få decimalpunkt
oavsett systeminställnig. Tack båda två
//Tor Erik

Det kräver lite eftertankte att internationalisera ett program genom att ersätta komma med punkt o s v. Tänk på att vissa länder använder punkt som kommaseparator och komma som tusentalsavgränsare och vice versa. Bättre är att använda funktioner som Cxxx() i VB som stödjer internationella inställningar i stället för att använda Val() eller liknande. Ska man göra det manuellt med Replace så måste man verkligen tänka igenom vad man gör, annars kommer programmet inte att fungera korrekt i alla regioner...

Jag har en annan stånd punkt. VB mfl har naturligt .(punkt) som decimalavskiljare.
Där för är det klokast att se till att alla uträkningar i funktioner mm sker med .(punkt)
Alla inmatningar från användare i TextBoxar bör ha den kod i KeyPress eventet.
<code>
Private Sub Text1_KeyPress(KeyAscii As Integer)
'Normalt bör du tillåta dessa tecken tillsammans med siffror
'BackSpace, Tab, Enter, Komma, Minustecken, Punkt och 0 - 9
Select Case KeyAscii
Case 8, 9, 13, 44, 45, 46, 48 To 57
' Tillåt
'här byter du sida på 44 och 46 efter önskemål ,komma(,) punkt(.)
If KeyAscii = 44 Then KeyAscii = 46
' så här bör det vara konsekvent
' If KeyAscii = 44 Then KeyAscii =46
Case Is = 22 'användaren klistrar in Ctrl+V
If IsNumeric(Clipboard.GetText) Then _
Text1.Text = Replace(Clipboard.GetText, ",", ".")
Clipboard.Clear
Case Else
KeyAscii = 0
End Select
End Sub
</code>
Internationella inställningar som tex vårt ,(komma) bör endast användas när
man presenterar ett resultat i tex en Label
Det är mycket bökigt att genomföra komplicerade uträkningar i långa av varandra
beroende kedjor om man inte konsekvent använder .(punkt)

Men när man presenterar ett resultat så använder en sträng, eller hur?
Du använder väl knappas strängar när du gör "komplicerade beräkningar i långa av varandra
beroende kedjor", utan snarare heltal eller decimaltyper. Då behöver man ju inte tänka på punkt eller komma överhuvudtaget.

Det är bara i omvandling sträng->tal och tal->sträng som det behövs. I båda fallen kan man använda Cxxx som automatiskt hanterar internationella inställningar. Ser inte problemet.

Som jag skrivit innan, håll en konsekvent linje.Dom flesta felen blir när man
använder input från TexBoxar den ena användaren skriver , den andra .
En lite kod som du kan använda för att kolla vad användaren har för separator
<code>
Option Explicit
Dim UserSep As String
Private Sub Form_Load()
Dim sepCheck As String
'Här gör jag en test om användaren har
'decimaltecken punkt ( . )
sepCheck = Format$(1, "0.0")
If InStr(sepCheck, ",") Then
UserSep = ","
Else
UserSep = "."
End If
MsgBox UserSep
End Sub
</code>

>Det är bara i omvandling sträng->tal och tal->sträng som det behövs.
Jovisst men det räcker att enda sträng innhåller .(punkt) när det skall vara ,(komma)och viseversa
Så skiter sig hela uträkninen i många led,som kan vara jätteknepigt att debugga
Strängarna kan komma från databaser av olika typ .Det är en djungel "Out There"
Om du skall betraktas som seriös programmerare måste du ha störtkoll på alla
strängar som innehåller decimala tal,det oberoende av var strängen kommer från. !

Niklas gör det så enkelt för sig som att säga använd Cxxx(string) så fixar det sig.
Testa denna kod. Jag skriver in 1,234 i Text 1 o 2 sedan multiplicerar jag de båda.
Efter mig kommer en amerikan till min dator och skall göra samma sak han skriver 1.234

Vad blir resultatet . ?
Algoritmerna måste behandlas lika oberoende på vem som sitter vid datorn !
<code>
Option Explicit
Private Sub Command1_Click()
' 1.234 1.234
'eller 1,234 1,234
MsgBox CSng(Text1.Text) * CSng(Text2.Text)
End Sub
</code>

Om amerikanen skriver in "1.234" på en dator med svenska regionala inställningar så ska en av två saker hända :

1. Om de regionala inställningarna säger att tusentalsseparatorn är punkt så ska talet tolkas som 1234 (ettusentvåhundratrettiofyra).

2. Annars (om tusentalsseparatorn är t ex mellanslag eller inget alls) så har användaren gjort fel och ett felmeddelande skall visas. Detta ska INTE automatiskt konverteras till "1,234"...

mmm det är också en åsikt,vore det inte bättre att räkna rätt och inte komma med pekpinnar ? .
Fö tycker jag att anglosaxerna har rätt decimalavskiljare skall vara lika i hela världen dvs .(punkt)

Men ok får Vi hela världen att acceptera ,(komma) så tar Vi det.Det är ju sannslöst i denna
globaliserade värld inte kan ha samma sätt att behandla elementär matematikdata.

En sak är säker om du och jag skulle konkurerar med ett program som räknar mycket
skulle mitt sätt att behandla matematik på dator vinna skyhögt.

Folk avskyr en massa meddelande som inte har nån vettig funktion.

Well Sven, du säger att mitt program skulle räkna fel (vilket inte stämmer eftersom mitt program skulle kräva rätt formaterad indata) men i själva verket är det ditt program som skulle få problem. Om användaren matade in :

1,234.567

(där regionala inställningarna är inställda så att tusentalsavskiljaren är kommatecknet och decimaltecknet är en punkt) så skulle ditt program konvertera det till :

1.234.567

och denna sträng representerar vilket tal? 1.234567? 1234.567? 1234567? Runtime error?

Det enda sätt som är hållbart att hantera tal är att anpassa sig efter regionala inställningar.

>1,234.567
Djä bull men Ok då får man väl även göra ett filter för detta.
Finns väl ingen som skriver så på en räknedosa eller i mattematiskt program

Som jag skrivit innan , det är helt Ok när man presenterar resultat i tex Label
men inte i inmatning av reella data. Använd alltid .(punkt) i mattematik på PC !

Man får ta hand om alla "knäppgökar" som skriver enl. Per

Det blir Replace(String,",","") 'Ok moster Agda:s 1,234.567 filtrerar Vi så här.

Men du har rätt Per det finns okunniga överallt det gäller att förutse dom.

Sven.
Det jag och Per försöker säga är följande:
1. Cxxx är en inbyggd funktion i VB, som är designad så att den omvandlar en sträng till ett tal enligt de nationella inställningar som finns på den datorn man använder, eller ett tal till en sträng med samma princip.
2. Har man en svensk inställning så fungerar Cxxx- konverteringen enligt svensk variant, har man en brittisk funkar den enligt brittisk standard, etc.
3. Så fort man har omvandlat värdet till ett tal uppstår aldrig problemet med att omvandla talet till endera standard.

Har man inställningen "Sverige" så kommer man troligtvis förvänta sig att program fungerar enligt svensk standard, dvs med decimalkomma.