Как стать автором
Обновить

Комментарии 17

Я может чего не понимаю (очень давно использовал C# и WinForms), но зачем в обработчике евента Click для Label проверять, что координаты курсора находятся внутри этого самого Label? Неужели есть варианты, когда можно кликнуть мышкой куда угодно на экране, а событие Click сработает для рандомного Label-а?
Нажатие по Label'у срабатывает плохо, поэтому мы обрабатываем клик по нему как клик по прямоугольнику.
Хм, можете немного расшифровать? Что значит «плохо срабатывает»? Не очень понятно что вы пытаетесь «починить» в плохо срабатывающем нажатии с помощью обработчика события, которое возникает при этом самом нажатии?

При добавление лэйблов массивом, при обработке нажатия на один из них ставиться значение глубины последнего

Ну и лэйбл очень маленький, и когда нажимаешь на ячейку "таблицы" там где нет текста обработчик не срабатывает

Но у вас ведь обработчик Click стоит именно на Label. И если он «не срабатывает» при клике мимо текста, то значит у вас и сейчас всё это не работает.

Наверное вы не поняли исходный вопрос. Событие Click возникает когда кликнули мышкой по Label-у. А это означает что курсор мышки находится внутри Label-а. Зачем ещё делать дополнительную проверку положения курсора?

Нажатие иногда происходит мимо лэйбла, и этот код вставлен и туда, чтобы определить его. Ну и конечно, его можно убрать с обработчика лэйбла. Спасибо))

Я думаю этот процесс можно было бы упростить. Вам не обязательно ставить клик на label, если важно именно отследить к какому label был ближе клик. Есть два способа — под label ставим глобальную panel, и ставим клик на неё, а после клика по координатам ищем самый близкий label. Если их генерация была в массиве и она имеет какой-то порядок, то искать можно не по всем, а только по области; способ два под каждый label ставим panel, так что бы он был прозрачен, т.е. виден он не будет и ставим на каждый из них один обработчик клик, в таком случае искать не придется, главное ставить их так, чтобы они были друг к другу вплотную. Нечто подобное применяется и в 2d-3d играх, т.к. отслеживать сложные формы дорого, поэтому простые контейнеры используются чаще всего.

Сейчас применяется первый способ, только обрабатывается клик по форме(а не панели), и затем ищем самый близкий Label(это возможно, так как сами Labelы в игре не показываются). А вот второй способ заставляет меня сомневаться в производительности. Даже при размерах поля 20x15 мы получаем 300 панелей.
А в чем смысл ковыряния автора в коде игры?.. Это игра Русская Рыбалка ранних офлайновых версий. Поначалу веселенькая, но потом довольно однообразная и нудная. Ей сто лет в обед. Ныне она благополучно переместилась в сеть, где люди за денежку могут купить себе эксклюзивные снасти, путевки в разные уголки виртуального мира игры с целью порыбачить, посмотреть успехи других игроков, продать виртуальный улов на аукционе и пр. Все уже есть и прекрасно работает. Что автор собирается преобразовывать, я не понимаю.
rus-fishsoft.ru

Простите за банальный вопрос но почему Windows forms? Зачем над собой издеваться? Почему тот же unity не взяли?

Просто мне интересно научиться применять различные фишки WinForms, чтобы делать красивый и удобный интерфейс, ну и возможно, пересесть в будущем на WPF, а Unity это всё таки целая область. Также, оригинал игры написан с использованием форм.

Ну дело ваше. Главное чтобы было интересно, горящие глаза это ключевой фактор развития джуниора.
Но вы в самом начале пути, вам бы набрать опыта именно в программировании, архитектура, общие практики, мышление. Все это не особо зависит от инструмента. Специфика типа фишек winforms после этого набирается быстро. А вот если вы используете неудобные для задачи среды и инструменты вы становитесь ограничены в возможностях, и вынуждены обвешивать все это костылями или велосипедами, теряя время и фокус. Возможно я не прав, так как десктоп под винду совсем не моя область, и они в целом подходят под ваши задачи. Но если вы будете замечать что слишком много времени тратите чтобы подогнать неподходящий инструмент под задачу, что вместо удобной вам архитеруры и приёмов вы вынуждены придумывать костыли чтобы обойти недостатки инструмента — я бы советовал подумать над тем чтобы сменить инструмент. Это то что программисты делают, подбирают инструмент под задачу и используют его, а не наоборот. Благо счас достаточно инструментов чтобы извращаттся только в очень специфичных случаях и только если есть понимание что другие пути ещё хуже.


Ну и я бы не сказал что юнити прям отдельная область. Да есть специфика, да потребуется разобраться, но это всего лишь инструмент. Главное в нем все тот же код, на все том же с#, а все эти настройки, шаблоны и прочее упрощают жизнь позволяя не отвлекаться от бизнес логики. Я слышал что его счас даже в универах используют, для обучения. Этакая альтернатива делфи или js. Ну или чистому Net. В конце концов он создан для разработки игр, то есть оптимизирован под это.

Вы правы. Но концепция юнити такова, что код написанный там, не является ООП. А одна из целей проекта, это конечно научиться сопровождать большой проект, чтобы подтянуть ООП, всё таки гитхаб показывает в нем 50000 строк со всеми файлами, сгенерированными студией. Инструментарий буду изучать, всё новый и новый. Спасибо.

А зачем вам распознавание лиц?

Распознавание лиц требует пытливый ум))

Наверное потому, что изначально это игра была спроектирована в Windows forms, еще в далеком 2008-10 году. И как я вижу, автор даже визуальный интерфейс и картинки не поменял, а писал он вроде, что разрабатывал ее сам.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории