Solution for the TODO in the CEGUIProperty.cpp and text property expanded to Tooltip

Issue #85 resolved
Former user created an issue

Automatic migration. Original reporter: "Xirnohn"

TODO: Create an helper function to extract whether the property should be inlined or exported as a text node At the moment export only Text property using text node

And now the Tooltip property saves like the Text property. like: <Property Name="Tooltip" >blah blah</Property>

Reproducibility: always

Additional information: I attach the CEGUIProperty.h and CEGUIProperty.cpp.

Comments (9)

  1. Anonymous

    Original reporter: Xirnohn

    One note, why we need to save/load like <Property Name="Tooltip" >blah blah</Property>: with the old formula the xml parser not reads its text with utf8 encodeing, so the éáûõúöüóí characters displaying wrong. The new formula helps me out for this.

    btw i hope i understandable, english not my main language. :(

  2. Anonymous

    Original reporter: lindquist

    Thanx for pointing this out, I think we want a somewhat different solution though. With the new TextProperty tag in Falagard (0.5), users can have arbitrarily many full text properties. The patch you post is too limiting for generic scenarios IMHO.

    What I think we need to do is detect characters that do not work in XML attribute valus and in those cases write the long format. It's fail safe, only costing some speed which is'nt really critical for writing XML. IMHO.

  3. Anonymous

    Original reporter: Xirnohn

    Yes, its a quick and dirty solution, glad to see you work/think on a more generalized result. But while its not in cegui, my patch works, and help me out.

  4. Anonymous

    Original reporter: Dalfy

    I implemented a solution that works independently of the property name. Each time a new line is detected in the property value, I am using the long property format.

  5. Anonymous

    Original reporter: Xirnohn

    Hi Dalfy.

    Your solution not working wery well(its saves Text property with the "sort" property format). Read my first post. To detect a new line its not enough. In StaticText (for example) i dont store multi line texts, but i really often use hungarian characters. So when i dont use new line in the text its saves like: <Property Name="Text" Value="Grafikai beállítások" /> and its render to "Grafikai be÷llít÷sok".

    I suggest that its still need a new detect mode. Maybe search the string for a char that > 127.

    Klaty klaty klaty... Ok, i tried it, its works. Its still a find, but its better now. :D

    const String& value = get(receiver); bool useLong = false; if (value.length() > 0) for (String::size_type at = 0; at < value.length() && !useLong; at++) if (value.at(at) > 127) useLong = true; if (value.find((utf32)'\n') != String::npos) if (useLong)

    I think, its still not the best, and sorry, i cant send a real diff. :(

    Xir.

  6. Paul Turner

    Note to whoever deals with this: If it is our use of the underlying parsers that is causing attribute data to be read incorrectly - that is, in a non UTF8 manner - then this should be fixed in the parsers rather than in property writing.

    The reason for this is that by design it was supposed to come in as UTF8, if this is not happening then it will likely affect other parts of the system as well - so the correct fix would be to XML reading, as opposed to XML writing :)

  7. Anonymous

    Original reporter: Xirnohn

    Hi Eddie.

    I looked into the parser(i using TinyXml parser). When the Text attribute stored with the Name="Text" Value="blabla" its handled with the attrs.add(currAttr->Name(), currAttr->Value()); formula. -No utf conversion.

    When its stored with the long formula(Name="Text">blabla</Property>) its handled with the if (childNode->ToText()->Value() != '\0') d_handler->text((utf8*)childNode->ToText()->Value()); lines, with utf conversion. Maybe change the currAttr->Value() to (utf8*)currAttr->Value()? I will try it.

    Edit: Its works for me, maybe this change need to be applied to the other parsers too.

    Xir.

  8. Anonymous

    Original reporter: Dalfy

    Xirnohn, I have updated two parser in order to solve the issue : Tiny and libxml could you test the latest version in order to close this bug ?

  9. Log in to comment