I wonder if your getting a referencing problem. CString attempts to not
occurrences. I've been caught by this before. I usually force the issue by
Howdy,
I'll try and cover several questions.
The program is not Unicode.
The CString in the case here could be generated one of serveral ways. The
most likey is:
const char *DefOperators[] =
{
"OR",
"AND",
"ADJ",
"NEAR",
"WITH",
"SAME"
};
CString ValidateDefOperator(CString Value)
{
Value.MakeUpper();
int Size = sizeof(DefOperators)/sizeof(DefOperators[0]);
for(int i=0; i<Size; i++)
if(DefOperators[i] == Value)
return Value;
return "OR";
}
When it comes from some other source, it will be processed here so the end
result would be the same.
I can't trace it because it is a rare occurrence. I'm afraid that logic
is
about all I can apply to the problem.
I don't see instances of GetBuffer applied to the string in question. The
data is a class variable. If something is clobbering the string, it will
be
almost impossible to sort out of the hundreds of C++ files that make up
the
code.
One reason for asking about this is I had a similar problem show up when a
CString was being returned from or Oracle ODBC driver. That would
sometimes
return a bad length for the string in a field of the rowset. It was
returned
from the driver with a problem before anything in the program itself
touched
it. I was wondering if this was similar.
The string itself is corrupted because the serialized data for it is FF FF
FF 02 00 00 DD, which indicates it was returned to the serialize string
function as 0xDD000002 bytes long.
--
Frank Perry
LavaLeaf Software
"Frank Perry" wrote:
Howdy,
I'm having a problem with CString. Rarely but too often, GetLength
returns
the wrong length. A recent example is a CString "OR" returned a length
of
0xDD000002. As you could guess, this caused Serialize to have a
heartattack.
Has anyone seen this kind of problem before and have an idea of the cause
and of a solution?
--
Frank Perry
LavaLeaf Software