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

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

Вот, это именно та информация, которой не хватало (предполагал, что так и есть, но уверенности не было).
Вариант с проверкой значения по умолчанию был первым, что пришло в голову, но он может оказаться неудобен, если значение атрибута совпадает с этим значением по умолчанию. Второй вариант — обертка, вызывающая SciterGetAttributeByNameCB для элемента и проверяющая возвращаемое значение — т.к. про него теперь точно известно, то этот вариант и буду использовать.

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

А идеальный вариант — это добавить метод в dom::element. Примерно такой:

  /**Check attribute existence by name.
    * \param name \b const \b char*, name of the attribute
    * \return true if element has attribute specified, false otherwise
    **/
    bool has_attribute( const char* name ) const
    {
      SCDOM_RESULT r = SciterGetAttributeByNameCB(he, name, &_NULL_LPCWSTR_RECEIVER, nullptr);
      return r != SCDOM_OK_NOT_HANDLED;
    }

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

Отлично, спасибо.

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

По behavior'ам информацию принял, еще раз спасибо. Здесь, значит, проблем возникнуть уже не должно.

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

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

Не требуется — в смысле, что не нужно адаптировать? Или же, что gui_task'и можно теперь выполнять, не дожидаясь попадания в цикл выборки сообщений?
P.S. А вообще, то ли я совсем сам себя запутал, то ли старый queue и новый gui_thread_ctx — суть абслоютно разные вещи и для разных целей, а аналога queue теперь просто нет.

---
Появился еще один вопрос. Будет уже, получается, пунктом 5.

5. Есть ли полные аналоги (или полный охват хотя бы) для флагов UPDATE_ELEMENT_FLAGS. С REDRAW_NOW понятно — использовать update(true), но по коду активно используются еще, например, RESET_STYLE_THIS. А без варианта el.update(MEASURE_DEEP | REDRAW_NOW) в одном месте так вообще ничего сделать не могли, код переписывался раз с десяток и в итоге пришли к варианту вот с таким комментарием:

         /* При изменении содержимого секции с большой долей вероятности
            меняется её размер. В некоторых случаях (после работы
            автопроцедур, например) при отсутствии активности мыши обычный
            update с параметром типа bool не давал должного результата.
            Поэтому теперь используется update с принудительной моментальной
            перерисовкой и пересчетом размера элемента. */
         el.update(MEASURE_DEEP | REDRAW_NOW);

SciterUpdateElement(el, TRUE), насколько я понимаю, не будет ничем отличаться от el.update(true) (если в реализации, конечно, ничего нового не появилось) — для каких флагов тогда имеет смысл дергать напрямую SciterUpdateWindow(), чтобы сохранить поведение? Для всех кроме REDRAW_NOW?