On 04.11.2016 16:18, zeljko wrote:
On 11/04/2016 03:32 PM, Ondrej Pokorny via Lazarus wrote:
On 04.11.2016 13:16, Luiz Americo Pereira Camara via Lazarus wrote:
In the last trunk, the slow issue is fixed regardless of usage of
TextHint in TMemo or not. Fixed also not being reset after text
changed / added

I see that r53292, r53293 and r53296 are all about TextHint - all this
code will be removed if we decide to rewrite TextHint, so it was just a
waste of time :( That's why I said better to wait, just to save your
energy.

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.

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:
  Edit1.Font.Color := clRed; // << execute when TextHint is visible

I remember from last year that the TextHint sometimes even wasn't correctly hidden. From that point I have never used it.

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.

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?

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.


On 04.11.2016 14:28, Bart via Lazarus wrote:
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.

I see all you say. It was still a bad idea :)

Ondrej
-- 
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Reply via email to