Is there any provision in WinAPI or otherwise for using ini files (or similar style config files) without having to use LPCWSTRs for most things?
My app is using single width ASCII strings throughout, and I've just got round to reading the ini file. Unicode strings are proving to be difficult to deal with and convert between.
If I can't find something fairly simple I think I will just use fstream and be done with it.
.INI files are very old stuff. They were existing decades before the Unicode was introduced. They are simple ASCII files. Tons of applications (including mine) are working with them using simple ASCII Api like GetPrivateProfileString.
If your application uses Unicode default, you can write explicitly GetPrivateProfileStringA. This will force all its params to be simple strings.
Related
I have to deal with importing CSV files. The legacy solution uses MFC and ADO text driver to manage this. I know that you can specify the TextDelimiter-option within the corresponding Schema.ini file.
The problem is, that it is impossible for some input files to specify a character that isn't used within that file!
All our files are CP1252 encoded - we cannot deal with other encodings, so a "☃" (SNOWMAN, U+2603) or stuff like that provide no solution.
If I omit a character, ADO seems to fall back to the default character (doublequotes):
[Import.txt]
ColNameHeader=False
Format=Delimited(;)
TextDelimiter= //← omit character doesn't work!
col1=...
I also cannot define a sequence of characters, which would reduce the risk of mismatches to an acceptable value:
[Import.txt]
ColNameHeader=False
Format=Delimited(;)
TextDelimiter=##+# // produces error when opening the ADO connection!
So my question is: Is it possible to completly disable this feature? I just do not want any automatic text delimiting!
The code is implemented in C++ based upon MFC and ADO - so no ADO.NET solutions will help me.
This should do it:
TextDelimiter=none
I am creating an OpenGL game and I would like to make it open to more languages than just English for obvious reasons. From looking around and fiddling around with the games installed on my computer I can see that locales play a big part in this and that .lang files, such as en-US.lang that is shipped with minecraft, are basically text documents with a language code, "item.iron.ingot" for example, an equal sign, and then what it means for that given language, English as per en-US, so in this case would be, "Iron Ingot". Well I created a file that I named en-US.lang and this is its contents:
item.iron.ingot=Iron Ingot
In my C++ main method I put:
setlocale(LC_ALL, "en-US");
After including the locale header file. So I suppose the part that I am confused by is how to use the locales to read from the .lang file? Please help SO and some example code would be appreciated.
C++ Does not come with a built-in support for resource files / internationalization. However there is a huge variety of solutions.
To support multi-language messages, you should have some basic understanding of how such strings are encoded in files and read to memory. Here is a basic introduction if you are not familiar:
"http://www.joelonsoftware.com/articles/Unicode.html"
To keep and load the correct text at runtime you need to use a third party library: GNU gettext http://www.gnu.org/software/gettext/ is one such example. However there are other solutions out there.
During working on one c++ project we decided to use MongoDB database for storing some data of our application. I have spent a week linking and compiling c++ driver, and its works now. But it is one trouble: strings like
bob.append("name", "some text with cyrilic symbols абвгд");
are added incorrectly and after extracting from database look like 4-5 chinese symbols.
I have found no documentation about unicode using in mongodb, so I can not understand how to write unicode to database.
Your example, and the example code in the C++ tutorial on mongodb.org work fine for me on Ubuntu 11.10. My locale is en_US.UTF-8, and I the source files I create are UTF-8.
MongoDB stores data in BSON, and BSON strings are UTF-8, and UTF-8 can handle any Unicode character (including Cyrillic). I think the C++ API assumes strings are UTF-8 encoded, but I'm not sure.
Here are some ideas:
If your code above (bob.append("name"... etc) is in a C++ source code file, try encoding that file as UTF-8.
Try inserting Unicode characters via the mongodb shell.
I'm developing an application in MinGW/C++ that uses Windows' common dialogs. The need has arisen to collect a file name that might have non-ASCII characters in it. Is there a flag or another option for retrieving a file name in Unicode, or preferably UTF-8?
Call GetOpenFileNameW. You can do this without converting your entire app to Unicode which may be the most expedient solution.
Windows API comes in 2 flavours, ANSI and Unicode. The former has functions with an A suffix. The latter have a W suffix. You are currently using the former.
I want to keep my replacement strings (German, French, etc) in a file format that is standard-ish and useable across Windows and Linux platforms. Thus VC++ resource files are ruled out right away.
What file format do others prefer to use for keeping these l10n resources? Two more features I'd like the format to support are:
the "key" for indexing l10n strings is itself an English string, rather than an enum.
the format can carry a message digest, so I could verify there has been no tampering.
My intent would be to use a function (e.g. wstring foo = GetString(L"I am %1% years old");) that feeds the boost::format or boost::wformat functions. Notice that the key fed to GetString is a string, not an enum.
Obviously I can use whatever XML format (or otherwise) I'd like to dream up. But I'd rather use something that is somewhat standard.
For a standard format, use gettext and msgfmt to make binary .mo files. The format comes from Unix, but is usable cross platform. Audacity, which is Linux/Mac/Windows, uses it.
1) The key is the English string.
2) The standard format doesn't come with an anti-tamper approach, so you will need to cook up your own.
There is also an editor, poEdit, and an emacs mode for working with the translations in the intermediate textual .po format.
We used a library called I18N (I'm sure there are a ton of implementations named the same way all over). The keys and translations were stored in a .txt file, and used some hash for faster lookups. We modified it some to improve the context - it used a context of filename, so you could not use multiple translations of the same string literal in the same file.
Usage was something like Translated = String::Format(I18N("I am %d years old"), years);
We would periodically run a separately executable against our sourcecode to parse out all the various I18N entries, rehash them, and update the file with any new additions.
Unfortunately I can't find any attributes to the author in the source.
Not sure if there is one, but if there is chances are it is mentioned somewhere at lisa.org: http://www.lisa.org/Standards.30.0.html