В ББ, чтобы не мерцало, используется двойная буферизация (как и везде в современных системах). Однако приборы WinApi, "прикрученные" к ББ с помощью модулей StdCFrames и HostCFrames, намертво вырубают эту буферизацию. Это прямо в их Restore прописано: ВыключитьДвойнуюБуферизацию. Получается так: начинается отрисовка области в окне, при этом включается двойная буферизация; пока рисуются нормальные виды ББ - все идет по плану; как только рисуется любой прибор WinApi - двойная буферизация выключается, т.е. то, что уже попало в буфер, переводится на экран, и дальше всё остальное тоже рисуется прямо на экран - т.е. мерцает. Независимо от того, приборы на форме или в тексте.
В разных источниках я нашел сведения (точнее, вопль и стон), что эти древние, почти доисторические приборы WiApi сами по себе, т.е. без всякого ББ, не совместимы с двойной буферизацией. (Если кто-то опроверг бы - было бы здорово). Сильнее всего это мерцание проявляется на приборах-блокнотах (tabulators, кажется), которые даже в дельфи мерцали (по некоторым сведениям).
Путей решения - несколько: 1) найти в недрах WinApi другой набор флажков или вызовов, обеспечивающих такие же по функциональности приборы. Задача для мужественных. Авторы ББ пошли на недюжинные выверты, чтобы завернуть эти приборы в ББ-шную обертку и обеспечить ими интерфейс Controls.Control. Отжирание памяти, о котором в 11 году выше писали - связано с тем, что там то и дело приходится пересоздавать winapi handles и Frames. Ну и платформозависимо оно будет... 2) прекратить поддержку StdCFrames и HostCFrames как неактульного ныне подхода. В 90е было модно, чтобы приложение "сливалось" по внешнему виду с операционкой, и авторы ББ успешно справились: на Вин оно выглядело как Вин, на Маке - как на Маке (но это не точно). Ныне такой моды нет - у всех фреймворков свои приборы, да еще кастомизация сплошная. Поэтому подход StdCFrames дорогостоящ и неактуален. При этом на замену нужно реализовать все стандартные приборы внутри ББ. Огромную работу Иван Андреевич Денисов уже проделал, написал платформонезависимый HostCFrames, который в 2.0 мы переименовали в StdStdCFrames. Несмотря на ущербность, интерфейса, который налагает StdCFrames.Frame на StdStdCFrames, большая часть функциональности уже есть.
Но я предлагаю выкинуть StdCFrames вообще и реализовать приборы как полноценные виды ББ, т.е. прямые расширения Controls.Control, а не StdCFrames.Frame. У себя я уже сделал и испытываю Edit Field (на базе TextViews), а сейчас работаю над ListBox и их стыковкой в ComboBox, и вообще списками общего вида.
|