I'm trying to save variables into text files and the Czech typographic rules drives me crazy.
The program I'm tuning is dedicated to work on Czech localized computers where decimal comma is used but the VB is working with normal, standard decimal dot.
When loading files "US" decimals are loaded correctly and showed as Czech decimals. In TextBoxes "Czech" decimals are required. My problem is that program generates Czech decimals and require the "US" ones.
How can I force VB program to read comma as decimal sign instead of delimiter or how to export data with dots instead of commas?
Yes I can load 123,456 as a=123 and b=456 and then return value as a + b/1000 but is there more elegant solution?
Pick the right function.
Val, Str will always use US settings (dot as decimal)
CDbl, Format will take account of the regional settings.
It's all in the manual section on international programming.
Your trouble might be due to use of the Val function; that isn't international. The help text recommends the use of CDbl when converting from strings to numbers.
Thanks for your advices, I'm not sure if I did something wrong, but I've obtained only errors (ie. type mismatch) or "Czech" decimal comma.
I've tried 'Got slapped? Slap him harder!' aproach with this code:
Dim PpP As String, SaveFile As Integer
PpP = Form1.TxtA10.Text & " " & Form1.TxtA11.Text
PpP = Replace(PpP, ",", ".")
Print #SaveFile, PpP
edit:
something means trying those functions at the output, not at the input. (like trying Double as String parameter).
This code:
Input #1,TempString
Form1.TxtA10.Text = CDbl(TempString)
works aswell.
Try,
Format$(CDbl(Text1.Text), "#,##0.00")
Related
I have installed windows 10 64 bit with french localization, and installed Microsoft Office, including ms access.
I have this problem when inserting values to Ms Access 2002 table into Currency field, as the value am trying to insert is a decimal value represented through string, with "." operator as the Decimal Separator, as am getting the error message "datatype mismatch in criteria expression".
Is there a way to tell Ms Access to use the "." as the decimal separator instead of "," and the "," as the Thousands Group Separator instead of " ", as replacing the decimal string value of "." character occurrences to "," characters isn't an option as i have thousands of strings that will need accordingly to have the replace function called upon,
What have tried so far, and didn't bring any results, is:
1. Change the decimal symbol, from control panel, regional and language settings from "," to ".".
2. Switching from OleDB to ODBC, and specifying "Locale Identifier" value to 2057, indicating en-GB, in the connection string.
Please Advise,
Thanks in advance.
First change the comma to a character other than a period ("#")
Then change any remaining periods to a comma.
Lastly change "#" to a period.
dblValue = Replace(Replace(Replace(OriginalValue, ",", "#"), ".", ","), "#", ".")
You mentioned that the values you are passing to access are strings. Why can't you format those strings in a way you wish them to be, and pass the data to MS access?
You did not mention anything specific, so I assume you work in the notepad.exe. In the above program, format the strings you wish to the values you need by replacing appropriate locale symbols to ones you need. After that pass the strings in some way you "better know how" to the MS access.
If you have a millions or billions of rows(columns?!) in your data, you can do a mass replace in the program of your choise(notepad.exe). This is as simple as that.
Use Str, it will never fail:
Str(AnyDecimalValue)
For a generic solution, use my function CSql.
Edit:
The other way around - to convert a text expression to a decimal - use Val:
Val(TextNumberWithDecimalDot)
Each computer reads the decimal in a different way. There are computers that use dots and others use commas to read decimals. I have a database that uses commas as decimals. Is there a code that I can use so that every computer that uses my application reads the comma as decimal without having to make changes to the settings on each computer.
Imports System.Globalization
....
Private DecimalSepPt As Boolean ' . is decimal separator and not ,
....
DecimalSepPt = (CultureInfo.CurrentCulture.NumberFormat.NumberDecimalSeparator = ".")
this will tell you if the country of the PC uses a . or a ,
I used it like this:
If Not DecimalSepPt Then ' if they use the ,:
Stack.Add(CStr(num).Replace(","c, "."c))
Else
Stack.Add(CStr(num))
End If
to be sure that CDlbl(..) results in the expected number
I'm trying to find a solution to print superscript using ZPL.
Example, if I have this string of ZPL:
string ZPLString =
"^XA" +
"^FO50,50" +
"^A0N50,50" +
"^FDHello, World!^FS" +
"^XZ";
sendToZebraPrinter(ZPLString);
Since there aren't any superscript characters, I could send this to my printer without issue. But if I wanted to use this string:
string ZPLString =
"^XA" +
"^FO50,50" +
"^A0N50,50" +
"^FDe = mc²^FS" +
"^XZ";
sendToZebraPrinter(ZPLString);
The superscript won't print natively. I think I need to access an international character set or something but I'm not sure how to do this, especially if I only need it for the one character. Do I need to change my entire character set, or do some sort of "replace" on it?
Note, we are generating ZPL code manually and shooting it directly at the printers (unfortunately this is our system), bypassing any drivers or 3rd party dev components of any kind.
Mark's answer gave me exactly what I needed to solve my issue. Here is additional information to further clarify the solution:
To use the hex code in your data you need to prefix the ^FD command with ^FH_ (where ^FH tells the printer the data in ^FD will contain hex values and the _ defines the hex code identifier so it knows which data is or is not defined as a hex code instead of standard text)
I got this to work immediately exactly as you mentioned. Then testing against additional printers I found (but not sure why) that I didn't need to actually send in the ^CI13 to specify code page 850. The ² appeared on all printers even when I didn't send the ^CI13
In my .NET application, for some reason the ² didn't map to the correct hex code that the ZPL code page expected (the .NET app converted ² to hex code b2 instead of fd, but for most standard characters converted to the same code as the ZPL map) so in my application I created a conversion table where any character I defined in my table I mapped to the ZPL hex code and any character I didn't define I allowed to remain as converted by the application).
I'd never used information from the non default code page and I didn't realize when using ^FH that you could mix standard text with hex (I thought if you used ^FH that "all" of the information in ^FD had to be hex). So the information Mark provided let me right down the correct path.
The final example to solve the problem, using the information Mark provided, is:
string ZPLString =
"^XA" +
"^FO50,50" +
"^A0N50,50" +
"^FH_" +
"^FDe = mc_fd^FS" +
"^XZ";
sendToZebraPrinter(ZPLString);
Try using ^CI13 to select code page 850, then use _fd in your string for the superscripted 2. The underscore is used to designate a hex character.
I'd like to create a .properties file to be used in a Java program from a VBScript. I'm going to use some strings in languages that use characters outside the ASCII map. So, I need to replace these characters for its UTF code. This would be \u0061 for a, \u0062 fro b and so on.
Is there a way to get the UTF code for a char in VBScript?
VBScript has the AscW function that returns the Unicode (wide) code of the first character in the specified string.
Note that AscW returns the character code as a decimal number, so if you need it in a specific format, you'll have to write some additional code for that (and the problem is, VBScript doesn't have decent string formatting functions). For example, if you need the code formatted as \unnnn, you could use a function like this:
WScript.Echo ToUnicodeChar("✈") ''# \u2708
Function ToUnicodeChar(Char)
str = Hex(AscW(Char))
ToUnicodeChar = "\u" & String(4 - Len(str), "0") & str
End Function
I am maintaining an app for a client that is used in two locations. One in England and one in Poland.
The database is stored in England and uses the format £1000.00 for currency, but the information is being gathered locally in Poland where 1000,00 is the format.
My question is, in VB6 is there a function that takes a currency string in a local format and converts to another, or will I just have to parse the string and replace , or . ?
BTW I have looked at CCur, but not sure if that will do what I want.
The data is not actually stored as the string "£1000.00"; it's stored in some numeric format.
Sidebar: Usually databases are set up to store money amounts using either the decimal data type (also called money in some DBs), or as a floating point number (also called double).
The difference is that when it's stored as decimal certain numbers like 0.01 are represented exactly whereas in double those numbers can only be stored approximately, causing rounding errors.
The database appears to be storing the number as "£1000.00" because something is formatting it for display. In VB6, there's a function FormatCurrency which would take a number like 1000 and return a string like "£1000.00".
You'll notice that the FormatCurrency function does not take an argument specifying what type of currency to use. That's because it, along with all the other locale-specific functions in VB, figures out the currency from the current locale of the system (from the Windows Control Panel).
That means that on my system,
Debug.Print FormatCurrency(1000)
will print $1,000.00, but if I run that same program on a Windows computer set to the UK locale, it will probably print £1,000.00, which, of course, is something completely different.
Similarly, you've got some code, somewhere, I can't tell where, in Poland, it seems, that is responsible for parsing the user's string and converting it to a number. And if that code is in Visual Basic, again, it's relying on the control panel to decide whether "." or "," is the thousands separator and whether "," or "." is the decimal point.
The function CDbl converts its argument to a number. So for example on my system in the US
Debug.Print CDbl("1.200")
produces the number one point two, on a system with the Control Panel set to European formatting, it would produce the number one thousand, two hundred.
It's possible that the problem is that you have someone sitting a computer with the regional control panel set to use "." as the decimal separator, but they're typing "," as the decimal separator.
What database are you using? And what data type is the amount stored in?
As long as you are always converting from one format to another, you do not need to do any parsing, just replace "." with "," or the other way around. You may need to remove the "£"-sign as well if that is stored in your string.
There's probably a correct answer dealing with culture objects and such, but the easiest way would be to taken the input from the polish input, and replace the , with a ., and then store it in your database as type "money" or "decimal". If you know they (possibly configurable per user) are always entering numbers in either Polish or English, you could have a function that you run all the input numbers through to convert the string to a proper "decimal" typed variable. Also, for display purposes you could run it through another similar function to ensure that the user always sees the number format they are comfortable with. The key here is to switch it to a decimal as soon as you get it from the user, and only switch it back to a string at the last step before sending it out to the user.
#KiwiBastard yes i would think so. Are you storing your amount in an "(n)varchar" field or are you using a currency/decimal type field? If the latter is the case, the currency-symbols and separators are added by your client, and there would be no need to replace anything in the database.