bug or not?

[nitex]

compiling this as ansi is ok but with unicode defined the string values of date and time seem to stay ansi. is this normal behaviour? do i have to manually convert the values?  :?

TCHAR tcBuffer[1024];

wsprintf(tcBuffer, _T("Build: %s // %s"), __DATE__, __TIME__);

greets alex

[Anonymous]

compiling this as ansi is ok but with unicode defined the string values of date and time seem to stay ansi. is this normal behaviour? do i have to manually convert the values?  :?

TCHAR tcBuffer[1024];

wsprintf(tcBuffer, _T("Build: %s // %s"), __DATE__, __TIME__);

greets alex

If you are working with the current (system clock time) you can use the functions _wcsdate and _wcstime in the wchar library.  

If DATE and TIME are ansi strings representing some other time and date you will likely need to convert them to Unicode manually. Fortunately this is easy to do....  The following code returns a pointer to a Unicode string built from an ansi string...

Code: [Select]


wchar_t*   MakeUnicode (char* str)
 { if ((strlen(str) == 0) || (str = NULL))
      return NULL;
     // allocate memory for result string
    wchar_t* wstr = calloc(sizeof(wchar_t),(strlen(str)+ 1));
    // transfer data
    for (int x = 0; x <= strlen(str) + 1; x++)
       wstr[x] = str[x];
    return wstr; }


[nitex]

the date and time values are used for displaying the build date and time in the about box of the program. thanks for your answer.

greets alex

[Anonymous]

the date and time values are used for displaying the build date and time in the about box of the program. thanks for your answer.

greets alex

You can probably do this most easily by adding a Version resource to your RES files.  There is considerable flexibility as to what is included and it can be displayed by standard API calls that work with either Unicode or Ansi text.  This method also has the advantage that your version info can also be displayed by a right click on the file.  (R-click,Properties,Version)

Check the Version Info section in the API docs for more detail...
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/resources/versioninformation.asp

[Pelle]

The following (for example) will work, starting with C99:
L"Built on " __DATE__ L" at " __TIME__

Pelle

[nitex]

i will try this, much shorter than what i used. currently i'm using something like this:

Code: [Select]

#ifdef UNICODE

// convert values with MultiByteToWideChar

#else

// use ansi version

#endif

i have looked with a hex editor in the generated *.exe. in the strings section all strings are unicode but the date and time values are stored as ansi. is this normal? i don't know how other compilers handle this.

greets alex

[Pelle]

I *think* so. If you just use __DATE__ and __TIME__, they will be character string literals. By using (for example) L"wide string" __DATE__, and using the compilers special support for concatenating strings, starting with C99, it should work combining a wide character string literal and a character string literal, forming a wide character string literal.

