Re: Populating CString in Win32 dll interface that accepts LPCTSTR

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

See below...
On Fri, 27 Jun 2008 05:18:33 -0700 (PDT), "divya_rathore_@xxxxxxxxx"
<divyarathore@xxxxxxxxx> wrote:

I have a Win32 dll interface:

typedef bool (__cdecl *TITLEPTR)(LPCTSTR);

and I want a string to be populated by calling this inside a UNICODE
enabled MFC App (VS2008):

CString str;
if (!(*pfn3)( str.GetBuffer(256)) )
****
This is totally weird syntax. If pfn3 is a pointer to a function, you can call it with
pfn3(str.GetBuffer(256);
The silly (*pfn3) notation has not been required since K&R C and is considered obsolete,
used only for backward compatibility with old programs written before ANSI/ISO C.
Therefore, there is no reason to use this obsolete and clumsy notation.

Note that in any sensible interface, you would pass in a pointer to the string AND A
LENGTH; how is it that you know for certain that 256 is the correct amount of space to
allocate (and if you "it's a file name" you're in trouble, because file names by default
are longer than 256; take a look at MAX_PATH)
{
MessageBox(_T("Some Problemo!"));
}

..All I am getting in str is jumbled characters (ANSI?).
****
I see no ReleaseBuffer here. It won't work if you don't call ReleaseBuffer
****

How can I get the string str populated properly? I am clearly missing
some Unicode concepts here.
****
If your app is Unicode, and your DLL returns 8-bit characters, you would declare
CStringA str;
which gives you an 8-bit string, but then you wouldn't be using LPCTSTR as the prototype
of the function, if it returned 8-bit strings; it would LPSTR. LPCTSTR says that it will
take 8-bit strings in an 8-bit app, and Unicode strings in a Unicode app, AND THAT THIS
PARAMETER REPRESENTS CONSTANT DATA AND WILL THEREFORE NOT BE MODIFIED. If the purpose is
to fill a buffer, it would have to be LPTSTR (for ANSI/Unicode), LPSTR (for ANSI) or
LPWSTR (for Unicode). Since it is a DLL, you have to declare data of the correct type
that matches the prototype of the function. Because it is a DLL, you have to use the
header file it was compiled with to determine the correct typedef for your function. You
can't just invent one out of thin air and expect it to work.
joe
****


warm regards,
Divya Rathore
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages

  • Re: Multi language application
    ... the block below implies that you created your app as "Unicode app". ... Whether you choose UTF8 or UTF16 is really up to you but by default in a "Unicode app", you're likely to write less code with UTF16 strings. ... You can use::MultiByteToWideChar Win32 API to convert from UTF-8 to UTF-16, and pass the UTF-16 string to Windows controls. ...
    (microsoft.public.vc.mfc)
  • Re: LANG, locale, unicode, setup.py and Debian packaging
    ... The app assumes unicode objects internally. ... encoding, and compute that encoding with locale.getpreferredencoding. ... string operation, at every print command and is almost impossible to fix. ...
    (comp.lang.python)
  • Re: ANSI string from UNICODE app.
    ... Strings are stored in the Registry as Unicode. ... string value, ... When an ANSI app retrieves the string value, ... is downconverted to an ANSI string. ...
    (microsoft.public.vc.mfc)
  • Re: DX9.0c Is it Unicode only now??
    ... I think u never use unicode(Wide Character) in C++ on NT/2k/XP platform ... And when u give new string content u need to add ... Unicode in order to make it common used, ... thing is that the Unicode based app can't run on Win9x system. ...
    (microsoft.public.win32.programmer.directx.graphics)
  • Re: String Manipulations
    ... But I didn't explicitly designate my program to run under Unicode ... > CString str; ... >> string and not the literal characters of the string. ... >> I still only receive the address of the CString object at the console. ...
    (microsoft.public.vc.language)