Комментарии 17
При добавление лэйблов массивом, при обработке нажатия на один из них ставиться значение глубины последнего
Ну и лэйбл очень маленький, и когда нажимаешь на ячейку "таблицы" там где нет текста обработчик не срабатывает
Наверное вы не поняли исходный вопрос. Событие Click возникает когда кликнули мышкой по Label-у. А это означает что курсор мышки находится внутри Label-а. Зачем ещё делать дополнительную проверку положения курсора?
Нажатие иногда происходит мимо лэйбла, и этот код вставлен и туда, чтобы определить его. Ну и конечно, его можно убрать с обработчика лэйбла. Спасибо))
Я думаю этот процесс можно было бы упростить. Вам не обязательно ставить клик на label, если важно именно отследить к какому label был ближе клик. Есть два способа — под label ставим глобальную panel, и ставим клик на неё, а после клика по координатам ищем самый близкий label. Если их генерация была в массиве и она имеет какой-то порядок, то искать можно не по всем, а только по области; способ два под каждый label ставим panel, так что бы он был прозрачен, т.е. виден он не будет и ставим на каждый из них один обработчик клик, в таком случае искать не придется, главное ставить их так, чтобы они были друг к другу вплотную. Нечто подобное применяется и в 2d-3d играх, т.к. отслеживать сложные формы дорого, поэтому простые контейнеры используются чаще всего.
rus-fishsoft.ru
Простите за банальный вопрос но почему Windows forms? Зачем над собой издеваться? Почему тот же unity не взяли?
Ну дело ваше. Главное чтобы было интересно, горящие глаза это ключевой фактор развития джуниора.
Но вы в самом начале пути, вам бы набрать опыта именно в программировании, архитектура, общие практики, мышление. Все это не особо зависит от инструмента. Специфика типа фишек winforms после этого набирается быстро. А вот если вы используете неудобные для задачи среды и инструменты вы становитесь ограничены в возможностях, и вынуждены обвешивать все это костылями или велосипедами, теряя время и фокус. Возможно я не прав, так как десктоп под винду совсем не моя область, и они в целом подходят под ваши задачи. Но если вы будете замечать что слишком много времени тратите чтобы подогнать неподходящий инструмент под задачу, что вместо удобной вам архитеруры и приёмов вы вынуждены придумывать костыли чтобы обойти недостатки инструмента — я бы советовал подумать над тем чтобы сменить инструмент. Это то что программисты делают, подбирают инструмент под задачу и используют его, а не наоборот. Благо счас достаточно инструментов чтобы извращаттся только в очень специфичных случаях и только если есть понимание что другие пути ещё хуже.
Ну и я бы не сказал что юнити прям отдельная область. Да есть специфика, да потребуется разобраться, но это всего лишь инструмент. Главное в нем все тот же код, на все том же с#, а все эти настройки, шаблоны и прочее упрощают жизнь позволяя не отвлекаться от бизнес логики. Я слышал что его счас даже в универах используют, для обучения. Этакая альтернатива делфи или js. Ну или чистому Net. В конце концов он создан для разработки игр, то есть оптимизирован под это.
Вы правы. Но концепция юнити такова, что код написанный там, не является ООП. А одна из целей проекта, это конечно научиться сопровождать большой проект, чтобы подтянуть ООП, всё таки гитхаб показывает в нем 50000 строк со всеми файлами, сгенерированными студией. Инструментарий буду изучать, всё новый и новый. Спасибо.
А зачем вам распознавание лиц?
Игра на WinForms + C# в 16 лет (2 часть)