Здравствуйте, uw, Вы писали:
[зверьковыгрызено]
недоразумение, понял, виноват, каюсь.
сам слушаю и вам рекомендую: silent
Здравствуйте, uw, Вы писали:
uw>Здравствуйте, c-smile, Вы писали:
CS>>Ага. D рулез. Мне он на порядок больше нравится чем C#.
CS>>Как минимум тем что гуёвая "hello world" — 64k и никакого Frameworka не надо — "Зачем нам кузнец?"
uw>Сначала написал пространный текст на тему того, что пока еще не рулез, ибо сырой, в отличие от C#. Затем стер, потому что мне хочется больше узнать об обертке для D и о hsmile вообще. Например поверх чего будет обертка для D. Остальные обертки сделаны на базе высокоуровневых GUI библиотек. Неужели для обертки на D есть приемлимый вариант? Или чистый Win32API?
Внешне hsmile это windowless engine состоящий из одного inbound интерфейса выполненного в виде
набора функций:
CFUNC HSMILE HSMILEAPI create_hsmile_engine(HS_DWORD tag);
CFUNC void HSMILEAPI destroy_hsmile_engine(HSMILE hs);
CFUNC HS_BOOL HSMILEAPI hsmile_handle_mouse(
HSMILE hs,
HS_DWORD event_type,
HS_INT x,
HS_INT y,
HS_DWORD mouse_buttons,
HS_DWORD keyboard_states);
CFUNC HS_BOOL HSMILEAPI hsmile_handle_paint(
HSMILE hs,
#if defined(WIN32)
HDC hdc,
#elif defined(MACOSX)
// nothing here as it draws on current Carbon's CGrafPort
#endif
HS_INT x, // Specifies a rectangle of area to paint
HS_INT y, // in device units relative to
HS_INT width, // the upper-left corner of the client area.
HS_INT height); //
....
Эти функции оборачиваются в C++ html_view класс (в комплекте SDK)
Архитектура проста: host вызывает сам функции hsmile когда он считает
это нужным. Например hsmile_handle_mouse может быть вызвана до, после или вместо
стандартной обработки WM_LBUTTONDOWN WM_MOUSEMOVE и т.д.
Так как HWND hsmile'у не нужен то можно сделать несколько engine на одном HWND
Например темы в виртуальном list view — разные HTML документы. Собственно так отображает
список note Flamer в MeineLiebenNotes.
Имея такую схему HTML rendering можно прицепить к любому окну — например отрисовка
background как HTML в некоем CDialog. hsmile там "стоит рядом" не мешая обрабатывать
всю остальную функциональность dialog системе.
В примере netbrowser.exe (.NET )
http://terrainformatica.com/hsmile/images/netbrowser1.png
стек документов для хождения Previous/Next устроен просто как массив hsmile'ов
hsmilenet11.Engine stack[];
Сам hsmile внутри себя стек документов не держит. Что имхо правильно.
Этот стек очень application specific и хост должен сам им управлять.
------------------------------------------
Также есть два других outbound interface — это адреса callback функций предоставляемые
хостом :
struct HSMILE_HOST_CALLBACK
{
// host's chance to load data for the engine
HS_BOOL (HSMILE_CB *load_data)(void* p, const HS_WCHAR* url, HS_DWORD data_type);
// host's chance to save received data somewhere
void (HSMILE_CB *data_loaded)(void* p, const HS_WCHAR* url, const HS_BYTE* data, HS_DWORD data_size, HS_DWORD data_type);
HS_BOOL (HSMILE_CB *start_timer)(void* p, HS_DWORD timer_id, HS_DWORD millis);
HS_BOOL (HSMILE_CB *stop_timer)(void* p, HS_DWORD timer_id);
...
}
И scripting callback
struct CSMILE_HOST_CALLBACK
{
// stdin/stdout/stderr for scripting engine
CS_BOOL (CSMILE_CB *stdin_getc)(void* p, CS_WCHAR* wc);
CS_BOOL (CSMILE_CB *stdout_putc)(void* p, CS_WCHAR wc);
CS_BOOL (CSMILE_CB *stderr_putc)(void* p, CS_WCHAR wc);
// user defined function callback - call from script
CS_VALUE (CSMILE_CB *udf_call)(void* p, CS_VALUE* argv, int argn );
};
Пояснение: В скрипте hsmile (JavaScript++) есть понятие streams поэтому можно писать так:
function onclick() // function call happens in context
// of element the behavior attached so
// 'this' is the element
{
stdout << "Gotcha! Click on " << this << "\n"; // вызовы stdout_putc....
}
function onmousemove()
{
statusbar.innerText = String.printf("x=%d y=%d",event.x, event.y);
}
Для debugging stdin/stdout удобнее чем alert(something) в стандартном JavaScript
"Неужели для обертки на D есть приемлимый вариант?"
Все зависит от задачи.
Например написане на D servlet'a html2png не требует практически ничего кроме как CreateCompatibleBitmap со товарищи.
Собственно сам по себе hsmile и есть GUI engine. C минимальной оберткой со стороны D . D получает события, исполняет мой eval() и генерирует нужный HTML если надо. Типа того.
А список gui libs для D здесь:
http://www.prowiki.org/wiki4d/wiki.cgi?AvailableGuiLibraries
uw>Заказчик случаем не Walter Bright?
Нет
Здравствуйте, SchweinDeBurg, Вы писали:
SDB>Ну, вот Вам пара примеров навскидку:
SDB>
SDB>Я делал ГУЙ на 15-дюймовом монике в разрешении 800 х 600 (зрение плохое), а у клиента — 21 дюйм и диалоги выглядят "маленькими", путь к файлу целиком в поле ввода не помещается. "Настраиваем" на его машине XML-"шаблоны" — и вуаля.
Несколько идей:
В CDialogXML на titlebar можно добавить кнопочку edit — в результате которой открывался бы встроенный редактор, в котором каждый желающий мог бы настроить контролы диалога "под себя" — это было бы реально круто.
В XML можно хранить всё состояние контролов. Default-ные значение контролов для диалога "Preferences" можно вполне рассматривать как настройки приложения.
Если также сохранять все .xml-ки программы вместе со всеми остальными её настройками в одном архиве — и это могло бы стать чем-то вроде стандарта backup/restore приложений.
Chez, ICQ#161095094
Posted via:RSDN@Home;version:1.1.3;muzikstamp:Radiohead — Climbing Up the Walls
Здравствуйте, SchweinDeBurg, Вы писали:
SDB>Внимание: файл InterfaceXML.zip содержит более поздние версии исходных файлов, чем те архивы, которые можно скачать по ссылкам, указанным в топиках "CDialogXML" и "CMenuXML/CHotKeysXML". Например, в класс CDialogXML добавлена возможность указывать в текстах элементов управления перенос на новую строку с помощью символа "|".
Ненавижу макросы. А вот у тебя в файле PugXML.h
#define Pop() { pCursor = pCursor->parent; }
что конфликтует с методом класса CPushRoutingView в afximpl.h.
И так будет с каждым, кто полезет [чистыми|грязными] руками в структуры языка. Это я по поводу ЯОП.
Здравствуйте, George Seryakov, Вы писали:
GS>Ненавижу макросы. А вот у тебя в файле PugXML.h
Это не у меня, это у автора парсера.
[ posted via RSDN@Home 1.1.4 stable SR1 r568, accompanied by silence ]
Здравствуйте, SchweinDeBurg, Вы писали:
GS>>Ненавижу макросы. А вот у тебя в файле PugXML.h
SDB>Это не у меня, это у автора парсера.
С поправкой согласен, но, как ты понимаешь, это мало что меняет.
А ошибка шикарная, давно такой не видел. Еще бы то макроопределение как-то извратить, чтобы контекстным поиском не находилось, а только просмотром файла после препроцессинга.
Здравствуйте, George Seryakov, Вы писали:
GS>С поправкой согласен, но, как ты понимаешь, это мало что меняет.
Да я понимаю, я сам там #undef-ил некоторые вещи, из-за которых не собиралось у меня. Кстати, более актуальный вариант лежит вот
здесь, так что если соберетель пользовать — то лучше его.
GS>А ошибка шикарная, давно такой не видел. Еще бы то макроопределение как-то извратить, чтобы контекстным поиском не находилось, а только просмотром файла после препроцессинга.
Мсье знает толк...
[ posted via RSDN@Home 1.1.4 stable SR1 r568, accompanied by silence ]