Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>HTMLayout реализует так называемую "event sinking/bubbling model" ("модель погружения/всплытия"). В ней событие проходит 2 раза: от всего окна к конкретному элементу, и от элемента к окну. Например, если есть вот такой html: ЗХ>
Здравствуйте, Left2, Вы писали:
L>Спрошу здесь — благо в этой ветке вижу и создателя библиотеки, и людей которые её юзали. У меня есть HTA-application, средней величины — и есть мечта уползти от MSHTML и пришить HTMLLayout, за счёт чего получить возможность портировать всё это на CE (я правильно понимаю что HTMLLayout работает на CE?).
L>Так вот — хотелось бы узнать во сколько уважаемые знатоки ( ) оценят трудоёмкость переезда с MSHTML на HTMLLayout? В частности, у меня на форме хостятся пару ActiveX-ов (грубо говоря — самописные ListControl и TreeControl). Как у HTML Layout с поддержкой ActiveX?. Плюс к этому, через window.external в клиентский JavaScript выставляется довольно много ActiveX-контролов (писаных на ATL). Насколько трудоёмко переписать их под HTMLLayout? Да, и есть ли проблемы с переездом JavaScript из MS-овской имплементации в имплементацию HTMLLayout? L>Ну и самый интересный для меня вопрос — насчёт отладки JavaScript внутри HTMLLayout — возможно ли это, есть ли выделенный отладчик, и т.п.
L>Заранее благодарен за ответы — развёрнутых ответов не прошу, буду рад хотя бы просто ссылкам или ключевым словам.
Если используются скрипты то надо Sciter использовать.
1) трудоемкость переноса оценить трудно. Основная масса вещей делаются легче и меньшей кровью чем в IE это точно.
2) ListControl и TreeControl есть встроенные — т.е. ничего особого делать не надо.
3) "клиентский JavaScript выставляется довольно много ActiveX-контролов (писаных на ATL)" — если это просто custom objects (не UI) компоненты то просто делается набор native classes для scriptа. В принципе плоско параллельный перенос.
4) если используется custom рисование то его можно делать с пом graphics (AGG based vector graphics primitives от великого и ужасного McSeem2) прямо в скрипте.
Я еще не компилировал mosciter (Mobile Sciter) в виде dll (встраиваемый компонент) для mobile. Сделаю в ближайшие неделю две.
Отладка.
Я думал про схему связи desktop sciter <-> mobile sciter.
На mobile стороне переопределить stdin/stdout на соединение с desktop версией. Т.е. desktop sciter будет выступать в качестве remote console для mobile. (такая связь полезна сама по себе.)
Но в принципе так как модель desktop sciter и mobile абсолютно идентичны то можно отлаживаться на десктопе — html/css/script будуь работать идентично на мобиле — один codebase.
Единственное что осталось непонятным — насчёт отладки. Мне интересен именно standalone отладчик — к примеру, оччень хотелось бы отлаживать скрипт примерно так же как я его сейчас отлаживаю из-под Visual Studio, с полноценным отладчиком (пошаговое исполнение, просмотр всех скриптовых переменных — must have ). Вот и хотел узнать есть ли такой для Sciter?
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>HTMLayout реализует так называемую "event sinking/bubbling model" ("модель погружения/всплытия"). В ней событие проходит 2 раза: от всего окна к конкретному элементу, и от элемента к окну. Например, если есть вот такой html: ЗХ>
Если повесить на <button> ("последний тэг") обработчик и возвращать TRUE, то тогда я его ловлю на стадии "погружения" и "всплытия" не будет.
Правильно?
Здравствуйте, Ash-2, Вы писали:
A2>Если повесить на <button> ("последний тэг") обработчик и возвращать TRUE, то тогда я его ловлю на стадии "погружения" и "всплытия" не будет. A2>Правильно?
На момент написания мануала да.
Сейчас, как я понимаю, уже нет. Сообщение будет передаваться дальше, маркированное как HANDLED.
htmlayout_behavior.h
enum PHASE_MASK
{
BUBBLING = 0, // bubbling (emersion) phase
SINKING = 0x08000, // capture (immersion) phase, this flag is or'ed with EVENTS codes below
HANDLED = 0x10000 // event already processed.
// see: http://www.w3.org/TR/xml-events/Overview.html#s_intro
};
A>>Все сгенерированные элементы имеют установленный бит состояния STATE_SYNTHETIC, что позволяет их отсеивать.
а вообще, былобы полезно перечень ситуаций с авто-генерацией иметь.
есть там всякие "прозрачные <p>", когда не блочные элементы в блочном контексте встречаются и т.п.
потому, что это время от времени подбрасывает сюрпризы в лаяуте, особенно новичкам, которые еще не научились дебажить лаяут.