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

DS>Как мне на "my_div" повесить обработчик событий onClick?

Все DOM событиия всплывают по цепочке контейнеров к окну поэтому если у тебя окно отнаследовано от sciter::event_handler то все DOM events туда приходят.
Поэтому ты можешь написать нечто типа:

bool my_window::on_event(HELEMENT he, HELEMENT target, BEHAVIOR_EVENTS type, UINT_PTR reason) {
  if( type == BUTTON_CLICK && dom::element(target).test("#table > .my_div") )
    on_my_div_clicked();
}

Если у тебя таких обработчиков много то имеет смысл нарисовать вокруг on_event что-то типа DOM_EVENT_MAP :

BEGIN_DOM_EVENT_MAP
  ON_BUTTON_CLICK( "#table > .my_div" , on_my_div_clicked )
  ...
END_DOM_EVENT_MAP

Да, и для того чтобы элемент генерировал BUTTON_CLICKs нужно в CSS написать

#table > .my_div { behavior:button; } // focusable
#table > .my_div { behavior:clickable; } // non-focusable

Но вообще-то ведущие собаководы рекомендуют более высокоуровневый UI/backend обмен, т.е. event handlers находятся и обрабатываются в скрипте
и вызывают native functions по результатам обработки:

include "decorators.tis"

@click @on "#table > .my_div" 
  function(evt) {  
    if( isValidSomehow(evt.target) ) 
      view.backendDoSomething(); 
  }

Смысл такой организации в том что дизайнер может поменять markup поэтому вшивать в native код селекторы можно лишь в том случае если ты сам и дизайнер и программер.
Со скриптом DOM structure refactoring проще.