Настоятельно не рекомендую пользоваться таким способом, вам «повезло» что он работает, но нет никаких гарантий что не сломается или не даст необычные глюки.
Используйте:
Memo1.Lines.BeginUpdate;
try
// изменения
finally
Memo1.Lines.EndUpdate;
end;
Вы кормите мудаков из Эмбракадеро? Ну кто-то же должен кормить мудаков...)
Извини, но ты мудак ;)
На остальное отвечать тебе не вижу смысла.
Поразительно то, что к каждой статье про Delphi найдется такой мудак, не способный пройти мимо. Благо теперь стали минусовать их.
Шутка не должна выглядеть так, было неприятно получить «это» в качестве первого комментария вместо обоснованной критики под своей статьей, тебя заминусовали за это, и не только дельфисты.
А оправдываться что в случае лазаруса ты бы не оставил здесь свой «полезный» комментарий не стоит.
Да, есть ошибка, знаю, но исправить «легко и просто» нельзя к сожалению, это сломает много кода(не моего).
Но я знаю как можно в течении времени исправить, добавив правильный «двойник» свойства, скрыть в дизайнере неправильное свойство через ToolsApi и т.д., при этом из dfm будет считываться неверное свойство, а записываться будет верное свойство. Если возможно будет исправить не сломав совместимость, то будет исправлено.
Согласен, у меня в EsVclComponents есть модуль специальный, который включает «родную» буферизацию для TListView: ES.VclFix.pas
Его достаточно подключить в файле с формой :)
Проблема мерцания и прозрачности все еще актуальна, по причине актуальности VCL, который базируется на довольно консервативном WinApi.
Новое есть — если про VCL, то теперь есть поддержка юникода, скинов.
Появился новый интерфейсный фреймворк — FMX, а с ним и поддержка MacOS, Android, iOS.
В следующем релизе будет серверный Linux.
Ну и кончено же в языке много изменений произошло.
Повторяю — проблема мерцания в классических WinApi приложениях никуда не исчезла, те что не мерцают — сами буферизируют отрисовку или вообще используют один из фреймворков для GUI.
Как я уже писал: «Откройте стандартный «диспетчер устройств» и попробуйте изменять размер окна, оцените мерцание.».
Возможно у вас быстрая машина и вы не успеваете заметить мерцание, или приложение на котором вы проверяете буферизирует отрисовку.
но вы форсируете «папу» «напечататься» (WM_PRINTCLIENT), а это может иметь побочные эффекты. Лет адцать назад я встречал контролы, которые не давали «печататься» — чтобы нельзя было сделать, скажем, слепок с защищенной пдфки, которую контрол демонстрирует.
Как я уже писал, класс показал свою надежную работу :)
Но для таких «кривоватых» контролов я сделал виртуальный метод procedure DrawBackground(DC: HDC); virtual;, в котором для обхода проблем подобных компонентов можно переопределить отрисовку фона.
Кроме того компонент имеет множество настроек буферизации.
К сожалению начиная с Windows Vista, GDI практически перестало использовать 2д ускорение, и к сожалению проблема мерцания никуда не ушла, да о чем говорить — многие стандартные Windows приложения мерцают.
Знаете, при всех недостатках сайта на ассемблере, он все еще держит хабраэффект, при том что многие, очень многие, не выдерживали столько, я считаю что это победа!
Вне обсуждения практичности, автор крут!
Если она уникальная, а не «набор новых текстур» — как многие уверяют, то это же круто!
А в том что на Delphi — не вижу совершенно никаких проблем, наоборот приятно.
Если я ничего не путаю, выкладывали сорцы старых Казаков где-то, они были на C++, возможно Казаки написаны на C++Builder просто, он использует Delphi RTL.
Используйте:
Извини, но ты мудак ;)
На остальное отвечать тебе не вижу смысла.
Поразительно то, что к каждой статье про Delphi найдется такой мудак, не способный пройти мимо. Благо теперь стали минусовать их.
А оправдываться что в случае лазаруса ты бы не оставил здесь свой «полезный» комментарий не стоит.
Но я знаю как можно в течении времени исправить, добавив правильный «двойник» свойства, скрыть в дизайнере неправильное свойство через ToolsApi и т.д., при этом из dfm будет считываться неверное свойство, а записываться будет верное свойство. Если возможно будет исправить не сломав совместимость, то будет исправлено.
Его достаточно подключить в файле с формой :)
Новое есть — если про VCL, то теперь есть поддержка юникода, скинов.
Появился новый интерфейсный фреймворк — FMX, а с ним и поддержка MacOS, Android, iOS.
В следующем релизе будет серверный Linux.
Ну и кончено же в языке много изменений произошло.
Возможно у вас быстрая машина и вы не успеваете заметить мерцание, или приложение на котором вы проверяете буферизирует отрисовку.
В VCL также, посмотрите на саму Rad Studio.
Как я уже писал, класс показал свою надежную работу :)
Но для таких «кривоватых» контролов я сделал виртуальный метод procedure DrawBackground(DC: HDC); virtual;, в котором для обхода проблем подобных компонентов можно переопределить отрисовку фона.
Кроме того компонент имеет множество настроек буферизации.
Вне обсуждения практичности, автор крут!
А в том что на Delphi — не вижу совершенно никаких проблем, наоборот приятно.
https://habrahabr.ru/post/318870/#comment_9992962