cannot convert from 'const char to 'ATL::CStringT<BaseType,StringTraits>' error

>> error C2440: 'initializing' : cannot convert from 'const char [27]' to 'ATL::CStringT<BaseType,StringTraits>'      

Try changing it to this...

#define      DBF_DIR            _T("\\Program Files\\MyProgram\\DB") // Wide or narrow depending upon compile time params

or this

#define      DBF_DIR            L"\\Program Files\\MyProgram\\DB" // Wide string

>> CStringT
I'm not 100% but I'm guessing the T at the end means the same as the T in a TCHAR type (it can be either wide or narrow).

I have did this:
#define      DBF_DIR            _T("\\Program Files\\MyProgram\\DB")

and it compiles but then when I go to use it like so:
sprintf(szDbFile, "%s\\%s.dbf", DBF_DIR, CONFIG_DB_FILE);

the DBF_DIR apears as an empty string.

Try: _stprintf(szDbFile, "%s\\%s.dbf", DBF_DIR, CONFIG_DB_FILE);
http://msdn.microsoft.com/en-us/library/ybk95axf(VS.80).aspx

You might also consider using CString, which has a Format method that is similar to sprintf

CString s;
s.Format("%s\\%s.dbf", DBF_DIR, CONFIG_DB_FILE);

Actuall that would be

CString s;
s.Format(_T("%s\\%s.dbf"), DBF_DIR, CONFIG_DB_FILE);

re: _stprintf(szDbFile, "%s\\%s.dbf", DBF_DIR, CONFIG_DB_FILE);
gives the error:
error C2664: 'swprintf' : cannot convert parameter 1 from 'char [260]' to 'wchar_t *'

re: Use CString
I have to use:
char szDbFile[MAX_PATH];
sprintf(szDbFile, "%s\\%s.dbf", DBF_DIR, CONFIG_DB_FILE);

as I am using codebase and it needs it to be in that format, i.e. the next line is:
m_pD4ConfigData = d4open(&m_c4CodeBase, szDbFile);      

You can use CStringA (as opposed to CString) and easily convert to a char * for the d4open() method.

It gets hairy mixing Unicode and the T macros with ANSI APIs. The macros work well, but an ANSI API expects ANSI, period, and are usually compiled to expect char *.

I will often just use a CString, for general use, that way all MFC APIs are happy, but when I need to call an ANSI/traditional API I assign to a CStringA for a conversion, and cast that to a char *. Its either that or use the conversion APIs (WideCharToMultiByte....), and I find them too wordy for general use. Or maybe I am yet to learn a better way.

>> Or maybe I am yet to learn a better way.
UTF8 :)

>>UTF8 :)

What do you mean? So I have a UNICODE app, all t* types and CString are wide-char. So what is the quickest, simplest way to convert for 8-bit APIs? UTF8 is great, but I am talking wide-chars here, right? What did I miss?

>> What do you mean? So I have a UNICODE app, all t* types and CString are wide-char. So what is the quickest, simplest way to convert for 8-bit APIs?
Just use UTF8 all the time, forget wide... it's not portable and causes so many headaches. Wide for Windows is UTF16 and for Linux it's UTF32 but both will happily work with UTF8.

>> UTF8 is great, but I am talking wide-chars here, right? What did I miss?
I know and I'm saying avoid the pain just use UTF8 rather than UTF16 or UTF32.

It was a bit of a glib and OT comment... sorry ;)

BTW when you convert to narrow using WideCharToMultiByte you are just converting UTF16 to UTF8 (hence it being multi-byte), you realise that right? Hence I glibly say, just use UTF8 all the time.

^^^assuming you chose UTF8 as the charset to convert to of course.

I'm rambling now, I think I need to go and sleep :)

Now that we have successfully hijacked another thread.. :)

What I am saying is, assuming we are using MFC with UNICODE defined, we don't necessarily have control? _T("foo") is going to be 16-bit, not 8-bit. TCHAR is wide, LPCTSTR is wide. All of the MFC APIs that expect either CString or LPCTSTR, etc. want wide char stuff, which is not UTF8. I don't want to use the conversion routines, I just want smart strings.

So if it were up to me, I'd use UTF8, but is it really up to me?

>> Now that we have successfully hijacked another thread.
You're quite right we seem to have hi-jacked a thread, so I relinquish my side of it ;)

@Wanting2LearnMan : did you resolve your problem?