Андрей, приветствую!

Тема миграции на Sciter с его предшественника уже поднималась пару

Автор: flаt
Дата: 27.03.14

раз

Автор: c-smile
Дата: 05.01.14

, но в процессе возникают вопросы, на которые не удается найти однозначного ответа.
Проект достаточно объемный, поэтому сразу сделать "как надо" не получается — на первом этапе хотелось бы добиться хотя бы компиляции в том виде, в котором оно реализовано у нас на HTMLayout (т.е. без переноса behavior'ов на скрипты как минимум). Особенность проекта — обилие отдельных API / WTL панелек, модальных и немодальных диалогов со встроенным в них html-движком. Со встраиванием, в принципе, разобрался, а вот дальше не всё так гладко.
Подскажите, пожалуйста, как действовать по следующим пунктам (всё касается native кода).

1. Метод dom::element::get_attribute(const char* name) раньше возвращал LPCWSTR, и этот указатель очень удобно было использовать для проверки наличия атрибута. Сейчас же получается (если я правильно понимаю), что и при отсутствии атрибута у элемента и при наличии атрибута без значения вернется sciter::string нулевой длины. Как можно однозначно проверить наличие атрибута у элемента по имени в Sciter?
   
2. Некоторые значения в BEHAVIOR_EVENTS пропали. И если с TABLE_HEADER_CLICK, TABLE_ROW_CLICK, TABLE_ROW_DBL_CLICK более менее понятно, что делать, то вот с CONTEXT_MENU_SETUP — нет.
   
3. Правильно ли я понимаю, что на первом этапе миграции можно адаптировать behavior'ы из HTMLayout к реалиям Sciter'а и использовать их? В частности, если вернуться к BEHAVIOR_EVENTS TABLE_*_CLICK из предыдущего пункта, то их какое-то время может слать адаптированный native-behavior grid, а потом уже что-то придумать со скриптом.
   Может какие-то behavior'ы вообще нет смысла перетаскивать из HTMLayout и они будут работать "из коробки", не подскажите?
   

   	в проекте явно подключены следующие:
   	behavior_accesskeys.cpp behavior_collapsible_by_icon.cpp behavior_editable_select.cpp behavior_grid.cpp behavior_hyperlink.cpp — есть в документации — видимо, переносить не нужно behavior_path.cpp behavior_popup.cpp behavior_select_checkmark.cpp behavior_sizer.cpp behavior_splitter.cpp

   
   
4. И пока самый неочевидный момент — это адаптация htmlayout::gui_task и htmlayout::queue к sciter::gui_thread_ctx. Если с HTMLayout в каждом API/WTL-окне со встроенным html-движком модифицировался цикл выборки сообщений (добавлялся вызов htmlayout::queue::execute()) и где-то в логике накапливались задания в виде gui_task, то как правильно поступать со Sciter — напомню, что в приложении всегда больше одного окна/панельки/диалога с работающим в них движком.