HTMLayout рисует элементы в три захода:
background, content и foreground
Данный конкретный behavior перекрывает только рисование content.
CSS задает две картинки
background:
и foreground:
(Последняя полупрозрачная — стекло — IE не умеет рисовать альфу).
Вот как выглядит CSS:
.clock {
behavior:clock; /* name defined in behavior_clock.cpp */
color:black; /* our behavior will use it for "hands" */
width:153px;
height:153px;
/* clock face */
background-image:url(clock-images/clock-back.png);
background-repeat:no-repeat;
background-position:50% 50%; /* middle center */
/* clock glass */
foreground-image:url(clock-images/clock-fore.png);
foreground-repeat:no-repeat;
foreground-position:50% 50%; /* middle center */
}
Т.е. в данном конкретном случае мы "реюзаем" все добавляя только
отрисовку контента.
Вот полный текст behavior_clock.cpp который оживляет картину:
(извиняюсь за полный текст, он не большой)
#include"stdafx.h"#include"behavior_aux.h"#include <math.h>
namespace htmlayout
{
/*
BEHAVIOR: clock
goal: Renders analog clock according to current tome.
TYPICAL USE CASE:
<img style="behavior:clock">
SAMPLE:
html_samples/behaviors/live-clock.htm
*/struct clock: public behavior
{
// ctor
clock(): behavior(HANDLE_TIMER | HANDLE_DRAW, "clock") {} // здесь задается имя behavior для CSSvirtual void attached (HELEMENT he )
{
HTMLayoutSetTimer( he, 1000 ); // set one second timer
}
virtual void detached (HELEMENT he )
{
HTMLayoutSetTimer( he, 0 ); // remove timer
}
virtual BOOL on_timer (HELEMENT he )
{
dom::element el = he;
RECT rc = el.get_location(false);
HWND hw = el.get_element_hwnd(false);
::InvalidateRect(hw, &rc, FALSE);
return TRUE; /*keep going*/
}
virtual BOOL on_draw (HELEMENT he, UINT draw_type, HDC hdc, const RECT& rc )
{
if( draw_type != DRAW_CONTENT ) return FALSE; /* do default draw if not DRAW_CONTENT */
// we can get color settings from attributes but for simplicity lets use
// default values
SYSTEMTIME st;
GetLocalTime(&st);
//Use GetSystemTime(&st); - if you need clocks in UTC or other TZ
//you may use something like get_attribute("timezone")
draw_clock_hand(hdc,rc, (st.wHour * 360) / 12, 0);
draw_clock_hand(hdc,rc, (st.wMinute * 360) / 60, 1);
draw_clock_hand(hdc,rc, (st.wSecond * 360) / 60, 2);
return TRUE; /*skip default draw as we did it already*/
}
void draw_clock_hand( HDC hdc, const RECT& rc, int angle_degree, int hand )
{
double radians = (2 * 3.1415926 * (angle_degree - 90)) / 360.0 ;
int radius = min( rc.bottom - rc.top, rc.right - rc.left ) / 2 - 12;
HPEN hp = 0;
LOGBRUSH logbrush = { BS_SOLID, RGB(0,0,0), 0 };
logbrush.lbColor = ::GetTextColor(hdc);
switch(hand)
{
case 0: // hours
radius = (radius * 3) / 4;
hp = ::ExtCreatePen(PS_GEOMETRIC | PS_SOLID | PS_ENDCAP_ROUND, 5, &logbrush, 0,0);
break;
case 1: // minutes
hp = ::ExtCreatePen(PS_GEOMETRIC | PS_SOLID | PS_ENDCAP_ROUND, 3, &logbrush, 0,0);
break;
case 2: // seconds
logbrush.lbColor = RGB(0x7f,0,0);
hp = ::ExtCreatePen(PS_GEOMETRIC | PS_SOLID, 1, &logbrush, 0,0);
break;
default:
assert(false);
}
int y = (rc.bottom + rc.top) / 2;
int x = (rc.right + rc.left) / 2;
int xe = x + cos(radians) * radius;
int ye = y + sin(radians) * radius;
HGDIOBJ hpBefore = ::SelectObject(hdc,hp);
::MoveToEx(hdc,x,y,0);
::LineTo(hdc,xe,ye);
::SelectObject(hdc,hpBefore);
::DeleteObject(hp);
}
};
// instantiating and attaching it to the global list
clock clock_instance; // регистрация behavior для CSS
} // htmlayout namespace
--EOF
Это собственно демонстрация идеи: UI можно в принципе делать "малой кровью"
программируя только то что действительно надо прогаммировать.
Здравствуйте, c-smile, Вы писали:
CS>Это собственно демонстрация идеи: UI можно в принципе делать "малой кровью" CS>программируя только то что действительно надо прогаммировать.
Меня-то ты еще год назад убедил Я только до сих пор не пойму, почему не XML?
Здравствуйте, c-smile, Вы писали:
CS>Вот тот же behavior но уже прицепленный на другой элемент CS>который в свою очередь тоже под behavior CS>
а не проще-ли просто, сделать тоже самое общепринятыми способами? пока что похоже на эквилибристику и шпагоглотание. успех у зрителей обеспечен, но в повседневной жизни лучше не пробывать.
мне правда, хочется разобраться "где собака порылась".
есть какие нибудь примеры где очевидны приимущества Вашего подхода по сравнению с ощепринятыми?
Здравствуйте, vladserge, Вы писали:
V>а не проще-ли просто, сделать тоже самое общепринятыми способами? пока что похоже на эквилибристику и шпагоглотание. успех у зрителей обеспечен, но в повседневной жизни лучше не пробывать.
V>мне правда, хочется разобраться "где собака порылась". V>есть какие нибудь примеры где очевидны приимущества Вашего подхода по сравнению с ощепринятыми?
Хех, а какие есть общепринятые? Сделать свой HWND-based контрол?
Здравствуйте, Кодёнок, Вы писали:
Кё>Здравствуйте, vladserge, Вы писали:
V>>а не проще-ли просто, сделать тоже самое общепринятыми способами? пока что похоже на эквилибристику и шпагоглотание. успех у зрителей обеспечен, но в повседневной жизни лучше не пробывать.
V>>мне правда, хочется разобраться "где собака порылась". V>>есть какие нибудь примеры где очевидны приимущества Вашего подхода по сравнению с ощепринятыми?
Кё>Хех, а какие есть общепринятые? Сделать свой HWND-based контрол?
??? зачем достаточно того, что есть у базового окна.
Здравствуйте, vladserge, Вы писали: V>мне правда, хочется разобраться "где собака порылась". V>есть какие нибудь примеры где очевидны приимущества Вашего подхода по сравнению с ощепринятыми?
Я тебе рекомендую сесть и написать апплет "стрелочные часы" используя общепринятый подход. У нас, кстати, в курсе программирования на яве такое задание есть. Сравнить количество кода, которое потребовалось написать. После этого, я думаю, сомнений в преимуществах у тебя не останется.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vladserge, Вы писали:
Кё>>Хех, а какие есть общепринятые? Сделать свой HWND-based контрол?
V>??? зачем достаточно того, что есть у базового окна.
Здравствуйте, vladserge, Вы писали:
V>Здравствуйте, c-smile, Вы писали:
CS>>Вот тот же behavior но уже прицепленный на другой элемент CS>>который в свою очередь тоже под behavior CS>>
V>а не проще-ли просто, сделать тоже самое общепринятыми способами? пока что похоже на эквилибристику и шпагоглотание. успех у зрителей обеспечен, но в повседневной жизни лучше не пробывать.
V>мне правда, хочется разобраться "где собака порылась". V>есть какие нибудь примеры где очевидны приимущества Вашего подхода по сравнению с ощепринятыми?
Скожем вот sliding panel c list box:
Каким "общепринятым способом" предлагается это сделать?
Ни стандарьный Windows API ни WinForms этого тебе не позволяют.
И вообще HTML based UI это уже и есть один из общепринятых способов.
В самом общепринятом виде (встраивание IE или Mozilla) у него есть
ограничения для использования внутри приложений.
Данный конкретный компонент просто снимает основные ограничения.
Здравствуйте, c-smile, Вы писали:
CS>Скожем вот sliding panel c list box: CS>
CS>Каким "общепринятым способом" предлагается это сделать?
CS>Ни стандарьный Windows API ни WinForms этого тебе не позволяют.
Кстати обрати внимание что этот самый ListBox прозрачный.
Прозрачность дочерних окон в Windows вообще отсутсвует.
(Только не говорите мне про WS_EX_TRANSPARENT пожалуйста — это фикция)
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, vladserge, Вы писали:
V>>Здравствуйте, c-smile, Вы писали:
CS>Данный конкретный компонент просто снимает основные ограничения.
где можно подробнее почитать по внутреннему устройству, архитектуре HTMLayout
Здравствуйте, Кодёнок, Вы писали:
Кё>Здравствуйте, c-smile, Вы писали:
CS>>Это собственно демонстрация идеи: UI можно в принципе делать "малой кровью" CS>>программируя только то что действительно надо прогаммировать.
Кё>Меня-то ты еще год назад убедил Я только до сих пор не пойму, почему не XML?
Я не понял а что такое XML?
XML и ASCII — это способы описания данных но не язык в чистом виде.
Что ты имеешь ввиду конкретно?
CS>>принципиально отличается от CS>>API: CS>> ::DrawText(hdc, ..., "1", 1);
CS>>Я не честно не понимаю.
А>А я не понимаю о чем речь во втором примере. Первое описание мне понятно. А>Вот собственно и разница.
Здравствуйте, vladserge, Вы писали:
V> где можно подробнее почитать по внутреннему устройству, архитектуре HTMLayout
Хороший вопрос, однако.
Надо его как-то осветить на сайте.
На самом деле ничего волшебного:
Есть специализированный DOM — его конcтруирует парсер или "руками" с помощью
static dom::element create(const char* tagname, const wchar_t* text = 0)
И есть behaviros — сущности цепляемые к элементам DOM — event handlers.
DOM cнаружи виден как иерархия HELEMENTs — можешь считать их lightweight HWND — абстракция достаточно
близка. behavior — это будет WndProc. Собственно и все.
Основные "фишки":
1) все дерево HELEMENT стилируется как единая система с помощью CSS. В зависимости от контекста тот же самый <SELECT> может выглядеть по разному.
2) все "сложные" HELEMENTs (например <SELECT>) есть просто части DOM и состоят из простых компонентов — тоже HELEMENT. Всем "ансамблем" в <SELECT> управляет специальный встроенный behavior.
Я не стал выносить базовые behaviors наружу по простой причине — при встраивании например в
PowerBasic пришлось бы их все переписывать на PB — не хочется.
Здравствуйте, c-smile, Вы писали:
CS>Я не понял а что такое XML?
Язык на основе XML, наилучшим образом подходящий для описания UI.
CS>XML и ASCII — это способы описания данных но не язык в чистом виде. CS>Что ты имеешь ввиду конкретно?
В HTML есть фиксированный набор тэгов, семантика которых довольно неудобна. <SPAN> <DIV> — наиболее общие, <B> <I> <P> <H1> — какие-то частные случаи, фактически дублирующие <SPAN> или <DIV>. Это было хорошо давным-давно, до CSS, в самом начале языков разметки. С появлением CSS это только мешает.
Я имею ввиду возможность, например, один раз определить тэг <button>, который потом развернется скажем в <DIV style="display: inline-block"> + текст с присоединённым к нему базовым CSS. Потом можно натыкать этих тэгов-кнопок по всему диалогу. Это и улучшит понятность исходника UI, уменьшит ошибки связанные с Copy+Paste, да и просто уменьшит размер UI.
Здравствуйте, vladserge, Вы писали:
V>Здравствуйте, Sinclair, Вы писали:
S>>Я тебе рекомендую сесть и написать апплет "стрелочные часы" используя общепринятый подход.
V>сел, написал V>сравнил, сомнения остались
Клево
Только идея на самом деле не о том чтобы нарисовать стрелки — это к тому же на win API получилось проще чем на Java.
Основная фишка во всей системе резиновых HTML элементов и каскадирования CSS.
смотри:
img.clock
{
behavior: clock;
width: 100px;
height:100px;
border:1px solid red;
}
p img.clock
{
border:1px dased green;
padding:4px;
width: 10px;
height:10px;
}
div.clock
{
border:1px dased blue;
padding:10px;
width:100%%;
height:100%%;
}
------------------
<img class=clock>
<p>А вот здесь уже будут другие <img class=clock> ходики. Их вид и положение зависит от контекста.</p>
<p>А вот ходики которые занимают все оставшееся место на view</p>
<div class=clock></div>
В принципе почти все это можно как-то с'эмулировать при помощи java LayoutManagers.
C inline элементами правда придется повозится.
Кстати концептуально java Layouts очень толковая штука.
Но вот основная беда layout managers — они не рисуют.
Принципиально в современном UI достаточно много всяких сугубо оформительских
деталей которые приходится сейчас руками програмировать. См например мой топик "XAML,XAML" —
опять ведь руками все написано хотя казалось бы у них все есть.
По хорошему тоже кстати еще тебе надо добавить какой-нибудь XML парсер что-бы хотя бы какая-то декларативность
была для сравнения.
Ну да ладно — и так понятно что задачу можно и должно решить способом подходящим
к данному контексту — сиречь не одним единственным.
Спасибо тебе vladserge большое — вельми показательно.