Macro issue...

[CommonTater]

I've been playing with this for a bit and so far no solution that doesn't make things worse...

The L prefix for strings is a pain in the butt since it does not respond to the #define UNICODE or _UNICODE... a wide string is always a wide string.

I am aware of the TEXT("string") thing, where text is essentially a macro that replaces it self with the L when one of the unicode defines is active. The drawback is all the extra typing, especially if you are doing a long series of strings...

What I was hoping to do is write a macro that A) responds to the unicode defines and B) still uses a single character... perhaps the $ sign... that is...

When UNICODE is defined I want it to see $"Hello" as L"Hello".  When it's not I want it to see $"Hello" as plain old "Hello".  But for some reason I just can't get it to work...

I tried simple character substitution with #define $ L  and got all kinds of errors as the L was no longer recognized as meaning a wide string.  Other variants such as #define $(txt) L##txt  required an extra set of brackets around the literal... 

Is there a way to do this?
What am I missing?

[JohnF]

Here's one way.

#ifdef _UNICODE
#define _TS  L"%ls"
#define _TC  L"%lc"
#else
#define _TS  "%s"
#define _TC  "%c"
#endif /* _UNICODE */

use as

_stprintf(sGen0, PATH_SIZE, _TS _TS, pathname, str);

EDIT: I just realised that did not answer your question! :]

John

[CommonTater]

No worries John... interesting macros though.

I'm really just trying to get some kind of automated mode switchging (like TCHAR) for string literals without having to type in a load of extra stuff on every line... I can deal with the rest easily enough, it's just that L prefix thing on literals that's driving me up the wall...

[Stefan Pendl]

How about creating a similar macro like the TEXT() macro, but using only $()?

Could you show the macros you already tried?

[CommonTater]

Already tried...

#define $ L  ... L not recognized as string modifier

#define $(txt) L##txt  ... requires brackets but works

#define $"  L"  ... not recognized

I think pretty much all the expected combinations... 

The second one is my version of the TEXT macro... it works but you still gotta put brackets around literals...

(I'm sorry if this seems trival, but it would make quite a difference in three medium-large projects I have coming up if I could get it to work.)

[Stefan Pendl]

Might be time for an add-in which scans the code to find string literals and checks for the TEXT() macro being applied, if not apply it.

[CommonTater]

Might be time for an add-in which scans the code to find string literals and checks for the TEXT() macro being applied, if not apply it.

Really...

Or... I could just get "unlazy" and live with it...  Although the $() macro is an intriguing idea, takes me back to my days in TurboBasic....

What I really wish is that C was internally unicode aware...
Maybe as a pragma... #pragma UNICODE:ON

[JohnF]

A thought - is there still a need to have both ANSI and UNICODE versions?

John

[CommonTater]

A thought - is there still a need to have both ANSI and UNICODE versions?

John

Actually for what I do... no.  I work almost entirely in WCHAR and unicode these days.  But yes, I believe ansi versions are still valid in some situations... Like when loading a DLL with ANSI functions in it.

What I'd really like to see is Windows go natively UTF8 ... instead of UTF16le ...  (Like that's going to happen any time soon)  ANSI and unicode all in one!

[defrancis7]

CommonTater:

I have been working, slowly it seems, trying to learn how to Program the Win32 API.  I am currently working from Charles Petzold's
"Windows Programming", 5th ed, 1998.  (I am just a recreational programmer.)  He writes about the differences between using ANSI and UNICODE with Windows; especially about the handling of the wParam and lParam values.

I am typing in the programs of book myself.  No better way to learn than to actually do it.  The book's advice, at least as I understand it, is to write the program as it would be for ANSI; but use TCHAR for type char and precede text strings with the TEXT macro.  To compile as an UNICODE project, in the code file define UNICODE before the '#include <windows.h>' statement.  (The documentation with Pelles C also says to have the '#include <tchar.h>' statement after the windows include.)  Petzold states that the ANSI version will then work without having to rewrite the entire program.  So far, and I am up to chapter 9 at the moment, all the programs have worked.  (After correcting for spelling errors in the ANSI code.  )

I have not gotten as far as how to handle the case where you are mixing ANSI and UNICODE in the same program.  Which is what I think you are trying to do.   I could see writing the code file explicitly with the functions and types used for ANSI for the ANSI part and those functions and types for UNICODE for the UNICODE part of the code file.

By the way,  my OS is 64-Bit Windows 7 and I am using Pelles 6.0.

David E.

[CommonTater]

