Форум: "KOL";
Текущий архив: 2007.02.25;
Скачать: [xml.tar.bz2];
ВнизОтрисовка XP контролов. Bug. Найти похожие ветки
← →
AndreyRus (2006-05-04 14:10) [0]Я заметил, что отрисовка контролов, при использовании манифеста, в стиле "Win XP" происходит во время показа формы. Особенно это заметно на TFT-мониторах, в следствии их инерционности. Проблему удалось решить назначив контролам и форме (хотя, непонятно зачем и для формы) свойство- DoubleBuffered. Однако если контролы находятся в GroupBox то при их прорисовке происходит "глюк" - RadioBox становиться черным, кнопки обрисовываются черной линией и.т.д. Знает ли кто нибудь как бороться с этой ошибкой.
← →
ECM © (2006-05-04 14:42) [1]А если попробовать графические контролы (windowed=false)?
← →
AndreyRus (2006-05-04 17:28) [2]
> А если попробовать графические контролы (windowed=false)?
В этом случае контролы вообще не отображаются, пока на них не навести курсор мыши. К тому же теряется отображение в стиле "Windows XP".
← →
ECM © (2006-05-04 18:11) [3]Какая верси KOL у Вас ?
Описанные эффекты в последней версии (у меня точно) полностью отсутствуют.
Почитайте
http://delphimaster.net/view/11-1136725971/
← →
homm © (2006-05-04 23:50) [4]
> AndreyRus (04.05.06 14:10)
Дохлый Bug Report. Я сразу сказал, фиг будут новые темы рисоватся с моей прозрачностью. Все вопросы на support@microsoft.com, т.к. это только их темк не рисуется правильно. Есть по-настоящему качественные темы, созданые с нуля а не с microsoftовского примера, в которых проблем нет. Пример - тема MacOS (другие на вскидку не помню). Хочеш красивости - юзай GRush.
← →
homm © (2006-05-04 23:55) [5]
> [3] ECM © (04.05.06 18:11)
Неа, пусть лучше прочитает ветку где прозрачность by me впервые появилась, там то-же самое написано.
И еще
> Я заметил, что отрисовка контролов, при использовании манифеста,
> в стиле "Win XP" происходит во время показа формы.
Зашибись! А когда же ей еще происходить?
← →
homm © (2006-05-04 23:56) [6]ЗЫ Какой-то я весь сегодня на нервах. Простите, если что...
← →
AndreyRus (2006-05-05 00:13) [7]
> > Я заметил, что отрисовка контролов, при использовании
> манифеста,
> > в стиле "Win XP" происходит во время показа формы.
> Зашибись! А когда же ей еще происходить?
IMHO. Отрисовка сложных графических элементов должна производится не в момент отображения формы, а до него.
← →
AndreyRus (2006-05-05 00:46) [8]
> Какая верси KOL у Вас ?
2.34
← →
homm © (2006-05-05 07:28) [9]Чудеса говорите. Хорошую книжку по WinAPI вым почитать надо. Система же не будет сама буфер создавать перед появленем окна, по 2-м вполне обоснованым причинам. 1) каким-то приложениям он и не нужен, а оперативу и/или видео засоряет 2) Для каких-то операций прорисовки (как например с этими глупыми тетмами, кстати) буферная канва неприемлима, нужна экранная.
← →
AndreyRus (2006-05-05 14:27) [10]Напали на новичка и заели :) , забыв о сути.
Конфигурация моего компьютера - Pentium II (Celeron) 300 Мгц, старая видюха на медленной шине, но 19" TFT монитор. При такой конфигурации я отчетливо вижу, что обрисовка контролов формы, особенно в стиле XP происходит в момент показа отображения формы - Form.Show. Я стал искать способ борьбы с этим эффектом и обнаружил, что если у контролов и формы (обязательно! Но непонятно зачем?) DoubleBuffered:= true, то форма контролы прорисовываются гораздо быстрее, без эффекта отрисовки в момент их отображения, но если они находятся в контейнере, например - GroupBox, то наблюдается ошибка при их отображении, в виде искажения цветов.
← →
ECM © (2006-05-05 14:56) [11]
> Конфигурация моего компьютера - Pentium II (Celeron) 300
> Мгц, старая видюха на медленной шине, но 19" TFT монитор
И это все под ХР? - может не надо мучать технику? :)
> обязательно! Но непонятно зачем?) DoubleBuffered:= true,
>
А почитать (погуглить) что это такое уже лень?
Doube - (двойной) - вся отрисовка производится во втром буфере( буфер в памяти) а вывод на экран производится быстрой операцией копирования BitBlt. Иначе все операции отрисовки производятся прямо в экранный буфер (DC)
← →
AndreyRus (2006-05-05 15:54) [12]Что такое буферизация мне хорошо известно.
1. Мне неизвестно почему необходимо буферизировать и форму и контрол.
2. Почему возникают проблемы с отрисовкой контролов находящихся в контейнере.
← →
homm © (2006-05-05 18:16) [13]
> 1. Мне неизвестно почему необходимо буферизировать и форму
> и контрол.
Такая реализация. Просто если бужеризован И родитель И дочерний контрол, то дочерний контрол отрисовывает прямо на буфере родителя, не создавая свой собственный.
> Я стал искать способ борьбы с этим эффектом и обнаружил,
> что если у контролов и формы (обязательно! Но непонятно
> зачем?) DoubleBuffered:= true, то форма контролы прорисовываются
> гораздо быстрее
Прорисовка с двойной буферизацией даже в теории не может занимать меньшее время, тем более на практике. В том ее и смысл, что она происходит в НЕВИДИМЫЙ буфер (за то-же самое время), после чего весь этот буфер мгновенно копируется на экран (в видео память).
> 2. Почему возникают проблемы с отрисовкой контролов находящихся
> в контейнере.
Похоже ты прав, и такой эффект действительно имеет быть, причем это не совсем тот-же эффект о котором я говорил. Но я даже не стану смотреть, возможно ли его исправить (чотя чувствую что возможно) по одно простой причине: то, о чем я говорил в [9] исправить уже никак нельзя, так что стоит ли убирать с дороги камешек, если на пути впереди все равно гора?
← →
homm © (2006-05-05 18:18) [14]
> то, о чем я говорил в [9]
сори, в [4]
← →
AndreyRus (2006-05-05 19:34) [15]
> Прорисовка с двойной буферизацией даже в теории не может
> занимать меньшее время
Разумеется. Я неверно выразился, говоря о скорости прорисовки. Контролы рисуются не быстрее, а полностью сформированные(нарисованные). На моем компьютере в момент отображения формы я отчетливо вижу как рисуется контрол, т.е. мигание в области его TRect и последующая обрисовка краев. Это, кстати, присуще и VCL.
> стоит ли убирать с дороги камешек, если на пути впереди
> все равно гора?
Очень даже стОит. Например, в досточно сложных программах, таких как MS Office, отображение диалоговых окон даже с большим количеством элементов управления происходит практически как единичный BitBlt. Тоже самое можно было бы сделать и в KOL, если бы ни этот камушек.
← →
homm © (2006-05-05 19:48) [16]Нк тогда поиграйтесь со стилями у GroupBox, так как у Panel таких проблем нет и когда я тупо присваиваю GroupBox.Styles := Panel.Styles почернение у дочерних контролов пропадает, но GroupBox становится соответственно не отличим от панели, кроме того сам становится черным.
← →
Vladimir Kladov (2006-05-05 21:39) [17]Если весь затык в групбоксе - так може просто без него обойтись? (Неправильный он, с темами не дружит немного. Вообще-то групбокс в GDI реализован на базе кнопки. Это так, к слову). В KOL групбокс никакой особой функциональности не несет. Так, панель с рамкой. Рамку можно и самому нарисовать, есди очень хочется.
← →
Vladimir Kladov (2006-05-05 21:45) [18]Если весь затык в групбоксе - так може просто без него обойтись? (Неправильный он, с темами не дружит немного. Вообще-то групбокс в GDI реализован на базе кнопки. Это так, к слову). В KOL групбокс никакой особой функциональности не несет. Так, панель с рамкой. Рамку можно и самому нарисовать, есди очень хочется.
← →
AndreyRus (2006-05-06 11:38) [19]
> Если весь затык в групбоксе - так може просто без него обойтись?
От проблем, как и в реальной жизни, не стоит убегать, т.к. в дальнейшем их станет слишком много и они наберут жирок.
> Неправильный он, с темами не дружит немного
А можно полюбопытствовать, с чем конкретно он не дружит?
> В KOL групбокс никакой особой функциональности не несет.
Равно как и ... везде, но тем ни менее активно используется при оформлении диалоговых форм. Это красиво. Особенно при использовании тем XP.
← →
homm © (2006-05-06 17:49) [20]
> От проблем, как и в реальной жизни, не стоит убегать, т.к.
> в дальнейшем их станет слишком много и они наберут жирок.
Только не думай, что я хочу накатить, но это твои проблемы и если их кто-то должен решать, то это ты. Не имей такой привычки - лечить других. Особено в реальной жизни.
> А можно полюбопытствовать, с чем конкретно он не дружит?
Люди, делавшие темы не дружат смозгами. Ты сказал, что новичек. Придется привыкать - в microsoft лучшие умы работают на ядре и других 2-х кольцах. Кодом, выполняющимся в пользовательском режиме (API разные) обычно занимаются люди из разряда третий сорт- не брак (не хочу сказать, что сам умнее, просто ошибки и кривизна сплош и рядом).
> В KOL групбокс никакой особой функциональности не несет
А вот это на водит на мысль: что, если оставить родителем всех контролов форму, и просто перетащить их "над" GroupBox. У меня сработало вроде. Не забудь только BringToFront для всех контролов задать. Кстать вроде можно задать какое-то свойство у GroupBox меньше, чем у остальных контролов и тогда они будут создаваться вперед них и не нужен будет BringToFront. Никто не помнит, что за свойство?
> Равно как и ... везде, но тем ни менее активно используется
> при оформлении диалоговых форм. Это красиво. Особенно при
> использовании тем XP.
А GRushControls имхо(как же иначе, то :) ) еще красивее.
← →
ECM © (2006-05-06 19:14) [21]
> homm © (06.05.06 17:49) [20]
> Никто не помнит, что за свойство?
TabOrder
← →
AndreyRus (2006-05-07 08:31) [22]
> Люди, делавшие темы не дружат с мозгами.
Это мне известно, равно как и то, что XP превалирует на рынке операционных систем и это необходимо учитывать при разработке ПО. Лично я столкнулся еще и с тем, что при использовании темы контролы могут немного менять свой размер и положение на форме. Для борьбы с этим приходится вручную просматривать формы и в run-time делать коррекцию. Для определения использования темы я написал нижеследующий код:
var
IsAppThemed: function: Boolean; stdcall;
IsThemeActive: Boolean;
begin
if OS_XP or OS_2003 then
begin
@IsAppThemed:= GetProcAddress(LoadLibrary("uxtheme.dll"), "IsAppThemed");
if (@IsAppThemed <> nil) and IsAppThemed then IsThemeActive:= true else IsThemeActive:= false;
end;
if IsThemeActive then Button1.Left:= Button1.Left + 2;
end;
Я прочитал статью - http://www.rsdn.ru/article/winshell/themes.xml и думаю, что описанная мной проблема вероятнее всего связана с реализацией прозрачности. Вот выдержки из этой статьи:
Если элемент содержит прозрачные или полупрозрачные фрагменты (что определяется через IsThemeBackgroundPartiallyTransparent), то сперва производится отрисовка окна, владеющего данным, через DrawThemeParentBackground.
В случае прозрачности/полупрозрачности элемента-заполнителя нам нужно отрисовывать ту часть окна-владельца данного органа управления, которая перекрывается нашим органом управления.
← →
ECM © (2006-05-07 11:21) [23]
> if OS_XP or OS_2003 then
При использовании KOL проще (да и правильнее - а под Vista и будущими версиями темы уже не нужны?) делать так
if WinVer >= wvXP then
KOL.PAS
...
type
TWindowsVersion = ( wv31, wv95, wv98, wvNT, wvY2K, wvXP, wvLongHorn );
{* Windows versions constants. }
TWindowsVersions = Set of TWindowsVersion;
{* Set of Windows version (e.g. to define a range of versions supported by the
application). }
function WinVer : TWindowsVersion;
{* Returns Windows version. }
function IsWinVer( Ver : TWindowsVersions ) : Boolean;
{* Returns True if Windows version is in given range of values. }
...
← →
fellix (2006-05-07 13:42) [24]Похоже, для ХР и выше стоит использовать АПИшный дабл-буфферинг (WS_EX_COMPOSITED).
← →
Vladimir Kladov (2006-05-07 14:09) [25]Выдержку из MSDN киньте плиз про WS_EX_COMPOSITED, а то у меня MSDN 2000, в нем нету.
← →
ECM © (2006-05-07 14:22) [26]Хм... у меня MSDN 2003 но там то же нету... В SDK для W2k3 есть только
WinUser.h:
#if(_WIN32_WINNT >= 0x0500)
#define WS_EX_COMPOSITED 0x02000000L
#define WS_EX_NOACTIVATE 0x08000000L
#endif /* _WIN32_WINNT >= 0x0500 */
На сайте MSDN написано следующее:
WS_EX_COMPOSITED
Windows XP: Paints all descendants of a window in bottom-to-top painting order using double-buffering. For more information, see Remarks. This cannot be used if the window has a class style of either CS_OWNDC or CS_CLASSDC.
← →
fellix (2006-05-07 14:50) [27]Syntax
HWND CreateWindowEx(DWORD dwExStyle, ...);
Parameters
dwExStyle
[in] Specifies the extended window style of the window being created. This parameter can be one or more of the following values.
...
WS_EX_COMPOSITED
Windows XP: Paints all descendants of a window in bottom-to-top painting order using double-buffering. For more information, see Remarks. This cannot be used if the window has a class style of either CS_OWNDC or CS_CLASSDC.
...
Remarks
...
Windows XP: With WS_EX_COMPOSITED set, all descendants of a window get bottom-to-top painting order using double-buffering. Bottom-to-top painting order allows a descendent window to have translucency (alpha) and transparency (color-key) effects, but only if the descendent window also has the WS_EX_TRANSPARENT bit set. Double-buffering allows the window and its descendents to be painted without flicker.
← →
homm © (2006-05-07 18:47) [28]
> В SDK для W2k3 есть только
Значит и в самом W2K есть?
> -to-top painting order allows a descendent window to have
> translucency (alpha) and transparency (color-key) effects,
> but only if the descendent window also has the WS_EX_TRANSPARENT
> bit set.
Что-то не вышло такого эффекта :( Ни чекбокс, ни PaintBox ни стали прозрачными. Может он тоже с темами не дружит :)
← →
Vladimir Kladov (2006-05-07 20:35) [29]Надо брать новый MSDN и смотреть. У меня при попытке получить справку MSDN on-line бедный завис напрочь, а Opera показывает только менюшку, а топик пустой, хоть кликай, хоть обновляй страничку.
← →
ECM © (2006-05-07 20:43) [30]
> homm © (07.05.06 18:47) [28]
>
> > В SDK для W2k3 есть только
>
> Значит и в самом W2K есть?
W2k3 <=> Windows 2003
Но #if(_WIN32_WINNT >= 0x0500) - предполагает что для W2k (win2000) эта константа определяется... Хотя коментарии к ней в МСДН говорят что XP.
:(
Тут надобы проверить экспериментально...
← →
fellix (2006-05-07 21:29) [31][27] - это фрагмент из MSDN April 2003, PSDK 2005 и msdn.microsoft.com. Всюду одно и то же. Больше информации нет.
← →
AndreyRus (2006-05-20 10:35) [32]Кстати, если манифест подключается как внешний файл, то контролы вообще не прорисовываются.
Причем, если не используется DoubleBuffered, то на их месте наблюдается "дырка", т.е. видно нижлежащее окно.
При использовании буферизации контрола получаем черноту, а при использовании буферизации и формы и контрола получаем чистую форму без отрисованных контролов.
← →
ECM © (2006-05-22 13:38) [33]
> AndreyRus (20.05.06 10:35) [32]
> Кстати, если манифест подключается как внешний файл, то
> контролы вообще не прорисовываются.
У меня всё прорисовывается - и как внешний и в ресурсах...
(D6 Win2k3 KOLMHXP)
← →
AndreyRus (2006-05-22 16:13) [34]У меня D7, KOL - 2.34, XP - SP1
Mainfest:<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity type="win32" name="KOL" version="1.0.0.0" processorArchitecture="*"/>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" publicKeyToken="6595b64144ccf1df" language="*" processorArchitecture="*"/>
</dependentAssembly>
</dependency>
</assembly>
← →
AndreyRus (2006-05-28 23:21) [35]Заметил еще один глюк. При DoubleBuffered у формы и Memo, последний отрисовывается стилем XP только при наведении курсора.
Страницы: 1 вся ветка
Форум: "KOL";
Текущий архив: 2007.02.25;
Скачать: [xml.tar.bz2];
Память: 0.55 MB
Время: 0.04 c