Здравствуйте, Scorpion1105, Вы писали:

S>Метод dom::element::get_attribute(const char* name) раньше возвращал LPCWSTR, и этот указатель очень удобно было использовать для проверки наличия атрибута. Сейчас же получается (если я правильно понимаю), что и при отсутствии атрибута у элемента и при наличии атрибута без значения вернется sciter::string нулевой длины. Как можно однозначно проверить наличие атрибута у элемента по имени в Sciter?

При отсутсивии атрибута SciterGetAttributeByNameCB возвращает SCDOM_OK_NOT_HANDLED результат, можно как-то с этим поработать.

dom::element::get_attribute используется например так

std::wstring val = el.get_attribute("contenteditable", L"false");

if( val != L"false" )
  ...

Можно как-то по другому это сделать наверное, предлагай.

S>Некоторые значения в BEHAVIOR_EVENTS пропали. И если с TABLE_HEADER_CLICK, TABLE_ROW_CLICK, TABLE_ROW_DBL_CLICK более менее понятно, что делать, то вот с CONTEXT_MENU_SETUP — нет.

CONTEXT_MENU_SETUP событие генерируется и поддерживается. С тем же кодом. Добавлю в header.

S>Правильно ли я понимаю, что на первом этапе миграции можно адаптировать behavior'ы из HTMLayout к реалиям Sciter'а и использовать их? В частности, если вернуться к BEHAVIOR_EVENTS TABLE_*_CLICK из предыдущего пункта, то их какое-то время может слать адаптированный native-behavior grid, а потом уже что-то придумать со скриптом.

Да, имеет смысл. Так и предполагалось изначально. Вообще native и script behaviors взаимозаменяемы. Пример \sdk\include\behaviors\behavior_tabs.cpp и sdk\widgets\tabs\tabs.tis

S>Может какие-то behavior'ы вообще нет смысла перетаскивать из HTMLayout и они будут работать "из коробки", не подскажите?
S>[cut=в проекте явно подключены следующие:]
S>behavior_accesskeys.cpp

Из коробки. accesskey функциональность встроена. Не требует behavior.

S>behavior_collapsible_by_icon.cpp

Можно использовать как есть а можно заменить на

function collapsibleByIcon() {
  var me = this;
  this.on("mousedown,mousedclick", ".icon" function() {
     me.attributes["state"] = me.attributes["state"] == "close" ? "open" : "close";
     return true; 
  });
};

и CSS:

div.collapsible { aspect: collapsibleByIcon; }

S>behavior_editable_select.cpp

из коробки.

S>behavior_grid.cpp

Или как есть использовать или sdk\samples\ideas\grid\ — это scripting порт оного.

S>behavior_hyperlink.cpp — есть в документации — видимо, переносить не нужно
не нужно.

S>behavior_path.cpp

встроенный behavior:file-icon;

sdk\samples\goodies\file-icon.htm

S>behavior_popup.cpp

встроенный см. sdk\samples\popup

S>behavior_select_checkmark.cpp

встроенный \sdk\samples\forms\select-list-multiple-checkmarks.htm

S>behavior_sizer.cpp

\sdk\samples\popup\popup-resizing.htm

S>behavior_splitter.cpp

встроенный <frameset>

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

Ничего этого не требуется. Даже если используется несколько GUI потоков.