I have not gotten as far as how to handle the case where you are mixing ANSI and UNICODE in the same program.  Which is what I think you are trying to do.   I could see writing the code file explicitly with the functions and types used for ANSI for the ANSI part and those functions and types for UNICODE for the UNICODE part of the code file.

Hello David;
I learned a long time ago not to mix Ansi and Unicode in the same programs.  Yes it can be done by specifying the A or W suffix on the function calls and CHAR or WCHAR for strings rather than using the generics but most often it simply results in spagetti code that never seems to work correctly. 

Peltzoid's book is an excellent introduction to WinAPI in C... but it is from 1998, predating Windows 2000 in which Microsoft switched everything to work internally as Unicode.  What happens behind the scenes is that when you call an Ansi function that uses a string, the string is first translated to WCHAR and then the Wide version of the function is called.  If you are writing Ansi code for WinAPI this adds an extra step to practically every function call you make... and yes there is a slight (but measurable) speed penalty for it.

What I do now is work in Unicode exclusively.  I use WCHAR (wchar_t) and I #define UNICODE and _UNICODE at the top of each page.  I no longer care if it will compile and work as Ansi, since almost everything I do now has to accomodate non-english inputs (to some degree). 
 
The whole point of using the native utf16le Unicode upon which Windows is built is so that even if your UI text is in English, the user entered data can be in almost any language and it's all quite transparent to the User.  Internationalization is pretty easy when you do this too... Place all your UI labels and text into stringtables then all you have to do is load and translate the resources for your program, maybe juggle the dialog sizes a bit, and suddenly you have a version for a different language.

Also you might want to look into updating to 6.50 rc 4, as there have been quite a large number of new functions implemented and the Windows headers and libs are a better match to the current Windows API for Win7. 
 
 

[defrancis7]

Thanks for the response CommonTater.   I like Petzold's book.  I also got the forger's tutorial from winprog.org.  I think both are good for beginners such as myself.  If I did have any complaints it would be along the lines that both need to be updated to include the new versions of Windows.  Fourteen years is almost ancient history when dealing with almost anything related to Computers.     On the other hand, I must admit that I am struggling at times to understand what Petzold (or Brooke) is trying to teach me.

As I wrote earlier, I'm just a recreational programmer.  I do it mostly for the fun of it; when I might have an interesting problem.  I'm not really expecting to write the next must-have program everyone must possess.

I downloaded the setup64 file for C6.5 rc 4 last winter.   I installed it over the version C6.0 I was using.  When I click on the About Pelles C menu item from the help menu, is states that I am still using ver 6.00.4.  So, as far as I know, I'm still running C6.0.

David E.

[CommonTater]

Thanks for the response CommonTater.   I like Petzold's book.  I also got the forger's tutorial from winprog.org.  I think both are good for beginners such as myself.  If I did have any complaints it would be along the lines that both need to be updated to include the new versions of Windows.  Fourteen years is almost ancient history when dealing with almost anything related to Computers.     On the other hand, I must admit that I am struggling at times to understand what Petzold (or Brooke) is trying to teach me.

An awful lot of the stuff out there is very old.  But it's also very reflective of the slow progress in languages as well.  It seems that we have a choice between ancient stuff and new stuff that's not working right.  Case in point the D programming language which I thought had enormous potential until I saw the state of the standard library for it... wadda mess!
 
Windows API is not easy programming and there's tons and tons of it... But with a little patience you will discover that all the basic principles from Peltzoid still apply.  What you need to do is get the Windows API installed ( From HERE ) and look stuff up as you go and as you need it.  Like most textbooks, Peltzoid and TheForger, are not complete discussions of the API.  Treat them as a starting point then go from there, learning as you need to.

As I wrote earlier, I'm just a recreational programmer.  I do it mostly for the fun of it; when I might have an interesting problem.  I'm not really expecting to write the next must-have program everyone must possess.

I'm sort of in the middle on that... I started programming long ago with one of the earliest microcomputers but never made money at it until after retring from electronic service (pro-audio, 2 way radio, home entertainment, computers).  I have a couple of fairly large packages out there and still maintain them, but won't be upgrading them anytime soon.  I'd say I'm about 70% hobbiest, 30% professional.  Most of the programming I did was in line with my main career.
 

I downloaded the setup64 file for C6.5 rc 4 last winter.   I installed it over the version C6.0 I was using.  When I click on the About Pelles C menu item from the help menu, is states that I am still using ver 6.00.4.  So, as far as I know, I'm still running C6.0.

I've messed with mixed versions before and that's just not good.  The biggest problem is that the compiler and the library are very tightly intertwined and cross-version stuff can cause some pretty strange results.  I suggest you uninstall what you've got then put in 6.50 clean.