|
Thanks for the help guys!! I was able to get it based on your suggestions.
S. Reynolds
|
|
|
|
|
Hello,
Is there an easy way to convert from ASCII code to Unicode?
assumes:
i have some text written in other encoding like cyrillic, i want to convert it to UNICODE? i am using visual c++ 6.0.
could somebody give any advice?
thanks
|
|
|
|
|
Gofur Halmurat wrote: Is there an easy way to convert from ASCII code to Unicode?
You mean like the A2W() macro?
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
i dont know what A2W macro is?
how can i use it?
thanks
|
|
|
|
|
See here.
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
The first 127 code points of the Unicode character set equal the ASCII character set, so you can simply assign each ASCII character to a wide Unicode character.
Gofur Halmurat wrote: i have some text written in other encoding like cyrillic, i want to convert it to UNICODE?
"cyrillic" isn't an encoding. You must know the actual character set used to encode the cyrilic text, is it ISO-8859-5, Windows CP1251, KOI-8, or something else? Once you know that you can use for example iconv[^] to do the conversion.
|
|
|
|
|
You are right, it is Windows CP1251, i want to change it to UTF-8, but how?
i read some about iconv, i think that is only under linux os,
even if it is under windows, could you give me an example of how to use it? i am really lost of c++ type casting. there are alot of types in c++
thanks
|
|
|
|
|
|
I'm calling the API function "Netbios", and can do most of the function calls. However, I'm stumpted, how do you clear the NBT Cache table
example of a struct i have setup:
ADAPTER_STATUS adapt;
NAME_BUFFER namebuffer [xxxx];
I originally thought it was in the nameBuffer, but that is the local NetBios names, not the cache of remote names.
NBTSTAT -R is the call in DOS to clear the remote name list.
Any help would be apprecated.
bulldogAMD
|
|
|
|
|
Hi,
An MFC program that uses the .h and .cpp files created from the type library msword8.olb. The program works correctly in versions of Word from Word97 to Word 2003 but does nothing in Word2007. This type library was used rather than msword.olb because some of the function signatures had changed & the newer ones would break in older versions of Word. Does anyone know how I can use the program with Word2007 as well.
|
|
|
|
|
Hello everyone,
I am using Visual Studio 2005. I am confused when creating a new smart device project. We can select Windows CE 5.0 or Pocket PC 2003.
My question is, are they compatible? (I am developing native unmanaged C++ application)
1. If I build Windows CE 5.0 project, could it run on Pocket PC 2003 device or emulator?
2. If I build Pocket PC 2003 project, could it run on Windows CE 5.0 device or emulator?
3. What are the differences?
thanks in advance,
George
|
|
|
|
|
Possible differences are in what drivers/hardware are available, memory layout and size, available screen resolutions, available subset of APIs and runtime library calls that are supported. As long as you're not doing any comms or anything close to the hardware or using any obscure APIs or library functions you should be able to write code portable between the two emulators at least. Any real world app is likely to have modules dependent on device hardware, in which case the emulators won't help you anyway. Remember CE 5.0 is really an OS toolkit rather than an OS. Each device type out there has its own build of CE 5.0 which is actually a subtly different OS. Platforms like Pocket PC 2003 are an attempt to standardise some of this variation so that software can run on multiple devices provided the actual CPU is compatible ( ARM V4I is pretty common so a good one to target ).
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Thanks Matthew,
Great reply! I want to learn more details in your below comments, e.g. what are the obscure APIs do you mean? Is there a list or some official documents?
Matthew Faithfull wrote: Possible differences are in what drivers/hardware are available, memory layout and size, available screen resolutions, available subset of APIs and runtime library calls that are supported.
Matthew Faithfull wrote: obscure APIs or library functions
I only use C/C++ standard libraries to access File system, process information and using multiple thread as well. There is also a very simple GUI interface based on Win API. I am wondering in my case, whether it is ok to,
1. make a ARM build on Pocket PC 2003 platform and make the built binary run on Windows CE ARM emulator?
2. make a ARM build on Windows CE platform and make built binary run on Pocket PC 2003 ARM emulator?
regards,
George
|
|
|
|
|
To find out which API calls aren't supported you'll need to look at the documentation for a specific API to see if CE supports it at all and for the Pocket PC 2003 platform to see if its included. It basically depends on which modules the platform includes in its CE build.
A GDI based GUI should be no problem and provided you can handle landscape & portrait screens, low res, different colour depths and adjusting your layout it should run on loads of devices and certainly on both the emulators.
The C/C++ standard libraries are cut down for CE but should be standard across the sample Win CE build and Pocket PC 2003. As long as you remember that thread management and priorities work differently on CE from ordinary Windows you should have no problem.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Good advice, thanks Matthew!
have a good weekend,
George
|
|
|
|
|
Hello everyone,
I would like to learn some experiences about when should we use std::basic_string and when should we use std::string?
I learned some Hello World level samples and now want to listen to your practical experiences.
thanks in advance,
George
|
|
|
|
|
std::string is a concrete instantiation of std::basic_string with char*. That is std::strings consist of signed 8 bit values.
std::wstring is a concrete instantiation of std::basic_string with wchar_t*. That is std::wstrings consist of unsigned 16 bit values.
You never use std::basic_string_string directly.
When you do not need 16 bit chars, you use std::string.
You may create your own instantiation of std::basic_string with a unsigned char* as underlying type.
Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all.
Douglas Adams, "Dirk Gently's Holistic Detective Agency"
|
|
|
|
|
Great reply, thanks jhwurmbach!
regards,
George
|
|
|
|
|
for normal string operations, you only need to work with std::string.
(inspired from Scott meyers's More Effective C++ )
std::string is a typedef of std::basic_string, something like std::basic_string<char> (and/or support for unicode? with std::wstring ).
If you want to specify what is stored in the std::basic_string and how it is allocated, then you will need to explicitly use std::basic_string and learn to use char_traits and Allocator to tell the string what is in it and how to allocated the memory for it.
|
|
|
|
|
Great reply, thanks Maximilien!
regards,
George
|
|
|
|
|
I have made all the necessary registry entries to associate my app with a project file that it creates. When I double click on the file my app starts up but I get an invalid path error when opening the file. Once the application is running, however, I can open the project file without any problems. I am getting the file name from the m_lpCmdLine variable in my CWinApp derived class.
Does anyone have any suggestions how to resolve this problem?
Thanks.
|
|
|
|
|
masnu wrote: ...but I get an invalid path error when opening the file.
Does the path contain spaces?
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
why don't you use your debugger for this ?
you could check where something is lost.
what i suspect is that you have spaces in your file path, and passing it through the commandline will not work since you don't put the path within quotes ("").
|
|
|
|
|
masnu wrote: Does anyone have any suggestions how to resolve this problem?
Yes, some kinda of debugging: for instance printout (maybe with a message box) command line content.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
I managed to solve the problem. For those who are intrested I did the following:
CommandLineInfo cmdInfo;<br />
ParseCommandLine( cmdInfo );<br />
<br />
CString strProjectName = cmdInfo.m_strFileName;
This works without any issues.
Thanks.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
