Используете уникальные идентификаторы для объектов?
В твоем примере (и в 95-98% реального использования) сравнивать нужно именно состояние. А значит и сравнивать нужно через Equals.
Мне тогда нужно было именно ссылки сравнить...Очевидно, что нет :) Во всяком случае, твоя коллекция ничего не знает о том, что объекты нельзя пересоздавать :)
Когда делаешь модели и представления, то в основе разных представлений может быть одна модель. Тогда сравнение по значениям полей покажет равенство. А мне нужно было понять, что это именно разные представления, хоть и с одинаковыми моделями.
Коллекция действительно не заботится, чтобы представления имели в основе лишь уникальные модели. Это не её задача. Тем более, что иногда надо позволять иметь дубли. Поэтому и потребовалось различать представления с одинаковыми моделями. Тут сравнение по ссылке вполне подойдёт - уникальные идентификаторы городить не надо. Я их приписал представлениям для тестовых целей, чтобы перепроверить.
Here's a clean approach
Оптимистично. Особенно про "clean".
This approach will prevent the single-click handler from triggering when...
Впринципе, "when" можно заменить на "at all".
Этот говнокод, конечно, работать не будет, но с синтаксисом он неплохо справился.
Кстати, когда делаешь на одном и том же элементе обработчики на одно нажатие и на удержание, то тоже немало попотеть приходится, если не знать, как. Обычно события удержания нету, и надо его самому эмулировать. При этом надо сделать, чтобы оно не помешало событию нажатия. Тут надо тогда заменить одно нажатие на клик - т.е. нажатие и отжатие на одном и том же элементе. А ужержание, если такого обработчика нет изначально, эмулируется подпиской сразу на три события: нажатия, отжатия и покидания элемента (если такое событие в вашем фреймворке есть). Далее после нажатия притормаживаем поток параллельно выполняемой таской (Task.Delay или что там у вас для этого), в которую передаём токен отмены. Если таска задержки закончилась, то выполняем код для логики удержания нажатия контрола. В обработчиках же отжатия и покидания элемента отменяем таску задержки - логично, т.к. если слишком рано отжали или при нажатии сдвинули указатель или палец за пределы контрола, то удержания не произошло.
Проверил на своём проекте - отлично работает. Если зажал контрол, то события клика не происходит, а происходит событие удержания. А если быстро нажал и отжал - то удержания нет, а есть просто клик.
Использую это удержание для вызова подсказки по элементу там, где нельзя задержать указатель поверх элемента - для тачевых интерфейсов например.
Тогда сравнение по значениям полей покажет равенство. А мне нужно было понять, что это именно разные представления, хоть и с одинаковыми моделями.
В сухом остатке мы имеем твою ошибку :) В любом случае.
Т.е. либо ты выбрал неправильный контейнер. Либо ты неправильно сравниваешь :)
Вопрос в том, чему ты на этой ошибке научишься. Если запендюришь какой-то левый id, то значит ничему ты на этой ошибке не научился :) Вот собственно и все 
Так я и создал тему, когда у меня такая ошибка вылезла. Когда всё хорошо, я чилю на сёрфинге и сюда не захожу. )))
Чему тут учиться? Я уже через время всё забуду, что тут говорили. Когда снова возникнет такая проблема, я скорее всего снова буду искать, как лучше различать объекты. Для быстрого теста такой проблемы как у меня "какой-то левый впендюренный айди" вполне подходит. Для более сложной ситуации наверное нет.
Этот говнокод, конечно, работать не будет
То есть вы тоже считаете, что должен выдаваться сразу 100% рабочий результат?
Сделать код рабочим, еще одно предложение написать 
Но идея то останется всё та же: JS, timer и две функции.
Если у вас другая идея, можно также попросить изменить.
И для проверки идеи очень неплохо. Не нравится - проси другую.
При 15-20 млн сгенерированных строк - хорошо если получится поделить на блоки...О чём-то речь мы ведем? Какие миллионы?
Согласен - проблема раздута. Уже выяснили, что ИИ копирует чужой уже написанный код и пытается по методу калейдоскопа смиксовать из него что-то удобоваримое. Маленькие скрипты и небольшие группы классов по известным темам, которые написаны во многих тысячах вариантов, у ИИ зоходят неплохо. Проектов на миллионы строк было куда меньше для обучения, если вообще были. Поэтому ничего подобного таким проектам ИИ выдавать не сможет. А в скорости и вообще придут к выводу, что это просто ещё одна поисковая и справочная система. При этом могущая в любой момент выдать ложный результат. Поэтому проверке должно подвергаться, по-хорошему, всё, что она выдаёт.
назад
список