You're right. I missed that OP said "populated" and was fooled by the
function. I need to get new glasses I guess....
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
See below...
On Fri, 27 Jun 2008 07:53:03 -0700, "Tom Serface"
<tom.nospam@camaswood.com> wrote:
Hi Joe,
I'm confused from the code, but it seems to me the call to GetBuffer() and
to ReleaseBuffer() is unneeded altogether.
****
Not only are they needed but it cannot possibly work unless they are used.
The DLL is
going to write some arbitrary amount of information, which the caller
naively thinks is <
256 characters, into the buffer (what happened to those ideas about "safe
computing" that
were so popular years ago?)
****
I've only had to call
ReleaseBuffer() if I actually modify the buffer after GetBuffer is called
and I only call GetBuffer() if I want to modify the string directly or the
calling parameter demands a LPTSTR (which I admit is hardly ever).
****
But the OP wanted the string to be "populated" by the DLL. That's the
OP's words, see the
message. So we can assume the buffer has been modified. Without the
ReleaseBuffer call,
the CString contents are not consistent with the actual string data.
****
Since
the parameter is a pointer to a const I think it's unlikely they can
modify
the buffer supplied anyway.
****
The fact that it is a pointer to a const from one view does not change the
fact that the
parameter might be non-const from the viewpoint of the DLL. Essentially,
what happens
here is an implict cast here by telling the C/C++ build that it is a
pointer to a const
Unicode or ANSI string, but the DLL might think it is a non-const pointer
to an ANSI
string. The prototype shown for the function pointer MIGHT be pointing to
a function that
says
bool Something(LPSTR result)
which means the prototype given is erroneous, OR, it might be
bool Something(LPTSTR result)
in which case the DLL and the app MUST BOTH be compiled either as Unicode
or non-Unicode.
If the DLL is compiled as ANSI and the app is compiled as Unicode, the
nominal text of the
prototypes will give the illusion of being the same, but in fact they are
not. When I've
had to do this, I usually do the same thing Microsoft does, e.g.,
#ifdef _UNICODE
bool SomethingW(LPWSTR result)
#else
bool SomethingA(LPSTR result)
#endif
so at least it won't link if there is a failure. In some cases where I'm
delivering a DLL
as a product, I do the same thing as Microsoft does, which is to implement
BOTH forms, do
the real work in Unicode, and convert back, e.g.,
extern bool __cdecl DoSomethingA(LPSTR result, int len);
extern bool __cdecl DoSomethingW(LPWSTR result, int len);
#ifdef _UNICODE
#define DoSomething DoSomethingW
#else
#define DoSomething DoSomethingA
#endif
and DoSomethingA is
extern "C" bool __cdecl DoSomethingA(LPSTR result, int len)
{
CArray<WCHAR> data;
data.SetSize(len);
if(!DoSomethingW(data.GetData(), len))
return false;
WideCharToMultiByte(CP_ACP, result, len, data.GetData(), -1, NULL, 0);
// I may have not gotten the parameters in the right order, check the
docs
// error detection and response left as EFTR
return true;
}
A major improvement over the piece of trash code shown was that I actually
use an explicit
length, which is what every string-modifying piece of code should do. The
code as
suggested by the OP represents obsolete, sloppy thinking and poor
implementation.
****
I liked your repsonse though. I didn't even consider that OP would want
to
perhaps fill the string. If that's the case then making the parametere a
LPCTSTR is definitely wrong, but if the DLL is using the string without
modifying it then that would be the better way to do it just to be sure.
I
think we need to see some more of the code if possible.
****
Like too many people asking a question, the OP shows half the code
required to figure out
what is going on (most of the rest seem to show no code and expect us to
guess...). We
see the prototype used on the "client" side of the DLL, but we do NOT see
the actual
prototype of the DLL function!
*****