Леонид, в публикаторе давно лежит схема, где всё это давно реализовано на отдельных элементах вокруг ChangeMon. Речь не об этом. У нас уже есть ChangeMon, в нём уже есть необходимая логика, осталось добавить одну точку и несколько строчек для полноценного функционала. А пока там ветка неизменности данных ведёт в тупик. Раз уж сделан элемент, так легко заменяемый всего двумя другими, он должен хотя бы функционалом не уступать этим двум элементам (в идеале - вообще превосходить, чтобы полностью оправдывать своё существование).

мои соболезнования.
Леонид, а выложить любой файл на сторонний файлообменник не пробовали ?
------------ Дoбавленo в 16.41:
1nd1g0, как думаешь в том, что выложил 10755, нижняя точка нужна ?

Надо подумать, делал-то кто-то со своими мыслями. ИМХО, не такая полезная, как точки событий, реагирующих на начало иили прекращение изменения данных, но применение можно найти. Первое, что приходит в голову - если нескольким разным потокам нужно одновременно среагировать на изменения данных где-то (например, приостановить деятельность, пока идёт получение данных со стороны). Первый проверяет данные, остальные ждут, когда флаг снимется. Во-первых, быстрее, чем много сравнений каждым потоком; во-вторых, не придётся хранить множество копий данных для сравнения; наконец, снижается риск, что проверки разными процессами дадут разные результаты, и кто-то из них продолжить работать. Да и одновременный доступ к данным при сравнении разными потоками может быть чреват подводными камнями. Доступ к флагу на чтение выглядит менее опасным.

В общем, выигрыш в производительности и памяти при правильном построении схемы точка, в принципе, может дать. Считывать флаг всё-таки быстрее, чем сравнивать, и уж тем более - постоянно перемещать данные.

Лично мне показалась полезной точка события неизменности данных, вдобавок её настолько просто реализовать, что на ней я и акцентирую внимание, остальное исключительно на усмотрение властьимущих.

Я так понимаю, что это в мою сторону закос, не прокатит. Вот придет Asassin, он все расставит на свои места. Nic, кстати, тоже имеет доступ. Пусть тоже принимают участие, че все ждут от меня каких-то кардинальных решений

nesco, а я ждал твоего мнения об изменениях в кодах компонента, а ты опять ищешь врагов - кто в какую сторону закосил.

Вроде не предлагалось ничего кардинального, лишь после 41-й строчки в hiChangeMon.pas вставить ещё три (которые при желании упаковываются вообще в одну)
Одну - в декларации (строка 14 hiChangeMon.pas)
и одну - в ini

Да ничего я не ищу, больше мне делать нечего, я просто хочу, чтобы и другие поучаствовали в решении общих вопросов, а то все по кустам попрятались
------------ Дoбавленo в 20.10:

Я только к концу обсуждения понял чего надо-то. Это может добавить кто угодно, особых претензий я иметь не буду, если уж совсем не вмоготу без этой точки. У меня, к примеру, никогда не попадался случай, когда она мне была нужна вообще

У меня тоже.

Остановка мыши и анализ, что же под ней

nesco, ты её (точку) не брал в расчёт т.к. её не было. А теперь можно будет строить логику программ уже рассчитывая на неё. Идея плавала на поверхности давно, окончательно меня убедил miver с его примером цикла на основе ChangeMon (сейчас как раз в топе по рейтингу). В его схеме было простительно иметь тупиковый выход из цикла (вся схема и была этим циклом, цикл вызывался лишь однажды и данные со временем гарантированно переставали меняться). А вот при применении его и подобных ему идей в более сложных разработках... Вот тогда-то я явственно понял, что не так логически в этом несложном элементе. Тупиковая ветвь, если данные менялись - мы это знаем, а информацией об обратном расточительно пренебрегаем.

Ну и пресловутая реакция на началоконец изменений данных, про которую мы выше говорили - тоже не редко нужная вещь. С такой точкой реализация упрощается. До этого мы, например, не могли легко узнать, что срабатыванию onData в ChangeMon предшествовал долгий период несрабатывания. А на прекращение срабатывания так вообще очень трудно было среагировать. Всё это ограничивало использование столь потенциально полезного элемента, пока что ставшего причудливой экзотикой (раньше его мало кто брал в расчёт продумывая алгоритм схемы - сужу по наблюдениям).

Как средство для подглядывания (Для тестирования необходимо установить компонент от 10755)
code_24821.txt

foksov, если им пользоваться, то лучше его слегка оптимизировать, в компоненте от 10755 лишняя 49-я строчка
присвоение заведомо совпадающих друг с другом данных. И назвать точки более логично (например, как в моём варианте )) )

onChange и onStopChange

Tad, тогда придётся как отдельный элемент оформлять)

1nd1g0, так ему и добавить Ex, а старый на пенсию и в дом престарелых