It is often a good idea to post the problematic code AND the full text of of
the error message. That usually rings a bell with someone. Without the text
of the error, someone has to create a project, copy the code and compile.
Some here have the time for that, some don't.

Regards,
Will

Sorry for not being so clear. Here is the complete error message I
get:

c:\MFC\Decoder\DecoderDlg.cpp(592) : error C2593: 'operator +=' is
ambiguous
       c:\Program Files\Microsoft Visual Studio .NET
2003\Vc7\atlmfc\include\cstringt.h(1075): could be
'ATL::CStringT<BaseType,StringTraits>
&ATL::CStringT<BaseType,StringTraits>::operator
+=(wchar_t)'
       with
       [
           BaseType=char,
           StringTraits=StrTraitMFC_DLL<char>
       ]
       c:\Program Files\Microsoft Visual Studio .NET
2003\Vc7\atlmfc\include\cstringt.h(1068): or      
'ATL::CStringT<BaseType,StringTraits>
&ATL::CStringT<BaseType,StringTraits>::operator +=(unsigned
char)'
       with
       [
           BaseType=char,
           StringTraits=StrTraitMFC_DLL<char>
       ]
       c:\Program Files\Microsoft Visual Studio .NET
2003\Vc7\atlmfc\include\cstringt.h(1061): or      
'ATL::CStringT<BaseType,StringTraits>
&ATL::CStringT<BaseType,StringTraits>::operator +=(char)'
       with
       [
           BaseType=char,
           StringTraits=StrTraitMFC_DLL<char>
       ]
       while trying to match the argument list '(CString, int)'

BR /// Rob

Are you sure it worked? It may have compiled, but I suspect it didn't
do what you wanted. I suspect it added an ascii character with the
value ((iOct >> 4) +48) to the string, not a string representation of
the number ((iOct >> 4) +48) as you seem to want.

There is no operator += for CString to add an int to a CString.
Instead, it is trying to call one of the 1 or 2 operator+= methods on
CString that take a char argument. I think the reason it used to work
is that you weren't compiling in UNICODE mode, and now you are, which
means that there are two versions of operator+= that can take an int
(one taking char and one wchar_t), hence the ambiguity.

What were you expecting it to do? Add on a string representation of
the integer to the string? In what base? From the workaround code
above you appear to want hex representation. I suggest you just use
the new code (making sure that your cTemp buffer is *definitely* large
enough - 8 might be too small? 64 might be safer...). It looks like
you have found a bug in your code by upgrading!

Tom

The code was part of a function that decodes a BCD number to ASCII.
Yes, the old code worked as I expected. But I did check the new code
and it did not! When I used “itoa” I shouldn’t have added “48”.
In the old code, by shifting my octet 4 bits I can assure that the
value is not greater then 9 as the number was BCD coded. Now by
simply adding 48 I got the number in ASCII format.

I have attached the complete function in the last part of the post.
The input to the function was the actual number of octets I needed to
decode and the file pointer.

I have no idea which mode I was compiling in. How can I check that?

I also tried this out in VS 6.0 for testing, assuming that the octet
never is greater then H’F

ASCII += oct + 48;

This worked in VS 6.0 and simply converted the binary number to
ASCII.

BR /// Rob

    CString BCD2ASCII(int num_oct, FILE *fp)
    {
        int count, iOct, iTemp;
        char cTemp[8];
        CString sASCII;

        for (count=0; count<num_oct; count++)
        {

            iOct = fgetc(fpHPSDFOA);
            iTemp = (iOct & 0xF);           

            if (iOct == 0xFF);                        // End of even number found

            else if (iTemp == 0xF)
            {
                iOct = (iOct >> 4) ;
                itoa(iOct,cTemp,16);
                sASCII += cTemp;        // End of odd number found. Store last digit

// old code that doesn’t work in .NET

                //sASCII += ((iOct >> 4) + 48);        // End of odd number found.
Store last digit
            }

            else
            {
                if (iOct <10)
                {
                    sASCII += "0";                    // Filler zero for the octet
                }
           
                itoa(iOct,cTemp,16);
                sASCII += cTemp;
            }

        }
        return sASCII;
    }

Thanks Tom. The static cast worked just fine.

BR /// Rob