<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-text-html" lang="x-unicode">
      <div class="moz-text-flowed" style="font-family: -moz-fixed;
        font-size: 14px;" lang="x-unicode">On 04.11.2016 16:18, zeljko
        wrote: <br>
        <blockquote type="cite" style="color: #000000;">On 11/04/2016
          03:32 PM, Ondrej Pokorny via Lazarus wrote: <br>
          <blockquote type="cite" style="color: #000000;">On 04.11.2016
            13:16, Luiz Americo Pereira Camara via Lazarus wrote: <br>
            <blockquote type="cite" style="color: #000000;">In the last
              trunk, the slow issue is fixed regardless of usage of <br>
              TextHint in TMemo or not. Fixed also not being reset after
              text <br>
              changed / added <br>
            </blockquote>
            <br>
            I see that r53292, r53293 and r53296 are all about TextHint
            - all this <br>
            code will be removed if we decide to rewrite TextHint, so it
            was just a <br>
            waste of time :( That's why I said better to wait, just to
            save your <br>
            energy. <br>
          </blockquote>
          <br>
          No it's not. It's pure LCL implementation and I guess that we
          won't be able to get it handled on WS side for all widgetsets.
          In that case Bart's implementation will be used. <br>
        </blockquote>
        <br>
        The current implementation opened many issues and bugs. You
        probably won't be able to solve some of them at all or at a
        reasonable effort (both for development and maintenance). E.g.
        try to set the edit font color while the text hint is shown: <br>
          Edit1.Font.Color := clRed; // << execute when TextHint
        is visible <br>
        <br>
        I remember from last year that the TextHint sometimes even
        wasn't correctly hidden. From that point I have never used it. <br>
        <br>
        My opinion is that the current implementation of TextHint should
        be completely removed. Even if TextHint won't be supported on
        all widgetsets. Sometimes it's better to have nothing than to
        have a bad solution. You said Qt5 has native support, so has
        WinAPI, Qt4 can be solved with custom painting -> not a bad
        start at all. <br>
        <br>
        Then there is the question about using the native TextHint. E.g.
        WinAPI supports it but doesn't support custom TextHintFontColor
        and TextHintFontStyle - so what to do if we decide to use native
        TextHint support? My opinion is to keep things simple and both
        TextHintFontColor and TextHintFontStyle should be removed
        because they are superfluous. Is TextHintFontColor and
        TextHintFontStyle supported natively on Qt5?<br>
        <br>
        Using Text and Font properties for an informative-only and
        inessential feature is just a rape of that properties. I mean
        everybody can do it in his own programs but to have such a
        solution on LCL level is not acceptable, in my eyes. In any
        case: if the TextHint property doesn't work, your programs won't
        stop working.<br>
        <br>
        <br>
        <div class="moz-cite-prefix">On 04.11.2016 14:28, Bart via
          Lazarus wrote:<br>
        </div>
        <blockquote
cite="mid:CAMye31zP=9JUKcEedVw5HUmp1g2vBZ8ie392abn1a+hDVDLLOA@mail.gmail.com"
          type="cite">The Windows API provides a nice interface to set
          TextHint (and the possibility to display it if control has
          focus, but Text is empty). At the time I implemented it, I saw
          no API in GTK/QT for a TextHint-like feature.</blockquote>
        <br>
        I see all you say. It was still a bad idea :)<br>
        <br>
        Ondrej <br>
      </div>
    </div>
  </body>
</html>