iarspider, мне кажется, что под

Andrey понимает применение альтернативного решения (ага, и пишит гораздо заумнее меня)

все правильно! и эту схему можно вставить в примеры wiki по StringTable или в замечании приписать и показать схему.

так что думаю ненадо....

nesco, хрновый значит из меня телепат

и как раньше работал именно onClick ? Вроде KOL тот-же. Значит виноват не KOL..., а применивший _OnSelState. именно не onClick
Правильно выбором не считается, а считается кликом на строке.
А совет по применению таймера здорово смахивает на затычку.
Andrey, не переименовывать , а вернуть старый onClick и ... если очень хочется, то добавить новую точку onSelect.

События onMouse работают в основной очереди и все команды контролу применены будут только по окончанию этой самой очереди. Но не реализовано на уровне KOL-a отработка отложенных событий. А таймер, в данном случае, и есть затычка, исполняющая роль отложенного события

Его закрыли, кто, спроси Автора этого закрытия, значит, на то были какие-то причины. Я не собираюсь ничего в этой области переделывать. Пусть Автор и переделывает, если посчитает нужным, я не вижу в этом никакой надобности

Я так и сказал

------------ Дoбавленo в 00.47:
А теперь смотрим KOL и делаем выводы


Класса Listview в нем нет. Для него есть


и на этом закончим прения по данном вопросу

nesco, а кто Автор этого закрытия ?

ListBox тоже в списке нет, а работает - кликай по одной строке сколько хочешь.
И по хорошему _OnSelState должно происходить после onClick.

И к чему это

Это - что ?

Исправления Galkov-a
------------ Дoбавленo в 01.25:

И давай оставим это на усмотрение Автора.

А ты не задавался вопросом, что onClick, это обычный onMouseDown, только вместо кода клавиши выдает строку таблицы

я не про исправления Galkov-а.
Я про примечания из которых видно кто внёс изменение.
Просто, зная что там участвует Galkov, мне легче было искать эти примечания.
------------ Дoбавленo в 01.33:
мне нужна строка или индекс строки по которой я кликнул, а не танцы с бубном вокруг кода клавиши мыши.

Интересное получилось обсуждение, мне очень понравилось. Понравилось то, что очевидный "непорядок" в поведении одного из самых ходовых и популярных элементов среды - StringTable (со всеми его разновидностями) - многим как знаком, так и активно их не устраивает.
Я очень благодарен sla8a и nesco за подсказки по простым решениям моей проблемы.
Но еще больше я благодарен всем, кто заявил, что подобные "проколы" в поведении элементов совсем не украшают среду проектирования HiAsm - хотя и устраняются несложными "затычками" (классный термин и прямо в масть!).

Хочу также обратить внимание вот на какой аспект. Я знаком с HiAsm не первый год и периодически работаю с этим замечательным инструментом. Образование и многодесятилетняя практика общения как с аналоговыми, так и с цифровыми электронными схемами обеспечили мне весьма комфортную адаптацию к терминам и понятиям этой программы.

При этом, встретившись с "непонятками" в StringTable, я отнюдь не сразу же бросился за помощью на форум программы - прежде чем убедился, что дело здесь не в моих заморочках. Признаюсь: меня просто ошарашила та скорость, с которой была предложена помощь на форуме!
При этом мне становится просто не по себе при мысли о том, сколько же времени, а также "крови, пота и слез" будут стоить "нормальным" пользователям как засвеченная здесь "некорректность" с элементом StringTable, так и другие подобные "шероховатости" - многие из которых, как я понял, уже знакомы участникам этого обсуждения.

М-да, ребята, грустно становится. Вы же практически все - ВЕТЕРАНЫ этого форума и ГУРУ этой программы. Вы отлично ориентируетесь во всех аспектах работы с HiAsm, включая те самые ЗАТЫЧКИ - о знании которых Вы объявляете и в ассортименте предлагаете здесь на форуме (еще раз большое спасибо - всё работает!). Все Ваши ники и аватарки мне знакомы не первый год, и мне, конечно же, льстит внимание столь квалифицированных специалистов.
Так вот: я убил на глюк с StringTable около трех часов (включая проверку в прежних версиях) - сколько же потратит НА ЭТОТ ЖЕ ГЛЮК КАЖДЫЙ ИЗ ПОЛЬЗОВАТЕЛЕЙ программы HiAsm - при условии, что они не знакомы с ассортиментом "затычек", предлагаемых на форуме?

Может, "в консерватории" что-нибудь подправить: присовокупить "затычки" к дистрибутиву, что ли? Либо напоминалки-извещалки про эти "затычки" прямо к элементам приклеивать (с адресами "затычек" на сайте)? Я думаю, что даже подобные "начальные" и "примитивные" способы выхода из сегодняшней ситуации способны спасти кучу времени и нервов пользователям этой славной программы.

Может быть, признаваться в дистрибутиве о наличии ИЗВЕСТНЫХ И НЕРЕШЕННЫХ проблем не совсем обычно и привычно, но при этом - честно и абсолютно в интересах заботы как о пользователе, так и об эффективности работы с программой. И уверяю вас: соображения эти отнюдь не малозначимы для КОНЕЧНОГО ПОЛЬЗОВАТЕЛЯ!

Не раз здесь прозвучало: "никто ничего исправлять не будет...". Простой вопрос: а для кого создана и уже много лет совершенствуется и развивается среда проектирования HiAsm? Я всегда считал, что главный её адресат, а также ключ к её успеху - именно конечный пользователь. И сейчас - НАДЕЮСЬ, ОЧЕНЬ НАДЕЮСЬ - что все авторы и "главные специалисты" этой программы смогут найти решение, достойное их опыта и традиций HiAsm.

На базе этого несчастного StringTabl-a, в последствии, были созданы такие монстры, как StringTableMT и MTStrTbl. И потому я этот класс излазил вдоль и поперек, и знаю большинство ее глюков. А все начиналось с малого -- мне катастрофично понадобился цвет и иконки в этой таблице. Увы, как это сделать мне никто не подсказал, все пришлось делать самому, перелопачиваю кучу литературы и форумов. И вот поэтому я, практически всегда, отвечаю на все вопросы, связанные с этой таблицей и ее следующими поколениями, мне не хочется, чтобы народ тратил попусту кучу времени на поиск решения по борьбе с глюками. К сожалению я не потому не могу исправить ошибку, что не знаю как, а потому, что одним их основных аспектов нашей разработки, является обеспечение совместимости. Да, это не совсем корректно, но это так. И вот почему "никто ничего исправлять не будет...". Я сделаю хорошо одному, а другой убъет, затем, на поиск несоответствия имени точки пол дня, роясь в куче мультиков и связей, представь каково ему будет, и будешь виноват уже не ты, а я.
У нас уже два года лежит переделанный KOL, но он не попадает в новые пакеты, а почему, а потому, что он не правился самим автором KOL-a (Кладовым) и нарушает дальнейшую совместимость. Возможно, я в чем-то и не прав, но я озвучиваю позицию Автора HiAsm-a и не могу делать ничего поперек его решения и не советуясюь с ним

А сложно будет сделать перед открытием файла поиск всех элементов и пересоединения измененной точки на новую и вывести соответсвующее сообщение.

по хорошему надо бы обьединить Баг трекер и хелп на элементы (wiki по элементам бы ещё вызывались по F1...) - починил баг и сразу исправил хелп на точку, в котором было написано "событие происходит ... , внимание - замечена нерешённая проблема (см.справку F1)" или что-то вроде этого..

А он и вызывается, только общий, а там спокойно можно найти нужный элемент. Не совсем удобно, но можно