(Using (for example) __DATE__ L"wide string" should probably work too, but I don't support that right now - you can always start with L"" or TEXT("")...).

Pelle

[Anonymous]

By using (for example) L"wide string" __DATE__, and using the compilers special support for concatenating strings, starting with C99, it should work combining a wide character string literal and a character string literal, forming a wide character string literal.

Ummm... hate to sound like a total noob again but... I can't seem to find any examples or documentation for this  L"wide string" or string conctenation ....  Could I trouble you for an example or two to demonstrate the concepts?

[nitex]

regarding the L"" you may read the following about the TEXT() or _T() macro:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/unicode_1cmr.asp

haven't found something about string concatenation.

greets alex

[Anonymous]

regarding the L"" you may read the following about the TEXT() or _T() macro:

Now THAT was helpful, thanks...  

haven't found something about string concatenation.

Still lookingl... other than the strcat and wstrcat I'm still drawing a blank, too.

One thing I've noticed and maybe someone can correct me on this, but it seems to me that MS's vision is that applications are either Ansi or Unicode, not a mixture of both.  In Pascal we could mix them together in the same application, even use one as the other (within limits)... is this not the case in C?  

For example, I noticed the rather distinct absense of library routines for converting between string types.  They're easy enough to write and it surprises me they aren't there...

[nitex]

One thing I've noticed and maybe someone can correct me on this, but it seems to me that MS's vision is that applications are either Ansi or Unicode, not a mixture of both. In Pascal we could mix them together in the same application, even use one as the other (within limits)... is this not the case in C?

if you compile ansi, the programs can be used under win9x based systems. unicode isn't directly supported by these. a small subset is supported with an extra layer.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/mslu/winprog/microsoft_layer_for_unicode_on_windows_95_98_me_systems.asp

unicode instead is supported on all NT based systems. if one would mix ansi and unicode, the application wouldn't run under 9x based systems.

with some extra effort it is possible:

http://www.flipcode.com/articles/article_advstrings01.shtml

For example, I noticed the rather distinct absense of library routines for converting between string types. They're easy enough to write and it surprises me they aren't there...

they are there, implemented in the windows api.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/unicode_19mb.asp

also one shouldn't use the ansi or wide string functions directly. instead one includes tchar.h and uses these macros. have a look in the pelles c helpfile.

all text in the source code should be surrounded with either TEXT() or _T() macro. to compile for ansi or unicode without sourcecode modifications.

at the top of your sourcecode or linker settings you'll only need to define this to compile for unicode.

#define _UNICODE
#define UNICODE

greets alex

[Anonymous]

if you compile ansi, the programs can be used under win9x based systems. unicode isn't directly supported by these. a small subset is supported with an extra layer.

Yes, I know about these limitations...

they are there, implemented in the windows api.

Ok... if "Mulitbyte string" means "ANSI string" yes they are right there, and in the C library as well mbstowcs and wcstombs being the complimentary functions...

 :x I really wish they'd quit arbitrarily renaming stuff... it's impossible to keep up!

also one shouldn't use the ansi or wide string functions directly. instead one includes tchar.h and uses these macros. have a look in the pelles c helpfile.

Thanks for that one...

However this is still not quite what I was on about....  
Lets see if an example will help...

I need to write a program that has to access data from multiple sources, some of which are using unicode, some not... and this does happen in WAN situations.  Therefore the same program has to deal with unicode or ansi text with equal grace...  

From what I've seen, C doesn't much like doing this... Everything I find seems to be either/or, never both ... hence my concern and my question...

Is this a C thing or is it just that I'm not finding mixed-mode examples?

[nitex]

i would probably use unicode for all strings. then write a function which checks if the data is unicode, when not than directly store it or if the data is ansi convert it to unicode. if the data is text you may use a function like
IsTextUnicode().

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/unicode_81np.asp

MultiByteToWideChar() and WideCharToMultiByte() are fully implemented in unicode on win9x based systems but i don't know how one would display such text except using TextOut() function which should be implemented in unicode too.

if you can live with the circumstance that your app only runs on NT based systems you should convert that ansi stuff.

greets alex

[Pelle]

I think concatenation of literal strings, in the compiler, was added to C89 (the previous C standard). It was originally meant to help with very long string literals:

char str[] = "abcdefghijklmnopqrstuvwxyz"
    "abcdefghijklmnopqrstuvwxyz"
    "abcdefghijklmnopqrstuvwxyz";

rather than the older style, which could cause some problems ("what about the spaces at the beginning of line 2 and 3 - are they part of the string or not?"):

char str[] = "abcdefghijklmnopqrstuvwxyz\
    abcdefghijklmnopqrstuvwxyz\
    abcdefghijklmnopqrstuvwxyz";

I can't point to a description of this at the moment, but some C FAQ site should contain something about this.

The C standard tries to be a bit broader than what's used by Windows, so they are talking about "multibyte" strings and "wide character" strings (hence names like mbstowcs - "multibyte-string-to-wide-character-string"). I'm not an expert, but AFAIK, there are other character encodings than ASCII, ANSI and Unicode. Maybe nor used by Windows, but probably used by C implementations on other platforms.

In straight C, you use "string" for a character string, and L"string" for a wide character string - in Windows this means Unicode. To be able to quickly build either ANSI or Unicode applications, Windows have a macro TEXT("something") which translates to either L"something", if UNICODE is defined (#define UNICODE), or "something" if it's not.

To complicate things even further, both Microsoft and Pelles C contains TCHAR.H which uses the same approach, but the macro is _T("something") and the symbol is called _UNCODE.

Hope this made *something* clearer...

Pelle

[nitex]

yes, that was nice!  

alex