Сообщение Re: Миграция с HTMLayout на Sciter 3 от 29.07.2016 17:12
Изменено 29.07.2016 17:13 c-smile
Здравствуйте, Scorpion1105, Вы писали:
S>Метод dom::element::get_attribute(const char* name) раньше возвращал LPCWSTR, и этот указатель очень удобно было использовать для проверки наличия атрибута. Сейчас же получается (если я правильно понимаю), что и при отсутствии атрибута у элемента и при наличии атрибута без значения вернется sciter::string нулевой длины. Как можно однозначно проверить наличие атрибута у элемента по имени в Sciter?
При отсутсивии атрибута SciterGetAttributeByNameCB возвращает SCDOM_OK_NOT_HANDLED результат, можно как-то с этим поработать.
dom::element::get_attribute используется например так
Можно как-то по другому это сделать наверное, предлагай.
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
Можно использовать как есть а можно заменить на
и CSS:
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 потоков.
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>
не нужно.
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 потоков.
Здравствуйте, Scorpion1105, Вы писали:
S>Метод dom::element::get_attribute(const char* name) раньше возвращал LPCWSTR, и этот указатель очень удобно было использовать для проверки наличия атрибута. Сейчас же получается (если я правильно понимаю), что и при отсутствии атрибута у элемента и при наличии атрибута без значения вернется sciter::string нулевой длины. Как можно однозначно проверить наличие атрибута у элемента по имени в Sciter?
При отсутсивии атрибута SciterGetAttributeByNameCB возвращает SCDOM_OK_NOT_HANDLED результат, можно как-то с этим поработать.
dom::element::get_attribute используется например так
Можно как-то по другому это сделать наверное, предлагай.
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
Можно использовать как есть а можно заменить на
и CSS:
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 потоков.
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>
не нужно.
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 потоков.