"message" started to contain text like "0x1234d34" instead of the sent text

Hello There,

Starting from yesterday evening (tried yesterday and today), messages (private message in my example) sent through Photon Chat became broken. Instead of the message I sent, everytime I receive something like "0x1234d34". "sender" parameter is fine though and messages were fine till yesterday evening as well. Is there any known issue on the servers?

Thanks,

Özden

Comments

  • Hi @Ozden79:
    Are you sure you did not change anything in the Client code?
    Could you please provide the output of printf("%ls", message.toString().cstr()); on both, the sending and the receiving client?
  • ok, something interesting, when I use your code, I get the correct string "FI", but using this code to turn it into a string : "ExitGames::Common::ValueObject(message).getDataCopy().cstr()" gets out a result string as "0x1406d54". Why?

    P.S. : I've been instructed to use the conversion that I've shown in another thread and I can swear :) it was working.
  • Alright, found the issue. It seems need to convert to UTF8 before c string, like :

    ExitGames::Common::ValueObject(message).getDataCopy().UTF8Representation().cstr()
  • Kaiserludi
    Kaiserludi admin
    edited November 2015
    JString.cstr() returns a wchar_t*, while UTF8String.cstr() returns a char* and JString.UTF8Representation() converts a JString into a UTF8String.

    Which of those you need or if you can use both depends on what you want to do.
    For example std::wcout and std::wcerr expect a wchar_t*, while std::cout and std::cerr expect a char*.
    The same is true for wprintf() vs. printf(), fwprintf() vs. fprintf() and so on. However with those printf familiy functions this ins only true for the format string itself. You can happily pass in wchar_t* to printf and char* to wprintf as additional arguments, if you use the according format specifiers:
    printf("%ls, %s\n", L"I am a wide string", "I am a narrow string");
    Please note the leading 'L' for the widestring literal.

    "P.S. : I've been instructed to use the conversion that I've shown in another thread"
    Sure, but as I mentioned over there, toString() is not meant for normal operation payload retrival, but as help for logging purposes and for debugging the code when you run into problems. And outputting the content of object for debugging purposes (to see if the source of the problem is on the sending client, the receiving client, the server or somewhat in between) is exactly what was needed here to get more info. That is why I asked you to try toString().
    I do not ask you use toString() in the actual game logic, but just for debugging (otherwise you would again have that issue from the other thread).
    The problem at hand is not toString() vs. getDataCopy(), but "%ls" vs "%" and .cstr() vs. UTF8Representation().cstr() .