Вы видите копию треда, сохраненную 29 ноября 2022 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
1. Ресурсы:
— https://dotnet.microsoft.com/learn
— https://ru.stackoverflow.com/a/416585/422180
— https://metanit.com
— https://professorweb.ru
2. С# для веб
— https://docs.microsoft.com/ru-ru/aspnet/core
3. C# для десктопа
— WPF ( https://docs.microsoft.com/ru-ru/dotnet/desktop/wpf )
— WinForms ( https://docs.microsoft.com/ru-ru/dotnet/desktop )
4. С# для игр
— Unity-тред в /gd/, а так же учебники: https://ru.stackoverflow.com/a/609901/422180
5. С# для мобильной разработки
— https://docs.microsoft.com/ru-ru/dotnet/maui
6. Годные ютуб-каналы
— https://www.youtube.com/c/CODEBLOG
— https://www.youtube.com/c/AndreyShyrokoriadov
— https://www.youtube.com/c/DevJungles
— https://www.youtube.com/user/Shmachilin
Шапка: https://pastebin.com/HT7Hi6FD
Прошлый тред: >>2445746 (OP)
— Для Windows Visual Studio ( https://visualstudio.microsoft.com/ru/downloads ). Также есть версия для macOS.
Кроссплатформенный IDE Rider ( https://www.jetbrains.com/rider ).
Если в C# хочется, но пк уж слишком хуёвый: https://docs.microsoft.com/en-us/dotnet/core/tutorials/with-visual-studio-code
8. Что нужно знать, чтобы взяли работать?
— Общие навыки — TPL, Linq, DI, интеграционные тесты. Преимущество перед такими же вкатунами даст парочка интересных пет-проектов где вы делаете всё максимально правильно и точно следуя архитектуре.
— Архитектура — DDD, микросервисная архитектура. Так же необходимо ознакомиться с паттернами проектирования. Обязательны к изучению: MVVM, MVC.
— Базы данных — PostgreSQL/MSSQL + Mongo/Redis. Из ORM: EFCore обычно достаточно, но есть более быстрый, но менее удобный Dapper. Тратить время на ADO.NET не стоит.
— Алгоритмы — сортировка, поиск, оценка сложности алгоритмов, рекурсия, алгоритмы на строках.
— Структуры данных — связанные списки, деревья (бинарные, красно-чёрные), хеш-таблицы, графы.
— Системы контроля версий — обычно гита достаточно.
> ui на авалонии(c#) какие есть тулкиты под неe
Она сама тулкит. Тебе нужен тулкит под тулкит? Нигер штоле?
>>2484363 →
> qt платный
Da.
> Gtk всратый
Ты всратый.
Просмотрел ссылки. Там темы для авалонии. И что? Что ты этим хотел сказать? Что анон перепутал тулкит и тему в своём посте? Или что?
Как же все таки уебищен современный UI дизайн. Безотносительно к авалонии, он везде говно.
Самый красивый UI - дефолтный с дефолтными стилями. Он всем привычен, пользователи никогда не скажут, что им не нравится цвет кнопки, им тупо похуй.
Вообще, странная тенденция со стилями этими. Лет 10 назад все плевались от кроссплатформенных тулкитов с собственными стилями, не выглядящими нативно, а теперь все ругают нативные стили и пытаются высрать очередной уникальный дизайн, где невозможно отличить кнопку от надписи.
Что значит не выходит? Для теста зашёл на https://visualstudio.microsoft.com/ru/downloads/ , всё качается. Проверил в Firefox и IE.
Согласен.
Обнова скачалась и установилась. Возможно, через моего провайдера пока ещё работает.
Именно поэтому Eto.Forms лучше авалонии. Eto.Forms генерирует нативные окна под каждую платформу WPF, Winforms, GTK, MAC. В отличие от авалонии, которая создаёт графический контекст и рисует в нём свой вид согласно установленной внутри себя теме.
Кому нужны мокрописечные интерфейсы - тем в авалонию.
Кому нужен натив - добро пожаловать в Eto.Forms.
У меня только через впн вышло. Пробовал на разных компах с разными провайдерами. Хуйня, кстати, появилась буквально день назад.
Точно так же через некоторое время она пропадет и все станет нормально.
Это кстати не только особенность майковского сайта, но и многих других подобных крупных порталов. И нынешняя политическая ситуация тут не при чем. Скорее всего это косяки защиты от дудоса, которые на время блокируют целые регионы.
Вместо ctrl-s нажимать alt-tab? 🤣
Бекенд - это набор веб-приложений на .NET6. Фронт был на ангуляр+nginx.
Так вот. Внезапно возникла охуитительная идея - запихнуть все это дело в десктопное приложение. Не спрашивайте. Просто требования бизнеса такие возникли.
Хочется все это дело малой кровью провернуть.
Насколько норм решение - просто запихнуть фронтенд в какой-нибудь компонент QT для рендеринга веб-страничек и запускать локально тихонько приложухи. Ну или не Qt - копмонент, а электрон, допустим.
Кто-нибудь такой фигней маялся?
Или хуйня все это и придется по хардкору - разбирать микросервисы и делать отдельное полноценное приложение для десктопа?
Если у тебя Qt в роли браузера, Qt тебе нахуй не всрался. Бери электрон, тупо копируй файлы веб-приложения и пиши скрипт для запуска. Но надо ещё придумать, как будешь обновлять.
Если сделаю - то вы все и так узнаете, вот увидите. Конечно, скорее всего через три дня я заброшу эту идею.
>>485152
Я об этом думал, но суть в том, что я резко потеряю в скилле и уровнях абстракции для разработки фич, которые мне нужны будут. Даже если там будут просадки со стороны .NET, Вулкан умножит на ноль любые потери в самом рендеринге, а я не буду читать мануалы аля как в этом ебаном С++ создать легкую хуйню X, которую в шарпе я могу закрытым глазами запилить.
В целом, нужны простые вещи: нарисовать линии, добавить точку, в основном всё будет 2d + возможности 3d интерфейса (сами данные 2d, но юзер может покрутить карту, угол обзора).
На данный момент на Шарпе нету карты, способной в сложный рендеринг, которая не стоила бы больших денег. Я знаю только про движок от ESRI. Кто напишет про GMap, SharpMap, MapWinGIS, dotSpatial, EasyGIS - сразу нахуй, коль не соображаете ничяго.
да. и ты заслужил
Где?
Сколько ты это пилить будешь? 10 лет? Сможешь запилить хотя бы что-то отдаленно напоминающее josm? Он кстати вроде на обычной джаве со свингом написан, без погружения в опенгл, вулкан или директикс. Но и 1кк+ элементов он не вытягивает, да и зачем?
>>485197
>Даже если там будут просадки со стороны .NET, Вулкан умножит на ноль любые потери в самом рендеринге
Вулкан не панацея от всех проблем.
>А если не берут без знания ASP.NET?
Тада учиться по видосикам андрея широкорядова.
>Он так асмрно говорит, что не думается о программировании
Двачую, мне кажется он на каких-нибудь нереальных транквилизаторах сидит.
> Дак там примеры только для вижлы, а значит надо ставить винду
В любом случае надо. Один хуй на работе будет Visual Studio, разработка будет на винде, сервера на винде, и это при мнимой кроссплатформенности дотнета.
Если речь про веб на ASP .Net Core то не факт.
> на работе будет Visual Studio
Не факт, у нас, к примеру, дозволен онли Rider. За VS розгами секут.
> сервера на винде
На всех трёх работах, где веслал деплоили в кубер/openshift под линухом.
> разработка будет на винде
У нас в команде ограничений по ОС нет. Большая часть команды, да, юзает Винду, но есть и пара линуксоидов и даже один яблочник. Проблем с разработкой не испытывают.
В общем, в компаниях, у которых все на .net Core нет такой лютой привязки к винде. Во всех местах, где работал и про которые слышал, вообще предпочитают деплоить кормовые приложение в кубер под линухом. Вот если в компании есть что-то легасевое на .net framework, то да, может быть требование винды. Но я бы сейчас такие компании старался стороной обходить.
>Дак там примеры только для вижлы, а значит надо ставить винду
Пиздец, это же такая проблема в 2К22-м году-то.
Вводные данные: Npgsql+EFCore
Собственно. Программулина - шлюз. TCP-соединение открывается, клиент регистрируется по моему протоколу, я выделяю ему порт в системе, через который другие клиенты могут как-бы напрямую с ним общаться, сохраняю данные в базу. Механизм вроде как простой и все работает.
Но есть ньюанс. После примерно 30к таких висящих клиентов - начинается треш. Во-первых, PgSql - почему-то не закрывает соединения с базой. Хотя я их честно диспозю, и вообще они мне из DI'я приходят. Из-за этого, после определенного порога - новый клиент зарегистрироваться не может, получаю WSAENOBUFS (10055)
Есть и другие моменты, но вот этот пока что самый бесячий и я буквально не представляю, что мне тут делать, потому что блин, я все как в документации и рекомендациях написано делал.
На SO находил мнение, что для PGSql - нужно один коннект на все приложение делать, но из коробки так нельзя, потому нужно на PGSql+ типа переходить, там какая-то хуевина якобы есть, которая все твои контексты оборачивает во что-то и фактически у тебя один коннект, но в приложении - куча контекстов. Плотить - пока что, не хочется.
Может быть я что-то не так делаю? Кто-нибудь вообще, кроме меня сталкивался с вот такой вот фигней, что просто не удается открыть сокет, хотя чисто номинально - их свободных еще должно быть куча, всего-то половина от 65535 использована.
>Rider
Проблемы бы не было, если бы была коммьюнити версия хотя бы. Всякие решарперы не особо нужны, а в обучении может и вредны.
>Кто-нибудь вообще, кроме меня сталкивался с вот такой вот фигней, что просто не удается открыть сокет,
Вряд ли. Сейчас подавляющее большинство через REST работает. А там где есть перспектива пощупать сокеты, все сразу "нахуй-нахуй" и либо съебывают, либо REST продавливают.
это вообще из разных миров как бы
А по теме...это ж pg.
притащу цитату с перехода убера
"Помимо вышеперечисленных проблем, похоже, в Postgres не лучшим образом реализовано управление большим количеством соединений. Даже в тех случаях, когда памяти было более чем достаточно, мы испытывали серьезные проблемы с масштабированием Postgres после достижения порога в несколько сотен соединений. В документации (хотя мы не смогли найти этому точного объяснения) настоятельно рекомендуется использовать внешний пул (connection pooler) для обслуживания большого количества соединений. Для этих целей мы достаточно успешно применяли pgbouncer. Однако периодически проявлялась ошибка, которая приводила к открытию большего количества активных соединений (обычно в статусе “idle in transaction”), чем было нужно. В итоге это приводило к увеличению времени простоя."
На работе тебе оплатят лицуху, а дома можешь обучаться на торрент эдишон. И хуй тебе кто что сделоет.
Единственная трабла может быть если ты самозанятый фрилансер, тогда существует некоторая вероятность, что к тебе доебутся за лицензию. Но после day Z эта вероятность стала ещё более призрачной. Воруй! Качай! Еби гусей! Мы русские! Какой восторг!
Дак райдер ломануть нормально не могут. Там какой-то замороченный гайд на старую версию с запретом обновлений и блокировкой интернет-соединения.
Фото монитора, так как с пк двач не грузит.
глупости какие то. уже больше года есть норм средство для всех idea-based редакторов
Я вроде не спрашивал мнения о коде, я спрашивал, почему он работает неверно. Сам код я уже переписал (пик), но вопрос меня всё еще интересует.
Мне что, ручками цикл писать?
А что по твоему он должен был бы вернуть?
>Мне что, ручками цикл писать?
100% нужно
в принципе можно использовать Array.FindIndex, но не нужно.
Так то ты прав. должно быть bool Find(...out value)
>не спрашивал мнения о коде
А это никого не волнует. Опубликовал код - радуйся что обосрали. Вот ты даже код поправил.
А по теме - исчезает через секунду. Не верь глазам, добавь Stopwatch
Я только что проверял …нет, не скажу какой трекер, и там висит 2022 с патченым экзешником на раздаче и никто не жалуется.
хз же что это за InterfaceVisibility и что там в обработчике MouseLeave ибо не представлено
но в остальном пруфпик
>Сколько ты это пилить будешь? 10 лет? Сможешь запилить хотя бы что-то отдаленно напоминающее josm?
Не совсем. josm - это не движок, а полноценная ГИС. Я же собираюсь сделать только прослойку между graphics API и ГИС приложениями. Ну это всё фантазии пока конечно.
Но на Вулкане через .NET обёртку я уже смог прорендерить 1кк+ объектов через несколько пайпов с ФПС 60. Правда там shaders без обвеса, а они перфоманс просадить могут. Но если удасться изменить модели на более качественные и удержать ФПС - то я точно продолжу разработку, ибо самый топовый движок до сих пор юзаею OpenGL, а тут у меня готовый .NET компонент будет для десктопа.
В итоге разобрался сам, для изменения других свойств надо было создать отдельную функцию и передать её в PropertyMetadata
>Я же собираюсь сделать только прослойку между graphics API и ГИС приложениями
А в чем тогда смысл твоих начинаний? Любая макака может из джавы/шарпы/питона дергать opengl и вулкан, обертки уже есть. Или ты хочешь какую-то особую gis-либу запилить со всеми необходимыми компонентами для разработчиков гис софтин?
А почему бы не посмотреть в сторону js и вебассембли? Например те же народные карты яндекса вполне шустро работают. Ну или викимапия, там наверное совсем что-то древнее под капотом у них крутится, но работает быстро.
>народные карты яндекса вполне шустро работают
Ты пробовал в них сотни тысяч элементов с графикой прогружать?
>обертки уже есть
Нету FOSS GIS компонента для .NET, способного в высокую производительность. Бесплатно только старые GDI/GDI+ движки.
>>486947
>викимапия
Дебил, просто съеби. Почитай про deck.gl, QGIS, ArcGIS Pro, Carmenta Engine, а потом неси своё говно мамонта, которое на первом же слое обосрётся.
Заметил, что указание типа после имени переменной на самом деле удобнее:
int Count;
Count int; – это удобнее, потому что большую часть времени ебёшь мозг над названием переменной, и, если название придумал, то структуру данных подобрать – дело наживное
Радует, что шарпы двигаются в сторону минимализма, хоть и через сахар, но писать можно меньше.
Вам не кажется, что в последнее время маятник качнулся обратно, и паттерны ради паттернов и интерфейсы на ровном месте стали использовать реже? Например, ебучие IRepository или UnitOfWork, которые тупо обёртка над EF. Ладно бы хоть с бизнес-логикой, так ведь не всегда
Если посмотреть EShopOnContainers, который разбирают на msdn, то выглядит очень даже ничего
>Например, ебучие IRepository или UnitOfWork, которые тупо обёртка над EF.
Как быть суть как раз в создание отдельного слоя данных, не привязанного к ORM. То есть ты пишешь IRepository<Entity>.Save в контроллере, и при смене ORM или вообще на переходе на SQL raw тебе не надо лезть ВО все контроллеры и вручную переписывать методы.
А Unity of Work - это просто удобный способ контроля изменений, когда ты сохраняешь всё по факту.
А как учится по Метаниту? Читать по-порядку? А практика? Там нет ни одной задачи после теории.
каждому свое
я вот читаю по диагонали чтобы понять основные принципы
а потом активно читаю чужой код и тем самым эти принципы вижу на деле
Получится. Внимательнее перечитай документацию. dll-сборка и есть кроссплатформенная программа. Ты можешь запустить её командой наподобие dotnet <сборка>, которая на всех платформах есть. Если ты не собирал, разумеется под конкретную платформу, то сборка будет собрана в общем для всех платформ виде.
Скоро и дотнет отключат
> Почему студия не скачивается?
Потому что ты - коллективно виноватый террорист.
Извините, не удержался. Не баньте, плиз.
впн требуют наши сердца
Потому что петушарп. А ты что думал? Пока ты нравишься майкрософту, петушарп для тебя опенсорс. А как только не понравишься - сразу делается проприетарным и ты не сможешь им пользоваться. Так и произошло в твоем случае - майкрософту не понравилась вся Россия. Кстати, петушарп ещё и кроссплатформенный - пока ты пользуешься шиндовсом. Как только ты переходишь на линукс или боже упаси пук оес, сразу он становишься намертво залоченным на платформу. Вот так гении майнрософты, что такую крутую систему придумали! Слава шарпу!
>Потому что петушарп.
Явадебил, спок. Язык, компилятор и дотнет никак не связаны с вижаком, можно хоть в блокноте писать. Если действительно блокнут вижак полностью для русни - это печально, но не критично, есть VS Code
Анон у меня такая же идея есть, го вместе пилить? Только без детского 2d, сразу в 3d на эллипсоиде.
Орнул. Джаву оракл еще в марте блокнул для рабсиян, жри стороннее говно непригодное к проду от openjdk или других хозяев (amazon, red hat, microsoft jdk внезапно)
да вы замучили
вот поставлю райдер и проверю что там изменилось с прошлого раза
последний раз пробовал 2022 версию и все было ок
У меня работает, но уже не в первый раз вижу посты, что у кого-то перестало качаться.
https://youtu.be/BG4nnMR7uTs
Просто в яндексе открой и в контекстном меню вруби перевод. Это не реклама, это суровая реальность на личном опыте. Яндекс теперь не вредоносный рекламный браузер, ставящийся вместе с левыми прогами, теперь это полноценная замена гуглу с хромом.
Анонимус разрешает.
Проблема в непонимании основ. Новичок читает и не знает почему это пишется именно так, а не иначе. Соответственно, у него нет знаний, как доработать, если оно не работает.
>Соответственно, у него нет знаний, как доработать, если оно не работает.
А, ну точно. Я и забыл, что сейчас 2K22-й год на дворе. Интернета нормального нет, дополнительную информацию посмотреть негде. Да и компиляторы до сих пор дубовые, в сообщениях об ошибках никакой информации нет. А до изобретения онлайн переводчиков еще лет 10 наверное.
А если без сарказма.
Самые основы учатся по другим книжкам.
Основы ASP-а?
Ну запустил ты пример из книги - не запускается. Прочитал сообщение об ошибке. Не понял - загуглил, почитал сопутствующие материалы. Не получилось. Открыл английский вариант книги и посмотрел тот же пример - сравнили на разницу. Что непонятно - перевел (со словарем хотя бы).
За пару часов такой возни опыта и знаний наберешь больше, чем за несколько дней копирования работающих примеров из книжки.
Сделай экстеншен который будет заменять все Ё на Е, в строках и сравнивай сколько хочешь (по аналогии с ToUpper или ToLower).
К сожалению в CultureInfo "ru-RU" нет эквивалента для этих букв.
Ну тут проблема в том что я могу преобразовывать только искомую фразу иначе не спарсится, а в бд эти данные могут быть в какому угодно виде там могут быть как е так и ё и всё в кучу, и вот что делать в такой ситуации непонятно, я решил пикрил попробовать
Можешь попробовать в самой БД сконфигурировать, чтобы в запросах эти буквы считались эквивалентными.
Вот например для постгреса из доков:
https://www.postgresql.org/docs/current/unaccent.html
Я думаю меня нахуй пошлют с таким запросом слишком всеобъемлющее изменение будет по сути, но за инфу что так можно спасибо
Хоть сарказм, хоть не сарказм, а многими уже подтверждаются печальные наблюдения о том, что чем больше доступ к знаниям, тем больше людям на знания похуй. Кого ты собрался заставлять читать книжки? Клиповых зумеров?
>но за инфу что так можно спасибо
Есть еще такие приколы, что в БД (например MySQL) такое может быть по умолчанию включено.
Сейчас ещё ковид сильно ударил по мозгам и учиться в разы тяжелее. Зумерам как раз ещё не так сложно, а вот кому за 30, уже не так легко.
Эх, да. Бывает сяду с книжкой и уже на второй странице засыпаю. А с аудиокнижкой - на первой, под бубнёж.
>за 30, уже не так легко.
Забавно такие рассуждения слушать когда тебе уже за 40 и никаких проблем с освоением этой мути не ощущаешь.
Дело не в возрасте, а образе жизни. И да ковидом я тоже болел, чуть легкие не выплюнул.
Да у тебя ковид ударил по легким, а меня по мозгам
Допустим, но какое отношение это имеет к студии, которая без костылей должна устанавливаться через официальный сайт, через официальный инсталлятор? Я знаю, что нужен впн, но какое это отношение имеет к моей криворукости?
кто мы, дебич?
>но какое это отношение имеет к моей криворукости?
Такое, что это давно известная проблема решаемая за пару минут. И она никак не связана с блокировками ни с той ни с этой стороны.
Просто каждый такой долбоеб вместо того, чтобы просто погуглить и решить ее самостоятельно, тут же бежит во все профильные темы и начинает срать в духе "У-у-у, майкрософт заблокировала Россию, всему пизда".
Там вообще врап панели из коробки нету
В смысле учится писать? Установил, поставил нужные дополнения и пишешь. Нихуя учится не надо, если обладаешь знаниями выше дауна копирайтера
В смысле как ? Вася... Просто ставишь нужное расширение и всё. В расширение описаны минимальные команды как да и что. Любой пенёк разберётся
Насколько руки должны быть из жопы, чтобы с примитивным гитом всё угробить? В начале, правда, не стоит баловаться с ребейзами, но всё необходимое учится за вечер.
Да, тысячи статей с простыми и понятными рекомендациями, всё давно разжёвано и быстро изучается.
Такая рекомендация даётся только в мемасах уровня пикабу. Даже если настал совсем пиздец, на stackoverflow легко найти, как в пару команд всё починить.
спасибо
https://pastebin.com/0TTmUVP8
В этом стиле есть Grid, внутри которого три векторных контура Path. А еще есть стиль-наследник, смысл которого — менять данные этих патчей. Но как это сделать?
Я пытался по TargetName перезаписать, но мне дает отказ.
Ошибка: свойство TargetName не может быть задано для типа Style Setter.
Сделай кустомный контрол на основе шаблона, который наследуется от контент контрола, добавь в этот контрол 3 свойства BoundingPath, FillShapePath и StrokeShapePath, потом в шаблоне <Path x:Name="bounding" Data="{TemplateBinding BoundingPath}". Потом сможешь менять <Setter Property="BoundingPath" Value="M0 20,0 20,20 0,20" />
потом в шаблоне Path x:Name="bounding" Data="{TemplateBinding BoundingPath}"
Через стиль можно будет менять Property="BoundingPath" Value="M0 20,0 20,20 0,20"
Ну в коде просто три депенденси проперти добавишь и всё, всё остальное уже в темплейте
Возможностей нуль. Это я как десигнер говорю.
Сначала тоже плевался, а потом как понял.
А перешел буквально из-за одного недостатка — контроль прозрачности. На винформсах можно установить главному окну общий процент прозрачности, но нельзя сделать прозрачность по маске
<— типа как этот стикер.
У меня щас весь интерфейс векторный, и минимум растра. Можно применять матрицу трансформаций и делать масштабируемую и адаптивную годноту. Единственная беда — это попиксельная работа с растром, т.к. либа есть только на винформсах.
Ну да, я так и представил. Даже если бы и была возможность, то не хотел бы о ней знать т.к. там 100% была бы простыня из тэгов.
Че меня дико бесит, это отсутствие возможности написать так:
<Setter.Value.Viewbox.Grid>
...
</>
вместо
<Setter.Value>
<DataTemplate>
<Viewbox >
<Grid>
...
</Grid>
</Viewbox>
</DataTemplate>
</Setter.Value>
>>489151
Неееет, зачем я заговорил про простыню кода?
Короче, сделал я кастомный класс со свойствами, начал в стиле менять свойства. Приехали:
Error XDG0041 : The "Date" property is not a DependencyProperty. To be usable in tags, unattached properties must be visible on the target type with an accessible instance property "BorderBrushB". For joined properties, the declared type must provide the static methods "GetDate" and "SetDate".
ОшибкаXDG0041Свойство "BorderBrushB" не является свойством DependencyProperty. Для использования в разметке неприсоединенные свойства необходимо предоставить целевому типу с доступным свойством экземпляра "BorderBrushB". Для присоединенных свойств в объявляющем типе должны быть представлены статические методы "GetBorderBrushB" и "SetBorderBrushB".
Потому что сотрудничать с издательствами страны-террориста очень чревато последствиями
ну а куда хоть устроиться можно будет, просто такое ощущение что в фронтэнд и qa вообще не реально на джуна устроиться
>ну а куда хоть устроиться можно будет
Да хоть кассиром, твое дело щас максимально набираться знаний. Если ты в душе не красноглазик, то становись в очередь мечтающих об успешном успехе.
Ты еще первый курс не прошел, ахахаха!
Нахер ты кормишь политического шизоида? Они и так срут во всех тредах.
На мой взгляд причины три:
- появились интернеты
- появились переводчики
- появилась мнение, что погромист обязан знать инглиш
Если раньше узкоспециализированная литература была мало популярна, то сейчас наверно вообще не рентабельна.
На джуна +- везде не просто попасть, либо оверхайп js, python, либо меньше хайпа (c#, java, go) но порог вхождения повыше.
Если уже фронт знаешь, норм варианты:
1. Дожать фронт: норм выучить react, angular, vue. К ним TS, redux`ы эти, router`ы под фреймворк, найди roadmap`у просто.
Как по мне, лучше взять angular, там TS, не смешаный в кашу HTML и JS, state легче сделан и меньше магии.
А там уже можно и перекатиться на react/vue
2. Взять бек, можно шарпы. Нужные знания фронта у тебя есть.
Сначала сами шарпы: ulearn.me
Потом ASP.NET Core, делаешь проекты WebApi, на RazorPages.
Норм каналы Platinum DEV (плейлист WebApi .NET5), Sergei Calabonga (там и сам шарп, aspnet проекты, и околошарповые темы),
Потом уже: Роман Сакутин (не курсы, а критика кода), Nick Chapsas, RadioDotNet.
А так, тупа пиши код. На любом языке, в любом направлении, желательно часто. Главное чтобы нравилось.
Посмотри на Desktop, Web, игры, написание ботов, тестирование.
Тут проекты какие-то https://eax.me/programming-language-learning/
Главное не отвлекайся на бред типо: каждый прогер должен знать Linux, C\C++, на память все алгоритмы, паттерны, железо, память.
Тут либо сам потом дойдешь, либо и вовсе не нужно будет.
Почему тогда у него одних джавистов работает несколько тысяч? Найс из контекста вырезал
>Роман Сакутин
Фу, это вообще противный чел. Весь в наколках как тюремщик и ещё выделывается на пустом месте, что он дофига великий программист и создатель курсов, а все остальные тупые.
Я за два дня только 8 страниц смог прочитать на твоём этом инглише. И то это введение. А в книге как бы 1300 страниц.
> Ты сам когда-то был тупым нюфагом. Уже позабыл?
Когда я был ньюфагом меня обзывали тупым тогдашние олдфаги, которые когда-то были ньюфагами и их обзывали тупыми праолдфаги, которые...
Спасибо анон, я и сам смотреть начал в c#, но как то посмотрел что на нем пишут и вообще запутался там и игры и бек и еще лабудень какая то. Спасибо что каналы хорошие подсказал, а то обычно все что ютуб или гугл выдает это инфоцыган, которые учат хело ворлд печатать. Надесю справлюсь с обучением и смогу куда нибдуь на работу залететь.
Да, спасибо. Сегодня до шести утра сидел и практически методом тыка добрался. Щас ебался с переопределением дефолтных свойств.
Меня бесит какая-то неоднозначность.
Вот я регистрирую свойство зависимости для SolidColorBrush, и там PropertyMetadata можно не указывать (пикрил 1)
https://pastebin.com/2wfX6rh1
И у меня нормально отрабатывает свойство "MyBrush". Но в случае с Path (Geometry, не суть), оно не хочет срабатывать.
Мне приходится юзать PropertyMetadata с ссылкой на метод, который перезаписывает свойство (пикрил 2)
https://pastebin.com/NU1MnKE1
>Это вина говнокода
Да
>или в принципе шарп не может обеспечить должную скорость
Может, C# является тир-2 языком по скорости после C++ не знаю на счет Rust. C# в последние версии нереально бустят по скорости. Вот пример на скрине новый linq, как видишь скорость в сотни раз быстрее, а аллокаций памяти вообще нет, всё дело в программисте, а не в языке. Даже пайтон можно разогнать, где-то видос видел, добавляли jit
Кажется понял в чем причина, но не понял как это работает.
В свойствах срабатывает SetValue DependecyProperty, кисть действительно назначается. Я панели свойств элемента я вижу, что кисть изменилась.
Но весь остальной код, что находится внутри кавычек Set — игнорируется. Для выполнения дополнительной логики, нужно юзать PropertyMetadata.
Как это работает — хз.
>где-то видос видел
Я бы не стал доверять современным замерщикам скорости. Был же недавно скандал, когда ради гонки показателей получилось так, что сервер выдавал ответов больше, чем приходило запросов.
>с одними шарпами
Такие не нужны. У тебя 2 стула будучи на .NET:
1. .NET + html + css + js/ts
2. .NET + C/C++
Есть само собой. Но ты обязан быть фуллстеком чтобы релоцироваться, даже если будешь писать чисто бэкенд
Ожидаемо. Единственный знакомый работяга улетел в июне, но судя по линкеду ему пришлось свитчнуться на другой стек
А какая разница
Без материализующих шагов потребление памяти (а именно оверхед) хоть на 1 миллионе, хоть на бесконечности - одинаковое
>Был же недавно скандал, когда ради гонки показателей получилось так, что сервер выдавал ответов больше, чем приходило запросов.
что за скандал
Эталоном считается benchmarks game. Просто потому что он самый известный бенчмарк. компиляторов
А ты случайно не знаешь как снять регистрацию с депендеси проперти? Ну вот допустим у класса есть по-умолчанию свойство Background, а в моем элементе это сбивает с толку, мне нужно свойство Fill.
У нас нет заводов с 1992 года
Когда портируешь с питона или котлина прямо таки чувствуешь что тебя ограничивают.
Или вообще WTF
вот сейчас столкнулся что yield return не может быть в try/catch
ШТА? 22 год на дворе и не нашли время это пофиксить? Невозможно это сделать? А почему питон может?
Не пишите на выразительных языках, а то потом на шарпе будете страдать.
так они у тебя и есть - мои проблемы.
ты страдаешь от недостатка выразительности языка и вынужден городить многословные костыли зная о том, что бывает проще.
охренеть что когда я тебе намекнул на англ язику
ты до сих пор сидел и не понимал что сделать
Вот накидали в язык async/await
А async примитивы где? Где нормальный асинксемафор? где AsyncReaderWriterLock? и так далее.
1 сделали цикл статей на мсдн как можно сделать самому.
2 ну ладно есть либа AsyncEx, но
а) она сторонняя
б) автор себе на уме - например, в том же AsyncReaderWriterLock он убрал возможность апгрейда лока, мол НИНУЖНА
в) медленная так то
3 ага. есть Microsoft.VisualStudio.Threading - но опять же, это просто пакет в нугет и даже из названия следует, что они писали для личных нужд.
Далее....есть такая штука как контракт кода.
вот в котлине есть всякие reqiure/check на уровне основного синтаксиса. А в шарпе что? А в шарпе жопа
1 всякие Guard для проверки входных параметров - но по факту это велосипеды. Где стандартное решение?
2 Debug.Assert...но он кстати не кидает исключение сам по себе. Не знали? Вот и я офигел когда привык что в винформсах он мессаджбок выбросит, а в консольке (и даже в WPF, хотя типа должен) код просто пойдет дальше
3 Родили как то CodeContract. Идея правильная, даже во фреймворке много где юзали. Но в итоге решили - это вам не нужно и херакс
"Контракты кода не поддерживаются в .NET 5 + (включая версии .NET Core). Вместо этого рекомендуется использовать Ссылочные типы, допускающие значения NULL ."
Бл... Это же частный случай контракта. Это как говорить "вместо борща иди погрызи шкурку от картошки".
Ну они все равно внесли, но "мы не поддерживаем и не рекомендуем"
При этом сами такие без трусов и с крестиком - для себя запилили Microsoft.VisualStudio.Validation, который тот же контракт, только в профиль и "ну это мы для себя такие, а вам нирикаминдуем, вот".
>>489864
не нужно оно тебе. береги нервы
в
Вот накидали в язык async/await
А async примитивы где? Где нормальный асинксемафор? где AsyncReaderWriterLock? и так далее.
1 сделали цикл статей на мсдн как можно сделать самому.
2 ну ладно есть либа AsyncEx, но
а) она сторонняя
б) автор себе на уме - например, в том же AsyncReaderWriterLock он убрал возможность апгрейда лока, мол НИНУЖНА
в) медленная так то
3 ага. есть Microsoft.VisualStudio.Threading - но опять же, это просто пакет в нугет и даже из названия следует, что они писали для личных нужд.
Далее....есть такая штука как контракт кода.
вот в котлине есть всякие reqiure/check на уровне основного синтаксиса. А в шарпе что? А в шарпе жопа
1 всякие Guard для проверки входных параметров - но по факту это велосипеды. Где стандартное решение?
2 Debug.Assert...но он кстати не кидает исключение сам по себе. Не знали? Вот и я офигел когда привык что в винформсах он мессаджбок выбросит, а в консольке (и даже в WPF, хотя типа должен) код просто пойдет дальше
3 Родили как то CodeContract. Идея правильная, даже во фреймворке много где юзали. Но в итоге решили - это вам не нужно и херакс
"Контракты кода не поддерживаются в .NET 5 + (включая версии .NET Core). Вместо этого рекомендуется использовать Ссылочные типы, допускающие значения NULL ."
Бл... Это же частный случай контракта. Это как говорить "вместо борща иди погрызи шкурку от картошки".
Ну они все равно внесли, но "мы не поддерживаем и не рекомендуем"
При этом сами такие без трусов и с крестиком - для себя запилили Microsoft.VisualStudio.Validation, который тот же контракт, только в профиль и "ну это мы для себя такие, а вам нирикаминдуем, вот".
>>489864
не нужно оно тебе. береги нервы
в
The c# player's guide, который с 6 дотнетом
Вообще надо вернуть книги в шапку, в старых тредах были
да я свои школьные гощды на js быдлокодил, теперь хочется что то серьезное посмотреть, может потом и буду каким нибудь фулстеком работать, не знаю пока
Троеллсен, как раз недавно на русик перевели новую книгу для 5 нета.
Додич, иди нахуй.
Вся хуйня, что ты описал (пожалуй кроме ненужного AsyncReaderWriterLock) тебе жопу печет только потому, что ты додич.
Не думал, что я буду это говорить в контексте C# и .Net ибо их и так ругают за перегруженность, но есть хорошие либы, которые это все решают без лишних напрягов. И есть уже даже "стандартным решением".
То, чт оты боишься добакить пакет, который начниается не с "Microsoft" - твои анальные проблемы.
а ну обоснуй мне ненужность асинк примитивов
Ну или сам иди нахуй
Как можно обойтись без них? Разработчики визуал студии вот не обошлись например. Видать не понимают как ты. Так просвети
>но есть хорошие либы
они всегда есть. Однако почему то мелкософт решил выдать свой DI контейнер, а не использовать один из 100500 готовых. Причем любой другой лучше мелкософтовского, но есть нюанс)
> который начниается не с "Microsoft"
Вообще то пакеты начинаются как раз с мелкософт.
просто они написаны ДЛЯ СЕБЯ. - в частности там есть штуки которые нужны для разработки расширений к студии, а в валидации писало "тут проблема контракта обратитесь в мелкософт".
Поясню подробнее для додика
Я не говорю про специфические вещи типа DataFlow
Я говорю про БАЗОВЫЕ примитивы. Которые нужны буквально всем, кто не формошлеп и использует async.
Хотя те же Channel были отдельно, а теперь стали частью.
А примитивы где? - ищи среди велосипедов
> XAML islands was a technology preview and didn't support high-DPI, DPI changes, or accessibility in 1809. We rely on them heavily.
> 1903 added support for side-by-side WinRT component activation, something deep in the COM stack that lets us find our DLLs when they're right next to our EXE
>Да
А вот в DevExpress считают иначе. На пике их сравнение производительности нового Winui 3 и старого доброго wpf.
>а ну обоснуй мне ненужность асинк примитивов
А примитивы где? - ищи среди велосипедов
>СемафорСлим юзай и не выебуйся.
>Однако почему то мелкософт решил выдать свой DI контейнер, а не использовать один из 100500 готовых.
Ну так сиди и не бухти. Добавят - хорошо, нет - тоже хорошо. Пусть лучше корными вещами занимаются, а не очередной либой для гардов-хуярдов. Тут, на счвет гардов, конечно можно подискутировать на счет билд тайм валидации. Но это хуйня на самом деле.
>Вообще то пакеты начинаются как раз с мелкософт.
Ты хуйню какаую-то выбрал. Никто по-хорошему сейчас ни майкрософт асерты не юзает ни ту твою вторую дичь.
А я до сего момента считал WPF тормозным кошмаром (заслуженно). Лишнее подтверждение истины, что у дна не бывает дна, всегда есть куда падать.
>СемафорСлим юзай и не выебуйся.
интересно зачем существует ReaderWriterLock, если "все можно через семафор"? или все же не все....
Можешь не отвечать, я понял что примера замены я не увижу.Ну или ты создашь через семафор свой ReaderWriterLock - ну это и я умею, просто это ЛИСАПЕД
>Ну так сиди и не бухти
схера ли. имею полное право иметь свое мнение и критиковать что угодно. Как ты вот щас критикуешь мое право критиковать.
>Пусть лучше корными вещами занимаются
лол. примитивы синхронизации - куда уж корнее.
>Ты хуйню какаую-то выбрал
что было то и выбрал. выбор или лисапед или "от мелких"
как раз именно ИХ они и юзают. Именно их они и создали для того, чтобы юзать. Или визуал студию уже не мелкие разрабатывают?
Может ты его с GNU Pascal перепутал?
Free Pascal это диалект Object Pascal со своим компилятором. У него бекенд не GCC и не LLVM как я понимаю.
Тогда наделать экземпляров? Я просто снихуя решил, что они глаза мозолят и будет круче всё в одну строку написать
Это тест компиляторов (времени компиляции), а не работы собранного кода. Паскаль конечно наравне с си/крестами.
> Это тест компиляторов (времени компиляции)
Что за бред, тогда кресты были бы в самом конце.
Фиг знает, написано под спойлером. Я исходил из того, что если предположить что это тест программ, тогда получается гораздо больший бред. На графике все примерно одинаковые, наибольшая разница всего в 3 раза, хотя реальная в сотни раз.
При этом фоновая интеллектуальная служба BITS на 40% систему (и начинает грузить аж на старте системы).
после добавления ip в впн - да
>2 Debug.Assert...но он кстати не кидает исключение сам по себе. Не знали? Вот и я офигел когда привык что в винформсах он мессаджбок выбросит, а в консольке (и даже в WPF, хотя типа должен) код просто пойдет дальше
Надо подписаться на событие необрабатываемых исключений. Я к этому привык, когда делал плагин, иначе из-за исключения крашит программу-родителя.
Ты понял неправильно. Нет никаких исключений.
Если ты ожидаешь, что в этом месте выполнение остановится ибо полетит исключение, то тебя ждет сюрприз.
Debug.Assert просто срет в слушателей (а это по дефолту output) и всё - то есть эквивалентен Debug.WriteLine('Alarm')
И нужно добавлять Listener, который бросит исключение, тем самым реально прервав выполнение.
Лучше бы он делал это по дефолту (с возможностью отключения), а не приходилось делать доп шаги
А, я нафаня — этим не пользовался.
Я try cath юзаю и Debug.WriteLine
И вообще написал функцию записи всех логов в текстовый файл. Хз как сделать так, чтобы был доступен аутпут для проверки библиотек, а точнее чтобы сторонняя программа загружала мою библиотеку, которая бы срала в окно интерпретации студии.
Задача ассерта -проверить инвариант что все верно в данный момент и fail-fast с диким ором делать (по идее). В релизе будет вырезано чтобы не тормозить. А твой try..catch это ну "логгер ошибок" разве что.
>>490369
>Хотя чисто логически, ассерт не должен останавливать программу
чисто логически должен. assert проверяет корректность выполнения
и если проверка провалилась, то дальше выполнять нельзя
в других языках ведет себя ожидаемо - генерит исключения. И в реализации код контракта тоже исключения. И в валидации от мелких - тоже
для чисто вывода в аутпут и так есть Debug.WriteLine,
просто реализован он через механизм листенеров (нет это не есть плохо) и для винформс этот листенер устанавливается ,а для впф почему то нет (а должен)
для консоли разумеется не устанавливается
но лучше бы устанавливался всегда
Боюсь представить зачем он нужен, если ты не на галере. Возможно просто исследовал чужой элемент.
> Растёшь
Просто Хач в недавнем видосе на ютубе сказал, что риоднли - это хорошо, и надо везде делать ридонли.
...Или это был не Хач? А, точно, это Сакутин так сказал.
>assert проверяет корректность выполнения
и если проверка провалилась, то дальше выполнять нельзя
Кто сказал? А если это не критическая ошибка, а обычный ворнинг? Вариаций масса и если какая-то залупа вдруг взяла на себя право чет там завершать, то надо такую залупу давить сапогом. В документации написано:
>Проверяет условие. Если условие имеет значение false, выдается сообщение и отображается окно сообщения со стеком вызовов.
Если ты судишь по другим языкам, то штош, логика сишарпа меня устраивает больше.
>для чисто вывода в аутпут и так есть Debug.WriteLine
Но он без условия. У меня был случай, когда окно должно было закрываться при отсутствии связи с сервером. Но связь может разрываться как штатно, так и в случае ошибки на стороне сервера. И чтобы окно мне не срало лог при каждом штатном закрытии, я использовал if, хотя надо было assert. При этом выполнение остального кода должно было проходить в обычном режиме, потому что на стороне окна проблем нет.
А для прерывания обрабатывай исключения или сам указывай дальнейшие действия. Все логично.
Да это я понял. Просто коллекция с запретом редактирвоания.
Только я не представляю случаев, в 98% мне именно что нужно редактировать коллекцию — в этом суть.
>так как в IReadOnlyCollection можно завернуть любой массив
Чем тебе IEnumerable не устаривает? Это ведь тоже универсальная вещь.
принимается.
Так то претензия не к ассерт у меня, а к тому что они похерили код контракт, а взамен предложили лютую дичь в виде nullable
assert поддерживают, но это не совсем то.
У меня когда устанавливалась то половина файлов не установилась. ХЗ как работает щас, мелкософт в своём репертуаре что пиратка что с сайта всё один хуй у них
То были эксперементы... А то, как я сейчас написал в100 раз легче, понятнее и тд. Я даже без особых проблем смог linq запрос сделать. Тупо по кайфу, тут я потратил часа 2, а там я дня два ебалася и в итоге все криво, хуево было
Мда, и накуя го(вно)ланг нужен-то тогда…
>рассказывать "алгоритмы нинужны", "матиматика нинужна", "можна в экселе загребать бабулесики больше чем любой программист
А ты сможешь пояснить-то зачем они нужны.
Ну, давай. Какие задачи ты решал за пределами собеса, где тебе хоть раз пригодились алгоритмы.
Даже не так. Давай я тебе реальную задачу дам.
У тебя есть ARM32 битный одноядерный, 64MB оперативки, BusyBox, sqlite. Задача - опросить 256*x устройств по modbus и отдать данные в облако по какому-нибудь mqtt за максимально быстрое время.
Так вот. Это реальный кейс. Это кейс требующий производительности близкой к максимальной. Где ты тут будешь математику использовать? Какие алгоритмы применишь? Почему все что ты придумаешь, кроме очереди с приоритетом - говно?
Заебал ты уже своим код контрактом. Единственный плюс у него был, что он там что-то пытался в былд тайме проверить. Но это не нужно ибо все равно внешних данных больше.
Все остальное пишеться или самому в один файл в 100 строк, или есть хорошие готовые либы.
Либо можно угореть и запилить себе и код генерацию, и билд тайм чеки.
Встроеный в язык нул гард отменили кста
https://devblogs.microsoft.com/dotnet/early-peek-at-csharp-11-features/#c-11-preview-parameter-null-checking
Так это задача требовательна к производительности, эта задача - требовательна к ресурсам. И при этом оно явно показывает, что ничего кроме умения обойти массив и в крайнем случае - использовать очередь с приоритетом - тебе нихуя в реальном мире и не надо.
Какие задачи средний шарпер-то решать будет? DTO'шку в базу загнать, да иногда что-то с xml поделать. Все это у тебя на стандартных решениях майков сделано, где уже индусы тебе оптимизировали все что только можно. Не выебывайся - учись этим пользоваться и сиди спокойно.
Нахуй так заморачиваться пасаны?
Тыщи телодвижений вместо того, чтоб ебануть везде IEnumerable/ICollection да хоть List бля
>IEnumerable я принимаю на вход и если мне нужно свойство Count, то я проверяю реализует ли коллекция ICollection
Зачем и главное нахуя?
Затем, что если мне придёт коллекция на 100 миллионов объектов я не хочу их итерировать в случае Count() да, такого не должно быть в принципе, но всё же. Даже условные тысячи 2-3 объектов супер впадлу итерировать и это нереально медленно.
>Тыщи телодвижений вместо того, чтоб ебануть везде IEnumerable/ICollection
Затем, что ICollection ты должен использовать для имплементации пользовательских возможно потокобезопасных коллекций которых нет из коробки, например деревья или графики
>да хоть List бля
Это может быть избыточным
Понятное дело, что у условном ендпоинте можно сделать хоть массив, хоть коллекцию, хоть блять че угодно, но когда ты делаешь что-то производительное - приходится думать правильно
этот единственный плюс есть киллер фича так то.
Помимо расширенного Assert проверка в билдтайме весьма приятная штука.
И при желании все это вырезается из рантайма ради перфоманса.
Можно ли сделать свою реализацию с блекжеком? ну можно конечно. можно и свой редактор запилить - а че нет, вон жетрбаинсы запилили и ты запили. делов то )
Каждый день с утра занимаюсь разработкой тулзов вместо разработки собственно продукта ))) (сарказм)
Ставишь пакет от того же жидбрайнса, обмазываешь арибутами аргументы и у тебя есть ворнинги. Раз тебе так стандартные нулаблы не нравятся.
Подкручиваешь код генерацию, тот же фоди умеет геренировать чеки по жидбрайновским нул атрибутам - есть рантайм валидация. Я давно нек иследовал, но думаю, что сейчас даже лучше варик, чем фоди есть.
>И при желании все это вырезается из рантайма ради перфоманса.
Хуйню не неси. Смысла в таких валидация без рантайма ноль. А если надо, то в тех же гардах касатомных в одну трочку делается.
Для дизайнера. Дизайнер - это когда ты в хамл код разметки пишешь, а рядом готовое окошко рисуется. Это в данном контексе - дизайнер. Это - для него.
Ну е-мое, ну это понятно. Вопрос в том, а зачем оно понадобилось, если есть параметр ширины и актуальной ширины? Зачем нужен третий параметр?
Тебе нужна сессия судя по всему.
>Затем, что если мне придёт коллекция на 100 миллионов объектов я не хочу их итерировать в случае Count() да
В итоге просто через Sort сделал
>если есть параметр ширины и актуальной ширины?
Актуальная вообще для рантайма. Да и просто ширина тоже.
Ты же не всегда можешь ее вписать (допустим ты пишешь контрол, который должен вписываться в контейнер и ты ему ничего не задашь), а может ты вообще в Blend дизайнишь и у тебя все застаблено, данных нет, кода нет, размер не вычисляется как надо и все выглядит не так.
поэтому в дизайне есть d: аттрибуты которые могут выставить/переопределить значение
Нужно просто не очень часто.
бери да записывай. и не будет тебе эксепшена
Так есть же асинхронная функция в FileStream, она запишет тогда, когда файл освободится. Правда если ты что-то с высокой частотой пишешь, типа лога, то может записываться не в том порядке, в каком ожидалось из-за занятости файла другими процессами.
Асинхронная запись вроде не вызывает эксепшина т.к. ее суть — дождаться и записать.
Можешь проверять File.Exists перед записью или чтением.
https://stackoverflow.com/questions/11774827/writing-to-a-file-asynchronously
>Раз тебе так стандартные нулаблы не нравятся.
да не говорил я что мне не нравятся стандартные нулабле
Я говорил что нулаблы - маааленькая часть же
псевдокод
int Delta(int min, int max){
Contract.Requires(min<max)
...
}
по хорошему при попытке вызвать Delta(10, 5) получу ошибку в рантайме и варнинг в разработко-тайм.
Где тут нулабле и как мне помогает "вместо контракта используйте нулабле" я хз о чем они вообще.
> Смысла в таких валидация без рантайма ноль
Нет это не так. Ты же не проверяешь валидность в каждом методе. Если у меня граница контекста и я проверил на границе валидность входных данных, то должен ли я в каждом методе и далее проверять валидность данных и состояний? Я могу просто вырезать это все, как сейчас вырезается Debug.Assert
Тут каждому свое - кто то юзает везде List и "я и так все знаю и не ошибусь", а кто-то любит строгость когда компилятор проверяет максимум, а "потом в рантайме оно бахнет". Понятно что все не проверить, но все же.
В MDSN примерах, в параметре "Key" приписывают тип слайдера для ориентира, но если у тебя дохрена элементов, то при биндинге локального ресурса выпадает такой адский список кистей, что будешь год искать нужное. При этом по факту они не нужны.
Я просто Шлепа
И что мне эта проверка даст? Я всё на в MSDN написано делаю, но если пытаюсь записать в файл почти одновременно то происходит пикрил. На UWP пилю.
там же в конструкторе есть параметр с этим
https://learn.microsoft.com/ru-ru/dotnet/api/system.io.fileshare?view=net-6.0
Blazor без asp.net явно никому не будет нужен. А из вариантов есть ещё десктопное гуи - wpf, winforms. Maui мертворожденный проект.
Закольцуй в цикл и записывай через try catch. Если выводится исключение, то меняй флаг выхода из цикла на false. Без проверки исключения.
Только вся эта асинхронность очень дурно влияет на порядок записи из разных потоков. Функция соберется записать в одно время, а по факту запишет спустя 10 строк, когда появится "свободное окно".
Тут надо городить что-то типа очереди, причем не обычной а ConcurrentQueue. Все потоки скидывают в эту очередь, а записывающая в файл функция — одна на всех и вытаскивает таски из очереди.
>ConcurrentQueue
если нужно ждать, то обычный семафор
иначе Channel/BlockingCollection
ConcurrentQueue тут неудобен
Ну вот я кстати семафор приколхозил, с ним работает, но я думаю это какой-то совсем лютый костыль
Абсолютно самая что ни на есть нормальность.
Просто нужно понимать что при очень интенсивной записи код будет ждать пока запишет.
Вот поэтому я и предложил ConcurrentQueue.
Все кидают в один "буфер" и продолжают делать свои дела, а одна функция этот буфер разгребает и пишет в файл.
>Channel/BlockingCollection
А разве не от этого ConcurrentQueue призвана избавить?
>ConcurrentQueue тут неудобен
А что там неудобного? Всего два метода: добавить в очередь и вытащить из очереди.
Метод Enqueue для добавления данных в очередь.
Только читальщик должен "пытаться" взять из очереди таску через TryDequeue — тут надо цикл организовать.
Причем там не надо ничего удалять из очереди — оно автоматом.
Единственное, над чем нужно подумать, как записывальщику в файл мониторить очередь, потому что совершенно непонятно в какой момент туда поступят данные (не будет же он в цикле постоянно чекать очередь?). Тут нужно какое-то событие или токен.
>Channel/BlockingCollection
они заточены на автопродолжение выгребания из них при появлении новых элементов.
>А что там неудобного?
ConcurrentQueue для этого не приспособлен, потому что никак не сообщает, что в нем появились элементы.
Нужно городить СЛОЖНЫЙ огород при добавлении элементов, который запустит цикл выгребания и учтет что пока он выгребает снова были добавлены и никаких проблем с синхронизацией не было
Ну или городить свою структуру которая прячет эту сложность внутри себя - собственно так ты и сделаешь подобие Channel/BlockingCollection
>как записывальщику в файл мониторить очеред
а в случае Channel/BlockingCollection думать не нужно. Они предназначены для решения паттерна Producer/Consumer
а обычная очередь это просто очередь.
>А почему нет?
Дед, мы живем в век мобильных устройств. Побереги батарею.
Сколько видов таймеров высрано по этому поводу.
А уж цикл While это вообще аут. События как-то шпокойнее.
Есть List<string> externalCodes = ["a", "b", "c", ... , "z"] (например)
И есть табличка Companies с проперти AgentList. AgentList это коллекция агентов у которых есть стринговая проперти CodeNumber.
Так вот. Как мне получить те компании, у которых хотя бы одна пропертя codenumber агента из АгентЛиста есть в externalCodes
Что не работает:
var _dbSet = cont.Set<Companies>()
.Include(p => p.AgentList)
//.Where(s => (s.AgentList.Any(p => externalCodes .Contains(p.CodeNumber))))
//.Where(p => p.AgentList.Select(cg => cg.CodeNumber).Intersect(externalCodes).Any())
Помогите пожалуйста с нужным Where, оба закомменченных не работают
Ошибка в линке - The Include path expression must refer to a navigation property defined on the type. Use dotted paths for reference navigation properties and the Select operator for collection navigation properties.
Имя параметра: path
Hangfire или Quarts.net
>>491175 (Del)
>>491181
Отбой, мне приходил массив стрингов с пробелами в начале каждого элемента, что я в дебаге никак не заметил.
В итоге .Where(s => (s.AgentList.Any(p => externalCodes .Contains(p.CodeNumber)))) работает и всё ок
К примеру есть диапазон значений от 0,1 до 100.
Длина слайдера примерно 200мм.
На первом видеорил — слайдер одной программы.
На втором — мой.
Заметьте, что у оригинального слайдера при такой же длине (и даже меньше), на участке от 0,1 до 1 шаг более подробный. Тут очевидно какой-то множитель. Какие есть идеи? Или лучше с этим вопросом в матан?
смотрю видос какого-то индуса, он на основе бд сделал классы. Я хотел проторить, но обасрался
Сам видос https://www.youtube.com/watch?v=1HE6xKCthLA&t
ну мне при просмотре уже стало понятно, что тут что-то не так. Но всё равно, хотел вот так несколькими кликами сделать классы.
если бд есть, то сюда смотри https://learn.microsoft.com/en-us/ef/core/managing-schemas/scaffolding/?tabs=dotnet-core-cli
У меня 12, большую часть сжирает ебаный браузер
Да, если тебе пайтон и ажура не нужны.
Сделал иерархию, в итоге мне вс код выдаёт миллион ошибок, что не видит всякие пространства имён...
А потом ещё говорят: ой, у нас дотнет давно кроссплатформенный, винда с вижлой не нужна, всё можно в вс коде делать.
Все (кроме жителей страны 404) юзают rider на маках
> выдаёт миллион ошибок
> Сделал иерархию
> А потом ещё говорят
Вс кодом открывай только папку, в которой лежит файл csproj.
А если у меня два проекта: само приложение и тесты?
Разобрался: Double.NaN
Ой, такой головняк.
в Application.xml, в заголовке прописываешь
Startup="YourMethodName"
Ну еще в свойствах проекта чекнуть, чтобы не стояло дефолтное имя запускаемого метода
Нашёл, в свойствах удобнее
MAUI предполагается как универсальная платформа для UI, но в большей степени ориентируется на мобилочки.
Ребзя, где я могу найти книги/статьи advanced и выше уровня о том как CLR компилирует и ранает C#? Например, как статические классы и переменные, лямбда выражения, параметры, вызовы, типа и структуры и т.п. выглядят под капотом?
>типа и структуры и т.п. выглядят под капотом?
Ты точно advanced?
Sharplab.io позволяет любые куски кода в рантайме переводить в IL.
sharplab.io тут тестить как что под капотом, олсо читай шапку треда, тем есть ссылка на стековерфлоу и книги хай лвла
>Sharplab.io
Я блять IL могу и в дотпике посмотреть, мне нужна книга где описывается вся теория дотнета, CLR, JIT, GC, причем глубокая, а не "переменная это коробочка, которая ссылается на значение в кучке"
Ооо, а книжечки там хорошие
CLR via C# Рихтера. Чуть подустарела, но все еще актуальна.
Ещё такая штука есть https://github.com/dotnet/coreclr/tree/master/Documentation/botr - оче специфичная инфа о принципах устройства clr-рантайма.
Рихтер CLR via C#
Нет. Потому что "Interfaces cannot contain constructors"
С одной стороны у тебя при первом старте уже будет все расставлено, а с другой стороны события с этими чекбоксами происходят на стадии инициализации, и начинается работа с экземплярами, которых еще нет. Из-за этого приходится городить города.
А дилемма в том, что я бы хотел все активации элементов делать в коде после инициализации, но при этом нет никакой защиты, если случайно в дизайнере будет выставлена галочка. А через месяц я об этом забуду и буду соображать, почему приложение не запускается.
Даже если я буду в каждом событии проверять IsInitialized, то это за задолбаешься везде прописывать.
Мне не нравится ситуация, когда нужно в голове держать некое правило, без которого код работать не будет.
>>492533
Мда ... судя по ответам
https://stackoverflow.com/questions/3150882/how-to-prevent-value-changed-events-from-firing-on-form-initialization-in-net
Чуда не существует. Нет никакого глобального рубильника, выключающего все обработчики событий, а если бы и был, то сломалась бы инициализация.
В итоге два выхода:
- Либо в каждом методе делать проверку на статус инициализации окна (или какой-то свой флаг).
- Либо забыть о создании автоматических подписок. И создать свой метод инициализации с ручной подпиской, и как следствие диспоза.
Второй вариант мне кажется более безопасным в долгосрочной перспективе, но опять какой-то лишний код.
в WPF у тебя все во вьюмоделях и чекед это биндинг, так что "случайно" ничего не поставишь.
Да и события обычные используются в разы реже
Суть шарпа ничем не отличается от жабы.
Это не желание
А опыт
Вечно "да тут нужно ерунда" превращается в "нужно это и то"
В итоге заранее закладываешь за воротник на будущее
Много всяких закорючек непонятных и в целом конструкция слишком монструозная
Вроде на третий раз должно уже нормально включаться, но это не точно.
Как часто ты нажимаешь Ctrl+S?
подтверждаю. такая же хрень. даже для нового проекта.
А если жидбрейнс непривычен после студии?
После PHP
сейчас у меня пикрелейтед: имеется коллекция чужих объектов, у них public bool IsDirty. они работают как "грязный бит" - когда есть какое-то изменение в объекте они становятся true, затем его надо самостоятельно менять обратно. при этом, я не контролирую другие компоненты которые могут изменить эти булевые или кто вообще это делает, единственное что торчит наружу это булевая на объекте.
Но это же говнокод!
На любом языке говнокод, невзирая на синтаксис.
В ифе идёт сравнение со строковым литералом. За это на первых курсах линейкой по рукам пиздят.
Но ведь в сишарпе == перегружен и сравнивает значения, а не ссылки.
ну... не совсем подменяться, но если сеттер какой-нибудь эвент квакнет после изменения было бы вообще идеально
Конечно забанят. То на четверг операция то на пятницу
Я скопом несколько добавил (в контекст), сделал миграцию, апдейтнул базу.
Новые таблички появились все кроме одной (называется Containers).
Так вот - через пгадмин и дбивер нет этой таблички, но через ЕФ она видна и с ней можно работать.
ЧЯДНТ?
Того что каждый день этот пост про операцию на завтра
Он раньше кидал полную картинку, где обследование за 2017 год. Сейчас обрезал дату. Этот кот сдох 5 лет назад.
я много жетбрэиню, но для шарпа студия
Мне в ней приятнее. Да и расширений побольше
и та штука показывающая потребление памяти и события тоже неплохо. А еще supercharger есть расширение
https://github.com/Aarnihauta/MethodReplacer/
Чекай Program, теперь вместо set_Property вызывается другой метод. Там можешь написать что угодно
Можешь описать изначальную задачу, мне кажется, раз тебе приходится лезть внутрь метода, то ты что-то не так делаешь
Для инстансов можешь использовать dynamic proxy, там есть способ перехватывать вызовы методов
так хармони не в смысле что хармони а в смысле что рефлексия
если для достижения результата надо метод подменять то лучше ну его нахуй
Конкуренции почти нет, одебилевшие от курсов гигбрейновские швайнокараси все в петухоне и жиесе. Вкатывайся анон
спасибо, и еще вопрос, насколько реально каким нибудь фуллстеком залететь? Мне кажется развиваться в двух напрвлениях сложно, плюс универ.
тебе бы какую нибудь выписку с суммой за операцию скинуть...
>одебилевшие от курсов гигбрейновские швайнокараси все в петухоне и жиесе.
Кстати, забавный факт.
Где-то два года назад перед приходом .net6 во всяких скилбоксах и т.д. и прочих начали открывать курсы по шарпу. Даже джаваеб Немчинский постоянно предрекавший смерть шарпу открыл у себя его курс. Но продержалось все это чуть больше года и либо шарпокурсы перестали пиарить, либо совсем позакрывали (как например в жидбрейнсе - инсайд инфа).
>навыки программирования
> Совершенно иной подход и где его брать не знаю.
Навыки программирования сейчас даже у детсадовцев есть. Для того чтобы понимать как раз и нужно учиться и читать дохуя скучных (для нормисов) книжек.
И что? C# сфера потихоньку сокращается или просто курсы были слишком сложные и никто бабло не платил?
>насколько реально каким нибудь фуллстеком залететь?
Фуллстеком как раз реально залететь, т.к. какой-нибудь условный реакт с js учится за месяц...два. Плюс очень много работодателей хочет себе двух спецов по цене одного.
Только нужно сразу понимать. Что по факту ты будешь на двух работах за одну з/п работать. Плюс это путь в никуда и нужно при первом возможном случае перекатываться в чистый бэк.
Насчет сокращения сферы - все так же как и в остальных сферах/языках. Разве что шарп себе в относительном выражении у джавы немного рынок отгрыз.
А вот насчет сложности, да есть такое. Насколько я заметил в шарпе традиционно намного сильнее ебут за чистоту кода. Плюс сам-то язык выучить просто, а вот начать разрабатывать на том уровне который нужен энтерпрайзу - новичку поебаться знатно придется.
Плюс не так уж много толковых преподов, а с учетом того, что в шарпе (для норм спецов) неплохо так в 21-м году зарплаты выросли, то им нахуй не уперлось идти в жидбрейнс за копейки лекции читать.
Я не знаю как на курсах по другим языкам например. Но на шарповых курсах конверсия была процентов 10 максимум. Т.е. из 10 человек только 1 мог претендовать на то, что его резюме хотя бы рассматривать станут и то если у него уже был хотя бы какой-нибудь бэкграунд при этом.
Я после ПНД и ПТУ сразу же устроился в нищем милионнике. Потом спустя 9 месяцев так же без задней мысли нашел новую работу. Так что динаху джавадебил
>>493504
Да бля у немчинского шиза ебаная, каждую секунду пиздит что ВОТ-ВОТ ЕЩЕ НЕМНОГО И ШАРП ТОЧНО ВСЁ ПУЗЫРЬ НАДУЛСЯ НЕВЕРОЯТНО, НУЖНА ТОКА ДЖАВА! А по факту в джаву вкатываются всё меньше и меньше, нежели в шарп, потому что джава морально устарела и уже не сможет догнать по возможностям .NET
>слишком сложные
Еще, кстати, в шарпе до сих пор языковый барьер играет роль. Практически вся актуалочка по фреймворкам до сих пор на английском, а то что переведено устарело и никому не нужно.
А большинство посетителей таких курсов не то, что онлайн переводчиками пользоваться не умеют, даже простой процесс гугления по ошибке для них это уровень рокет саенс.
>ВОТ-ВОТ ЕЩЕ НЕМНОГО И ШАРП ТОЧНО ВСЁ ПУЗЫРЬ НАДУЛСЯ НЕВЕРОЯТНО, НУЖНА ТОКА ДЖАВА!
Ну я про что и написал. При всей его ненависти к шарпу он все равно попытался под рыночек прогнуться и открыл у себя курсы по нему.
Я правда сейчас глянул на его сайт, как и ожидалось он так же учит неактуальной хуйне вроде винформс, WPF и MVC.
WPF еще актуальна более чем. Корпоративное ПО делают на винформах или впф, это его нисша. Иногда добавляют C++ если нужна высокая скорость
Твои проблемы, раз тебя волнует конкуренция то может тебе и не нравится программировать? Кому нравится тот ебашит код каждый день и вкатывается, оставляя нубасов позади
В большинстве своем это закрытые системы. Т.е. они пилятся/ковыряются годами и там сидит прикормленая команда, которой тепло-сытно и дергаться никуда не хочется. Что-то новое пилится только в областях САПР-а и экспертных систем, но чтобы туда вкатиться нужен хороший багаж по предметной области. Ну и зарплаты там в большинстве намного ниже рынка.
Потому что, где-то с выхода Core 3.1 народ осознал, что MVC с его привязкой к винде теперь нахуй не нужон и можно спокойно садить бэкэндера пилить чистый WebApi бэк, которому будет похуй на какой системе работать и похуй на чем будет написан фронт. Т.е. намного выгоднее иметь грамотного бэкэндера и грамотного фронтендера, чем двух фулстеков хуево разбирающихся в обеих областях.
Ну и все постепенно к этому и переходят. Так что искать сейчас работу на MVC - путь в никуда, т.к. в основной массе это будет старый стек и потом ты нахуй не нужен будешь с таким опытом.
Я хер знает. Теоретически да.
Но практически...
В серьезных конторах вряд ли. Там за лишнюю библиотеку прикрепленную к проекту заебешься согласовывать все. Ну чтобы писать на чем-то не имеющего статус LTS вообще можно забыть.
Может только где-нибудь в стартапчиках, где кабанчик модно-молодежный и топит за инновации и все новое.
В тырпрайз говне, где все шарперы и вы делаете веб приложение для "локального" пользования клиентом - может даже и нужно.
В остальном конечно юзлесс
Котаны, а как вы парсите в объекты json-ы у которых ключи на русском языке?
Через dynamic или делаете объекты у которых поля кириллицей обозваны?
Твой кот сдох в 2018
Примерно так:
- таак почитаем что это такое
- да блин еще статьи по EF, а мне нужен кор
- попробую
- да епрст
- да ну блин
- да как так то
- привет dapper
>Котаны, а как вы парсите в объекты json-ы у которых ключи на русском языке?
Никак. Это как себя не уважать надо, чтоб с таким кодом работать?
Я планирую фрилансить и иногда попиливать игрухи. Фрилансить собираюсь пиля мобильные приложухи или веб-приложения. Так вот, я никак не могу выбрать между флаттером и C# стеком.
Флаттер кажется больше подходит под разработку мобильных приложух. И игры простенькие 2д на нем можно делать, вроде все подходит. К тому же флаттер работает сразу почти на все стороны, и веб, и десктоп, и мобилки, фрилансить на нем должно быть довольно легко, сразу пиля приложуху и под айос и под андроид.
НО.
Тут я наткнулся на .net и понял что на шарпе можно делать то же самое, благодаря в основном Uno Platform. Плюс на шарпах есть юнити и моногейм. Плюс MAUI потихоньку допиливают.
Ну и вот я не могу решить флаттер или C#. Реально ли будет фрилансить разрабатывая мобильные приложухи на шарпе, или мне лучше смотреть в сторону флаттера. Плюс у шарпа охват шире, можно аж целую операционную систему почти полностью на нем запилить.
Кароче по сути мне нужно чтобы кто нибудь шарящий за меня решил, флатер или .net. Какие еще можно привести доводы C# против флатер? Есть тут такие кто пилит приложухи на фрилансе? Реально ли будет фрилансить на MAUI через годик другой?
На мобилках надо учить джаву/котлин. Там и инструментарий неплохой с Андроид студией.
Просто раньше на курсе 3 приходил дяденька и забирал маслят на стажировки. Но сейчас пиздец происходит и стало интересно продолжаются ли такие практиики.
Очередной инфантил с мриями о фрилансе, заканчивай с этой хуйней
Да кто дизморалит то?
осиляторского во мне дохуя. Сиквельщик передо мной стоит там, екзекюшн планы дрочит свои, я говорю бля старина съеби нахуй, выгребаю все таблицу в память, забирай и съёбывай
Все так и есть кста
>>494184 (Del)
Спасибо за подсказки, но я более удобную штуку нашел пока их изучал: ContractResolver
>Это как себя не уважать надо, чтоб с таким кодом работать?
Импортозамещение во все поля, чувачок.
Закажет тебе бизнес интеграцию с каким-нибудь гос-сервисом, еще и не с таким говном поработаешь.
Скорее приходят за теми кто представляет из себя что-то экрстраординарное. Либо дохуя умные, либо те за кого заранее проплачено.
Причем умные не в плане каких-нибудь олимпиадников (они то как раз нахуй никому не нужны), а те кто действительно быстренько во все въезжает, шарит на уровне намного выше среднего, плюс показывают хорошие результаты на практике помогая делать преподам их собственный гешефт. Таких преподы сами устраивают сигналя нужным дядям.
Не-а. Нормальная практика, точно так же как за рубежом. И не только в айтишечке, но и во всех остальных сферах. Берут либо тех кто уже свой, либо тот кто уже показал, что чего-то стоит.
Ну может. Хотя кому там тот задроченый препод может посигналить? Рогам и копытам, в которых их зять работает?
Мы про универ говорим. Это в школе все задроченные. В универе есть два типа преподов. Либо долбоебы до сих пор преподающие студиозам лабы на паскале. Либо продвинутые ребята шарящие за рынок и имеющие связи, и знающие что и как сделать на имеющихся у них мощностях (люди это кстати тоже ресурсы, а толковые студенты хороши тем, что это максимум дешевые ресурсы).
Причем ай-тишные факультеты даже проигрывают немного тем где реальным вещам учат. Например какой-нибудь шустрый завкафедрой машиностроения имея в наличии лабораторию с парой ЧПУ-шных станочков будет в деньгах купаться.
var collection = new int[] { 0, 2, 10, 5, 4 };
if (collection is [.., > 5, _, var even] && even % 2 == 0)
{
Console.WriteLine(even);
// 4
}
Инсайд индустрии - через 10 лет все будет писаться на расте + гитхаб копилот
игруньки делать хочешь?
Вот хейтят джаву, что там нету такого сахара, дак это даже хорошо, потому что язык легко учится и код легко читается. В сишарпе же навводили всяких закорючек и хрен пойми что они означают.
Если до 5 версии все изменения были логичными и делались с определенной целью, то сейчас разработчики языка как сороки собирают все фишки из других языков, без понимания зачем это нужно там. Ни какой цели в этих изменениях нет, просто напихать побольше всего, чтобы выкатить новую версию к назначенной дате. Язык замусоривается и превращается в синтаксическую помойку.
Или кроссплатформенность позволяет работать с консолью в режиме потока: читать символы из него и выводить символы без перескакивания по координатам?
>Можно ли на сишарпе написать консольное кроссплатформенное приложение типа вима или нортон коммандера
Можно, но UI будет на каком-нибудь электроне
>То есть можно ли рисовать в консоли как на экране по знакоместам: символ и аттрибут
Чего?
>Или кроссплатформенность позволяет работать с консолью в режиме потока: читать символы из него и выводить символы без перескакивания по координатам
Тоже нихуя непонятно, но можно
Мне кажется ты не понимаешь как работают консольные приложения типа вима или нортон коммандера. Они не создают своё окно, а работают в рамках обычной консоли.
Допустим у нас есть консольное окно 80 на 25 знакомест и я мог бы вывести символ в любое знакоместо по любой координате. Учитывая, что можно задать цвет символа и цвет фона, то получается простая псевдографика.
Вопрос, поддерживает ли .Net Core такой режим работы?
Мне в МВП-треде запретили учить голанг и сказали учить сишарп
Соси писю
Если тебе дали инструмент это еще не значит, что надо с него такие хатки строить
Даже на одних ифах можно такое наворотить, что хуй ты его распарсишь
Все нитики на сахар в шарпе - закостенелые тупые уебаны, которым лень швелиться.
Есть способ в VS автоматом добавлять в ссылочную базу проекта цепочи зависимых разделяемых библиотек?
Не надо кукарекать что это не для этого. Оно для того самого.
Видимо было заложено в Mono, а микрософты украли их код для своего Core.
>.NET Core уже легаси и у нас теперь просто .NET
Вы че там, охуели совсем? Я ж только посрать отошел! Заказанные свежие книжки по кору только через неделю приедут. Вкатился, блять.
Что заказал?
Но вообще книжки устаревают уже на выходе, потому что каждый год выходит новая версия, которая всё ломает.
Хз, ни разу не спрашивали. Это в ойропейских потогонках наверное такой хуйней страдают, чтобы зарплату сбить.
Есть свои подводные камни вроде автобоксинга, которые могут существенно снижать производительность программы.
Язык компилируемый! Причём первый раз из исходников в байт-код, а потом из байт-кода в нативный код процессора.
Лес рук! Вам бы лишь бы на собеседованиях с умным ебалом ответы на вопросы угадать, а дальше хоть трава не расти, ебашите такой же говнокод как и все, только с претензией.
1280x720, 1:23
Если книг читать не будешь - скоро грамоту забудешь! (с) Уесака Сумире, японская писечка
Допустим есть некая кнопка, которой надо перебросить ссылку на экземпляр Grid.
<CustomButton TargetGrid="{Binding ElementName=MyGrid}" />
Выводит ошибку:
Cannot find source for binding with reference 'ElementName=MyGrid'. BindingExpression:(no path); DataItem=null;
А какой Path, если я не хочу биндить свойство, я хочу биндить экземпляр целиком?
System.Windows.Data Error: 4 : Cannot find source for binding with reference 'ElementName=MyGrid'. BindingExpression:Path=.; DataItem=null; target element is 'CustomButton' (Name='MyButton'); target property is 'TargetGrid' (type 'Grid')
Короче (пикрил) есть два фрейма:
ModsPanelInserted и ModsPanelExpanding.
Задача состоит в том, чтобы страница типа ModifiersPanel сама себя перемещала из одного фрейма в другой. Но страница не знает куда ей перемещаться, для этого в нее добавлены два свойства:
InsertedFrame и ExpandingFrame (оба реализованы через DependecyProperty), в которых должны передаваться ссылки на оба фрейма.
Собсно в XAML я пытался передать экземпляр на фреймы, но без толку.
Причем во второй вариант с RelativeSource не выдает ошибки, но все равно свойство остается пустым.
Вкатуны скорее нахуй никому не нужны. Будут брать мидлов-синьйоров. Всех остальных нахуй
У меня дногруппник вкатился на джаву в сбер на прошлой неделе единственный из группы пока нашел работу
Первым делом так сделал.
Не, не, сейчас фрейм. Актуально то, что в этом посте >>495332 .В ошибке пишется, что не найден источник. Иначе бы ругался на неудачную попытку каста.
System.Windows.Data Error: 4 : Cannot find source for binding with reference 'ElementName=ModsPanelInserted'. BindingExpression:Path=.; DataItem=null; target element is 'ModifiersPanel' (Name='ModifiersPanel'); target property is 'InsertedFrame' (type 'Frame')
Ну не знает он где этот элемент mygrid в дернве
Во первых не RegisterAttached, а просто Register, во вторых класс должен быть унаследован от UIElement, в третьих геттер и сеттер должны выглядеть так:
public Frame InsertedFrame{
get => (Frame)GetValue(InsertedFrameProperty);
set => SetValue(InsertedFrameProperty, value);
}
Вполне логично. Шанс вката в джаву почти в 2 раза выше, чем в сишарп. Там и вакансий больше и конкурентов меньше.
Модифицируй удаление поста с необязательным аргументом bool ban. Почему так? Нет смысла банить без удаления поста. Нет смысла держать отдельный ендпоинт для банов, какой в этом практический смысл? Если ты банишь кого-то, значит его пост который нарушает правила сайта (не просто же так бан выдали, да мочух?) должен быть удален.
Урлы - это ресурсы, а не действия, в них не должно быть глаголов. Нет сущности "delete". Должна быть ручка DELETE /api/posts/post_id, куда может передаваться флаг ban, про него правильно всё сказали.
Двачаю, еще парашу в виде bool ban небходимо завернуть в dto какую-нибудь и вьюмодельку, а для респонса сделать условный АпиРеспонсБилдер который будет возвращать всегда одинаковую хуйню:
1. Дата и время ответа
2. Свойство Data (будет отражать сам ответ контроллера)
3. Свойство Error
В таком случае ответ ендпоинта всегда будет структурирован и условному мобильному дауну который юзать будет ендпоинты всегда будет приходить структура
{
dateTime: "...",
data: { ... жсон},
error: null
}
Так же, если сильно надо, можно добавить другие поля значимые, типа code. Офк возвращать надо Ok(ApiResponseBuilder.CreateApiResponse<T>(T data)) в случае если всё норм и BadRequest(ApiResponseBuilder.CreateErrorApiResponse<T>(message)) если например условный юзер не найден. Добавлять [ProduceResponseType] на контроллеры для OK и BadRequest, а сами методы контроллера должны возвращать (всегда) Task<IActionResult>1
>ендпоинт для банов, какой в этом практический смысл?
Ну бан можно отменить, можно просматривать баны по каким-то критериям.
>Нет смысла банить без удаления поста
Я тоже так думаю. Но есть но, а вдруг админ захочет забанить айпи/подсеть просто так (ну там торы хуйоры, страна не та и т.д.)
>>495513
> в них не должно быть глаголов.
А это всегда так или для рест-сектантов? А то вот, апи вк полон глаголов, например. Но я там в урлах delete написал для наглядности, у меня то в коде все лк ага, как же
> А это всегда так или для рест-сектантов?
Для рест-сектантов, конечно же. У нормальных людей эндпоинты типа POST /api/posts/deletePostById, всё через POST, везде глаголы, никакого GET, в ответе всегда 200 OK и код ошибки в теле ответа.
>Нет сущности "delete". Должна быть ручка DELETE /api/posts/post_id
Вот посмотрел на свой говнокод еще раз и у меня есть
/api/threads/pin /api/threads/lock etc
получается я должен это переделать на
[PATCH] /api/threads/{id}
и получается в body гнать на сервер все значения полей для треда, включая текстовые? А если это сущность, где много текстовых полей, гнать это все на сервер ради обновления одного флага (хуита). Проверять на нулл в модели? А если налл валидное значение? Так много вопросов и нихуя не понятно. А все статьи в тырнете описывают только простейшие случаи, где никаких проблем офк нет.
Уж как знать. Это называется удалённым вызовом процедур, используется много где и на соглашения restful совсем не похоже.
Да, PATCH. Надо только решить эту проблему:
> Проверять на нулл в модели? А если налл валидное значение?
Для валидных значений можно передавать не null, а 0, пустую строку, пустой список и т.д. Так и отличать не заданное значение от не переданного. Это опять же простые случаи, в более сложных придётся выдумывать флаги для идентификации, что указанное поле передано. Да, сплошные костыли в этом ресте. Особенно если действие не вписывается в концепцию круда.
> RegisterAttached
Исправил
> во вторых класс должен быть унаследован от UIElement
Это Page, а она наследует UIElement (пикрил)
>третьих геттер и сеттер должны выглядеть так
А какая разница через что присваивать? Мне геттер не нужен. Просто через свойство не так универсально.
В любом случае я попробовал и не помогло.
Если присваивать через код, то норм работает. Похоже биндить можно только свойства, но не экземпляр класса целиком.
>Похоже биндить можно только свойства, но не экземпляр класса целиком.
Хз, ща от нехуй делать потестил, всё биндится.
мимо другой анон
>Для валидных значений можно передавать не null
В этом нет смысла, значения должны быть nullable обязательно. Параметры которые являются обязательными помечаются в моделях как [Required]
Не качайте. Уродский дропмифайлс положил архив в архив, запаролил, а пошатал всю структуру файлов .
Другая ссылка https://transfiles.ru/6ibm4
Вот ты спросил это здесь, но не в треде про жабу. Значит, шарп тебе ближе.
Фуух, спасибо! Завелось.
А почему работает только с UIElement? если я хочу передать фрейм и ставлю тип свойства Frame, то пишет
Cannot create default converter to perform 'one-way' conversions between types 'ModifiersPanel' and 'System.Windows.Controls.Frame'. Consider using Converter property of Binding. BindingExpression:Path=; DataItem='ModifiersPanel' (Name='uModifiersPanel'); target element is 'ModifiersPanel' (Name='uModifiersPanel'); target property is 'ExpandingFrame' (type 'Frame')
Приходится каждый раз делать каст. Ну тут я попробую разобраться сам. Еще раз спасибо.
я нашел как мне кажется охуенное решение:
1. сделал энум флаги
2. каждый тик флаги проверяются:
if ((state & flagname) == flagname)
3. если да то выполняется какой-либо из этапов обновления кешей и целевой метод
флаги моделей выставляются тоже каждый тик если обновились
а флаги из гуя нанизываются |= flagname по эвенту
после выполнения целевого метода флаг сбрасывается
таким образом каждый тик в теории у меня самые последние данные, а если им не надо обновляться то и не надо...
Сука как же меня бесит этот впф. Самое нелогичное говно во вселенной. Я кодом мог написать две строки сутки назад.
Ну какого хуя снова не работает? Как забиндить родителя?
По имени не могу — цикличная зависимость.
Начинаю искать предка — предок не найден.
Даже Self не работает.
Я уже тупо перебрал все ключевые слова и комбинации.
хз че там у тебя. слепил кастомный проперти для контрола и попробовал аналогично - проперти получает родительскую кнопку
Потому сейчас мы будем писать TCP-чатик.
От вас - предложения по тому как улучшить это дело.
ВПН включи
У меня он еще попытками связаться с сервером грузит проц на 40%
с Frame не работает. Ну и плюнь на него.
Используй DataContext (тру) или проксиобъект сделай (неплохо, но не тру в данном случае).
Ну и вот тебе еще в копилку решений
https://pastebin.com/VPtVBst0
в данном случае не работает ибо видит выше родителя, но работает если нужно биндить всякие меню и прочую хрень что не найти в дереве.
Не знаю.
Блин. Чет не могу придумать формат сообщения.
Пока что придумал "[clientId] message" Но эт какая-то херня. Надо нормальный формат в духе: [len][headers][body]. Но чет не знаю я. Ды.
Признайся. ты просто хвастаешься темой в студии. А на формат сообщений тебе пох.
Не.
Я могу на дефолтную поменять.
Я ж сразу сказал. Мне - скучно. Хочу чатик нахуячить. И думал скучающие аноны - посмотрят,за полетом моей фантазии и будут чет там советовать. Типа да. Укажут, где я говнокодю.
>с Frame не работает. Ну и плюнь на него.
У меня во фреймы загружается страница, а их может содержать вроде только Frame и NavigationWindow.
>DataContext
А каким образом? Насколько я понял, можно создать класс, а DataContext просто делает доступным свойства этого класа в XAML.
Или нужен какой-то промежуточный класс, свойства которого связываются с Фреймами. А затем Страница свзязывается со свойствами класса?
>У меня во фреймы загружается страница
хз. никогда не использовал Frame.
Суть Frame - изоляция. Ну чтобы типа оно работало в своей песочнице, не наследовало стили (кроме основных стилей приложения) и поэтому не наследует DataContext, ну и такие проблемы биндинга
ContentControl + немного кода на коленке = отлично работают.
>А каким образом? Насколько я понял, можно создать класс
Для тебя наверное никаким. Раз ты решил использовать Frame значит "так надо" и в нем....ну можно в code-behind прокинуть DataContext странице, но...собственно в этом месте можно прокинуть и сам Frame, то есть именно то, что ты хочешь сделать через xaml
То есть ты изи можешь решить проблему через code-behind/attached/behaviors/...
и лично я бы решил создав аттачед с кодом
>Или нужен какой-то промежуточный класс
Такое тоже возможно. Кодится класс который обычно называют вида BindigProxy, который кладется в ресурсы окна и его видят все кому не лень
типа вот https://thomaslevesque.com/2011/03/21/wpf-how-to-bind-to-data-when-the-datacontext-is-not-inherited/
только в твоем случае холдер ссылки.
Но проще атачед сделать прокидывающий фрейм странице..
...но лично я вообще хз зачем странице знать про родителя вообще, а уж тем более про то, что это фрейм. Это неправильный подход в принципе.
>>496161
Страница позволяет вынести группу элементов, как будто это отдельное окно — со своим XAML-дизайнером. Это позволяет стакать окна, как сделано в вижуал студии, к примеру. Да и вообще удобно.
Вы должны понимать, что я не знаю какие там впереди подводные камни. Я взял страницу как нечто очевидное для моей задачи. Затем оказалось, что страница может помещаться только во фреймы. Затем оказалось, что и фреймы имеют свои ограничения при биндинге.
Маленькие ограничения нарастают как снежный ком и приводят тебя в тупик.
>>496135
>Используй юзер контрол
А на чем о будет основан? Мне надо плодить сущности. Сперва нужна все та же страница, которая обязательно оборачивается во фрейм, а дальше я это оборачиваю в грид — вот он мой контрол, основанный на этом гриде. У меня иногда кровь из глаз от количества вложений.
Сидит дед, во сто шуб одет. Ответ: WPF-кнопка
> как будто это отдельное окно — со своим XAML-дизайнером
>Это позволяет стакать окна, как сделано в вижуал студии
не понимаю. покажи пример.
>но лично я вообще хз зачем странице знать про родителя вообще
Сомнительное решение, которое вероятно мне аукнется. Хотел сделать страницу целиком автономной — она может быть в нескольких местах в окне. Я хотел этой странице перекинуть список всех фреймов, в которых она может существовать. А далее страница сама перемещается от фрейма к фрейму, вместо того, чтобы основное окно перемещало страницу.
Короче, реализация как в вижуал студии, когда пользователь может объединить два окна в одно. Только там посложнее структура, а не просто стак.
>когда пользователь может объединить два окна в одно
типа такого что ли?
https://github.com/Dirkster99/AvalonDock
Ну смотри. Ты мог бы сделать как пикрил 1 — окно, которое визуально разбито на два блока.
Вот если каждый блок вынести на отдельную страницу. То у пользователя есть возможность просто сделать два отдельных окна (пикрил 2) , или поменять блоки местами, или расположить горизонтально.
Главное, что каждый блок живет своей жизнью.
Да, оно.
Тебе для этого не нужна страница, тебе нужен юзер контрол ещё раз тебе говорю
>>496237
>А далее страница сама перемещается от фрейма к фрейму, вместо того, чтобы основное окно перемещало страницу.
У каждого свой подход к фломастерам.
Можно чтобы окно перемещало между фреймами
Можно чтобы страница страдала ерундой и перемещала
А можно сделать какой то манаджер который может вызвать окно или страница и он все устроит
но лично я просто бы сделал эти страницы юзерконтролами (а ведь страницы и есть юзеркотролы с оговорками и знанием (нужным ли в твоем случае??????) о навигации)
И у меня везде такие вьюмодели и DataTemplate и никто ни про какие фреймы и окна не знает - перемещение происходит одной вьюмодели коллекции в другую коллекцию, а там уже Items/ContentControl-ы сами найдут и отрисуют что нужно.
То есть принцип тот же, но все знание не на уровне визуальных контролов - их дело только рисовать содержимое и ничего не знать.
Если можно все решить на уровне вьюмоделей и не лезть в code-behind то я так и делаю.
Кроме юнити что ещё можно пилить?
А ведь выше по треду уже говорилось про вечное "на завтра операция "
А чего ему не быть. Юзер контрол это обычный контрол
Как та же кнопка только без поведения и дефольного шаблона
Это Page особый
Как засунуть жирафа в холодильник?
Нет.
то есть русская студия
анимешная тема (при этом справа нет баров чтобы не закрывать рисунок)
тебя не смущают )
Все это меркнет перед шумом из точек.
Ещё Гитлера приведи в пример. Настройки в студии не убивают людей.
Моногейм возьми
Годот попробуй.
Там можно настроить билд на разные платформы через консоль парой команд.
Я пару лет назад как-то делал. Собрал батник, который командовал годоту сборку релизов под нужные мне платформы (андроид, веб и винда), а потом через батлер сразу деплой всего этого на itch.io. И грубо говоря у меня с нажатия одной кнопки сразу релиз обновлялся на сайте.
Сейчас правда я все это забросил.
В годоте еще и нормальный шарп встроен, в отличие от того огрызка в юнити. Плюс если есть навыки можно пересобрать сам движок, выкинув оттуда все лишнее (например 3Д если оно не нужно) и получить относиетльно легковесные поделк (но тут уже знание плюсов нужно или нужных людей)
Лол.
какую-то хуйню я нагородил в общем. ночью это казалось охуенным решением
есть ли способ похитрее сделать?
я не могу отойти от необходимости теребонькать WeightChangePolling() и соответственно весь метод каждые N секунд
Анон, ты флаговый enum написал довольно тупо.
1)Он используют байтовую маску, поэтому любое значение с 0 будет считаться активным всегда (то есть 6 он будет воспринимать как 0 + 2 + 4)
я тупенький и не очень разбираюсь, про флаги и байтовые операции узнал только вчера. как правильнее сделать?
алсо вот что сделал. насколько это ГРЯЗЬ?
протестировал, вроде бы значение с 0 воспринимает правильно и выполняет нужный метод при нужном значении
Приходится создавать новый файл, с новым именем класса и копипастить код туда.
1) Флаговый енам можно начать со значения 1 << 0 - он будет равен единице
2) Название класса должно быть с большой буквы.
3) Метод InitMethods - не нужен, все это в конструктор. Плюс он у тебя даже не сработает, т.к. actions - readonly
4) Переменная actions должна называться _actions
5) Использовать флаговый енам в качестве ключа словаря в таком виде - ебанизм. Во первых ты не все варианты учел (например Method1+Method2 и т.д.) и при выпадении словишь исключение. Во вторых если у тебя вариантов станет побольше ты заебешься прописывать все варианты.
Шапку читай
я код не смотрел. просто демотивирую.
а теперь посмотрел.
хз че он делает, но зачем кастовать к инту енумы хз. Их можно использовать прямо как ключи у словаря
А еще можно унаследовать енум от байта и экономить.
спасибо за развернутый ответ
1. не знал про это но читал что флаговые энамы вроде бы требуют None = 0
2, 4. класс тестовый я чисто проверить возможность но да я насвинячил
3. всмысле не сработает? я же запустил этот код, все сработало и заполнило даже с ридонли.
5. это да, я затуп
но у меня будет только три варианта твердо и четко, больше не будет
и тут подумал а зачем мне вообще флаги и вот это вот все добавление?
я хочу сделать такую вещь.
у меня только три метода которые я хочу вызывать в определенном порядке:
метод 1 => метод 2 => метод 3 если данные для метода 1 изменились
метод 2 => метод 3 если данные для метода 2 изменились, но данные для метода 1 в порядке
и метод 3 если данные для метода 3 изменились, но все остальное нет.
>>497458
я где-то прочитал что энумы оптимизированы под инт, а если использовать как ключ энум то там вроде бы получается объект вместо инта который внутри в инт, но я не уверен, я хотел чисто инт сравнивать
ну словарю на тим плевать - он все равно вызовет GetHashCode и потом сравнивать будет.
А енумы внутри себя имеют кучу переборов "is int32/byte/double"
Вообще магические структуры.
>если значение больше 5 и четное, по моему все просто
значение говоришь )
там вывод - 4
4 больше 5?
ты, прав, ты
>Нихуя не понял
ни в каком не создает. таска это "десктриптор задачи". аналогичен CancellationToken по сути.
Допусти есть классы:
class A { }
class B : A { }
Можно ли сделать так?
List<A> a = new List<B>();
или наоборот
List<B> b = new List<A>();
Если это так, то почему иногда когда я из таски обращаюсь к основному потоку, то он сыпет экспешный о том, что низя из другого потока к мейн потоку обращаться.
Когда писал бэкэнды, с этим проблем не было. А когда писал клиентские приложения, то орал.
я это 3 треда назад пояснял.
потому что у тебя в голове перемешались понятия
У тебя в голове таска - "вот это мне нужно выполнить отдельно в другом потоке/тредпуле"
А на деле есть такие понятия
1 таска, которая имеет семантику "задача", то есть что то логически отделить и выполнить.
2 Объект-дескриптор, который ассоциирован с этой задачей чтобы видеть статус, дожидаться и получить результат (его синонимы - Defer/Promise/Future/..)
Пункт 1 говорит про то что у задачи есть границы и вообще она будет выполнена и есть начало конец.
Но тут нет ничего про то "как она будет выполнена".
Поэтому таски сами по себе не работают. Это просто определение корутины, которые ты называешь тасками.
Их выполняют другие - тредпул, отдельные потоки, процессы, вообще никто (CancellationTokenSource)...
И все траблы от того, кто выполняет и как. В бэкенде нет контекста синхронизации по дефолту, а в десктопах есть - и тебе и мешает. Но контекст синхронизации - это не из TPL, а из классического многопоточного программирования.
Туда же и async/await - он просто пихает все в контекст синхронизации или тредпул. Это механизм тоже не из TPL, а тупо сахар, который появился позже понятия тасков
Task.Factory.StartNew/Task.Run - несмотря на класс Task - тупо хелперы для запихивания задач в тредпул/свой поток (ну чтобы все было красиво и ты не работал напрямую с тредпулом, что неудобно)
Смотритет какая фигня.
Сервер. TCP.
Подключаются 50к клиентов. Соответственно - тредпул расширяется. Пытается обработать клиентов. Все ок. Лезем в базу - хуяк, количество коннектов резко к максимуму подходит. Часть коннектов клиентов успешно обрабатывается. Дальше - все соединения, что создал EFCore - висят в Idle. Умирают через 5 минут. Это повторяется.
Собственно. Я нашел костыльный метод - убиваем коннект который больше 10 секунд в Idle. Но это пиздец же не правильно и кажется оно не должно так работать.
Проблема, как я понимаю, в том, что коннект привязывается к потоку в котором создан. А т.к. всюду асинхронщина и ConfigureAwait(false) - выходит так, что выполнение работы с сессией клиента - по потокам прыгает.
Почему так думаю? Потому что чтобы воспроизвести проблему - достаточно создать 110 тредов и в них контекст создать - сразу счетчик подключений в pgAdmin - скакнул, а потом оно Idle. И из других мест не подключиться.
Собственно. Че делать-то?
Вроде как PgSQL - хороший-годный. Я - дебил, что не следил за потоками и вот так вот скакал, чтобы ничего не простаивало. Но блин. Да.
Спасибо
Нет. А шо це таке?
Делать игоры на юнити
Где можно спиратить?
очевидно же чтобы было больше шансов.
Зачем в 26 строке создается объект базового класса с конструктором дочернего? Он же все равно не будет иметь весь функционал. Не легче создать объект дочернего?
Новое, но на английском, не? А у меня на русском
Создается объект дочернего класса и приводится к базовому
нахера? Ну может показывают что так можно. Для примера по полиморфизму кода не хватает.
Почитай книжку "Философия Java" Брюса Эккеля. Там всё подробно разжёвано про ООП.
Затем чтобы отсеивать долбоебов, которые до сих пор начинают проекты со стандартных шаблонов.
аргумент уровня /b, но никак не /pr
Есть UserControl (пикрил), а в нем TabControl. В каждом табитеме контент разный высоты. Соответственно, при переключении на таб, меняется высота UserControl (у него размеры автоматические).
Так вот этот юзерконтрол должен отображаться по нажатию кнопки в главном окне (пикрил 2), но не просто, а с анимацией высоты — по типу "шторки" меню в смартфоне. По сути это должен быть попап. В нем уже есть встроенная анимация, но только на отображение, но если я буду переключать табы, то анимации смены высоты не будет.
Так вот была идея завернуть юзер контрол в какой нибудь контейнер и опираясь на UserControl.ActualHeight менять высоту контейнера. И вот тут возникает проблемка.
1. Если контейнером будет Grid, то статическая высота грида делает ActualHeight контента равным, собсно, высоте грида. И я тупо не знаю до какой высоты анимировать.
2. Есть контейнером будет Canvas, то габариты холста никак не повлияют на актуальный размер контента. Но тут возникает другая проблема: по задаче, ширина UserControl должна быть равна ширине контейнера.
Короче, я не знаю как естественным образом взять максимальную высоту UserControl, если этот контрол может быть "сжат" гридом. И таких UserControl-ов будет 10500 и я не хотел бы в каждой прописывать новое свойство, добавлять подписки на события (даже если это будет абстрактный класс).
>Если ООП, то вот тебе задача:
>Есть openweather API
Дядь, какой нахуй апи? Я пока только полиморфизм начал осваивать.
Тогда какие тебе задачки нужны?
Сила ООП не в 3х китах, а в гибкости, которое оно дает. Ты формируешь рабочий граф и все начинает работать, инкапсулируется, SOLID-ируется, сообщения бегают. В общем это нужно мозг форматировать чтобы ООП начать использовать по делу, а не просто так.
я очень давно не читал книг, поэтому посоветую старое -
дуй читать про паттерны, только не GoF, а что то типа Thinking about patterns (и похер что там жава), а потом вроде бы "Джошуа Кериевски: Рефакторинг с использованием шаблонов"(название вроде то, но год смущает) не сильно прорабатывая
(сам то я ее не дочитал, когда понял суть)
Я хочу, что бы разные части моей программы (которых может быть сколько угодно) работали с разными реализациями интерфейса IPrinter (которых тоже может быть сколько угодно).
В общем, в конструктор классов частей программы я буду передавать словарь с реализациями. Моя задача в том, что бы если в будущем появятся еще реализации интерфейса IPrinter, я мог добавить реализацию нового класса и дописать лишь одну строку - dictionary.Add("N", () => new PrinterN());
var dictionary = new Dictionary<string, Func<IPrinter>>();
dictionary.Add("1", () => new Printer1());
dictionary.Add("2", () => new Printer2());
var class_of_getter = dictionary["1"].Invoke();
class_of_getter.Print();
public interface IPrinter
{
public void Print();
}
class Printer1 : IPrinter
{
public void Print() => Console.WriteLine("hello 1");
}
class Printer2 : IPrinter
{
public void Print() => Console.WriteLine("hello 2");
}
Не является ли то, что я тут написал, антипаттерном? Возможно, кто-то уже такое придумал?
Я хочу, что бы разные части моей программы (которых может быть сколько угодно) работали с разными реализациями интерфейса IPrinter (которых тоже может быть сколько угодно).
В общем, в конструктор классов частей программы я буду передавать словарь с реализациями. Моя задача в том, что бы если в будущем появятся еще реализации интерфейса IPrinter, я мог добавить реализацию нового класса и дописать лишь одну строку - dictionary.Add("N", () => new PrinterN());
var dictionary = new Dictionary<string, Func<IPrinter>>();
dictionary.Add("1", () => new Printer1());
dictionary.Add("2", () => new Printer2());
var class_of_getter = dictionary["1"].Invoke();
class_of_getter.Print();
public interface IPrinter
{
public void Print();
}
class Printer1 : IPrinter
{
public void Print() => Console.WriteLine("hello 1");
}
class Printer2 : IPrinter
{
public void Print() => Console.WriteLine("hello 2");
}
Не является ли то, что я тут написал, антипаттерном? Возможно, кто-то уже такое придумал?
Что такое кричать во View с точки зрения микросервиса?
Кажись разобрался. В попыте канвас, в канвасе юзер контрол. И все трое биндят ширину к нужному объекту. Или двое — попыт сам растянется.
>Не является ли то, что я тут написал, антипаттерном?
Под антипаттерн можно подписать практически, что угодно. То что, ты описал по факту разновидность паттерна стратегия, одного из самых часто применяемых.
>Возможно, кто-то уже такое придумал?
В DI контейнерах даже под это дело специальные механизмы есть, когда ты запихиваешь в контейнер кучу реализаций одного интерфейса, а потом при внедрении получаешь словарь на них и выбираешь нужный.
Поздравляю с изобретением велосипеда. Без сарказма.
>необходимо реализовать микросервис... погода изменятся на новое состояние - кричать об этом во View
Не понял этот момент, кто кричать должен?
вебсокеты же или другие постоянные коннекты.
вопрос 1:
есть dll #1. в нем статический класс со статическими методами и т.д., к нему обращаются изнутри, все туда-сюда
есть dll #2. с тем же статическим классом.
что будет когда два dll встретятся в одном ассембли?
два разных но одинаковых во всем кроме неймспейса статиков будет?
как поступать в таком случае если я не знаю заранее будут ли две дллки в одной ассембли?
вопрос 2(практически то же самое):
вот я хочу подключить сторонний код к своей хреноте №1. я ее хочу смерджить в один длл со своей хренотой №1. что будет если смердженный код встретится в одном ассембли с собой же но не смердженным(отдельный длл)?
и что будет если хренота №1 с этой либой встретится с хренотой №2 с тем же кодом и тем же неймспейсом?
как такие вещи вообще решаются? и надо ли
А ты проведи эксперимент. Сделай простые dll-ки по типу тех, что в твоем вопросе описаны и попробуй их объединить. Потом пацанам расскажешь, что получилось.
Хз. Может демогстрация неявного каста и возможность присвоения экземпляра дочернего класса переменной базового. Больше код ничего не демонстрирует
Можно ли вывести "автоматом" на консоль все имеющиеся переменные?
var variablesClass = new VariablesClass();
var allPublicFields = variablesClass .GetType(). GetFields(BindingFlags.Public | BindingFlags.Instance);
Как-то так.
>There is no argument given that corresponds to the required formal parameter 'classname' of 'Program.Warrior.Warrior(string, string, string, string, string)'
<Grid >
<Grid.RowDefinitions>
<RowDefinition Height="20"/>
<RowDefinition Height="20/>
<RowDefinition Height="*" MinHeight="150"/>
<RowDefinition Height="20"/>
</Grid.RowDefinitions>
</Grid>
Одна из строк имеет адаптивную высоту с ограничением минимума = 150.
Как ограничить основное окно, чтобы оно не сжималось меньше, чем так сказать, результирующий минимум грида с учетом всех строк?
А зачем создавать файл? MemoryStream для кого придумали?
>Как подобное принято интегрировать в основной код?
с высказыванием нехороших слов о авторе.
Это ведь не пхп/питоны всякие где можно вот так в продакшене забирать с гитхаба. Тут компилить нужно и с этим часто проблемы.
Самое очевидное, это при событии окна SizeChanged, чекать все ячейки грида. Это я и так знаю, я думал есть что-то более вменяемое.
зачем. Если ты знаешь минимальную высоту таблицы то можно выставить лимит окна и ничего не чекать.
Я не могу знать. Некоторые ячейки могут поменять свойства в процессе, поэтому я не могу где-то единожды вычислить значение. При этом расчеты в риалтайме при SizeChanged слишком затратны, если ячеек будет 100500.
А еще в некоторых ячейках стоит сплиттер, к примеру. У таких ячеек MinHeight предназначен для сплиттера, а сами ячейки не реагируют на изменение габаритов окна. Я не могу просто циклом пройтись по всем ячейкам и взять оттуда MinHeight.
А вручную указывать, мол, "здесь возьми MinHeight, а здесь ActualHeight" — это какой-то бред.
вообще не понимаю причем тут ячейки. Есть размер таблицы, можно следить за его SizeChanged, можно за SizeChanged окна - одинаково будет. Лучше за SizeChanged таблицы и выставлять MinHeight окна
я в ахуе, запустил этот же пример,но чуть позже - уже ничего не работает АХАХХАХАХААХАХХХАХААХ
Твое как-то и есть сериализация. Ничего в этом плохого
Другое дело что есть море универсальных, где за универсальность платишь размером сообщения или скоростью десереализации
И форматов очень много: текстовые xml/json (+сжатие), разные бинарные: cbor, messagepack, can n proto, bjson, protobuffers....
Затратность штука "придется замерять"
Но если не нужно суперхайперфоманс то общих решений хватает с головой
Выбор из них это уже холивары
Никак. Они определяются по контексту
Цвет в одном файле
<Color x:Key="MyBaseColor">#FF00FF00</Color>
Цвет в другом файле должен получить данные из MyBaseColor
<Color x:Key="MyLocalColor" />
Можно, конечно, во втором файле создать кисть, которая бы ссылалась на цвет в первом файле, но беда этих темплейтов в том, что кистям и прочим параметрам нельзя ограничить область видимости. И при выборе кисти, в каком нибудь окне свойств студии, вываливается список из миллиарда кистей, собранных по всем темплейтам и контролам.
Разве нет никакой инкапсуляции в XAML? Это уже второй вопрос.
In the software industry PHP is used first and foremost for small projects, because it can easily lead developers into writing code that is bad, disorganized and hard to maintain, making it inconvenient for more substantial projects. This subject is also debatable, but it is commonly accepted that, because of its antiquated concepts and origins it is built on and because of various evolutionary reasons, PHP is a language that tends towards low-quality programming, writing bad code and creating hard to maintain software. PHP is a procedural language in concept and although it supports the paradigms of modern object-oriented programming, most PHP programmers write procedurally. PHP is known as the language of "code monkeys" in the software engineering profession, because most PHP programmers write terrifyingly low-quality code. Because of the tendency to write low-quality, badly structured and badly organized programming code, the entire concept of the PHP language and platform is considered wrong and serious companies (like Microsoft, Google, SAP, Oracle and their partners) avoid it. Due to this reason, if you want to become a serious software engineer, start with C# or Java and avoid PHP (as much as possible).
A programmer’s productivity under pure C is many times lower compared to their productivity under modern general-purpose programming languages like C# and Java. A variant of C is used among Apple / iPhone developers, but not because it is a good language, but because there is no decent alternative. Most Apple-oriented programmers do not like Objective-C, but they have no choice in writing in something else. In 2014 Apple promoted their new language Swift, which is of higher level and aims to replace Objective-C for the iOS platform.
C++ is good when you have to program applications that require very close work with the hardware or that have special performance requirements (like 3D games). For all other purposes (like Web applications development or business software) C++ is inadequate. We do not advise you to pursue it, if you are starting with programming just now. One reason it is still being studied in some schools and universities is hereditary, because these institutions are very conservative. For example, the International Olympiad in Informatics (IOI) continues to promote C++ as the only language permitted to use at programming contests, although C++ is rarely used in the industry. If you don’t believe this, look through some job search site and count the percentage of job advertisements with C++.
The C++ language lost its popularity mainly because of the inability to quickly write quality software with it. In order to write high-quality software in C++, you have to be an incredibly smart and experienced programmer, whereas the same is not strictly required for C# and Java. Learning C++ takes much more time and very few programmers know it really well. The productivity of C++ programmers is many times lower than C#’s and that is why C++ is losing ground. Because of all these reasons, the C++ language is slowly fading away and therefore we do not advise you to learn it.
In the software industry PHP is used first and foremost for small projects, because it can easily lead developers into writing code that is bad, disorganized and hard to maintain, making it inconvenient for more substantial projects. This subject is also debatable, but it is commonly accepted that, because of its antiquated concepts and origins it is built on and because of various evolutionary reasons, PHP is a language that tends towards low-quality programming, writing bad code and creating hard to maintain software. PHP is a procedural language in concept and although it supports the paradigms of modern object-oriented programming, most PHP programmers write procedurally. PHP is known as the language of "code monkeys" in the software engineering profession, because most PHP programmers write terrifyingly low-quality code. Because of the tendency to write low-quality, badly structured and badly organized programming code, the entire concept of the PHP language and platform is considered wrong and serious companies (like Microsoft, Google, SAP, Oracle and their partners) avoid it. Due to this reason, if you want to become a serious software engineer, start with C# or Java and avoid PHP (as much as possible).
A programmer’s productivity under pure C is many times lower compared to their productivity under modern general-purpose programming languages like C# and Java. A variant of C is used among Apple / iPhone developers, but not because it is a good language, but because there is no decent alternative. Most Apple-oriented programmers do not like Objective-C, but they have no choice in writing in something else. In 2014 Apple promoted their new language Swift, which is of higher level and aims to replace Objective-C for the iOS platform.
C++ is good when you have to program applications that require very close work with the hardware or that have special performance requirements (like 3D games). For all other purposes (like Web applications development or business software) C++ is inadequate. We do not advise you to pursue it, if you are starting with programming just now. One reason it is still being studied in some schools and universities is hereditary, because these institutions are very conservative. For example, the International Olympiad in Informatics (IOI) continues to promote C++ as the only language permitted to use at programming contests, although C++ is rarely used in the industry. If you don’t believe this, look through some job search site and count the percentage of job advertisements with C++.
The C++ language lost its popularity mainly because of the inability to quickly write quality software with it. In order to write high-quality software in C++, you have to be an incredibly smart and experienced programmer, whereas the same is not strictly required for C# and Java. Learning C++ takes much more time and very few programmers know it really well. The productivity of C++ programmers is many times lower than C#’s and that is why C++ is losing ground. Because of all these reasons, the C++ language is slowly fading away and therefore we do not advise you to learn it.
Какая же ебанина... Либо я чего-то не знаю.
Вот есть практика, что перед стилями выводится список цветов\кистей, чтобы каждый раз не лазить по стилям. Любой стиль в MDSN так представлен.
Допустим в одном словаре ресурсов у меня стоит цвет
<Color x:Key="Background">#FF00FF00</Color>
Тут я подгружаю другой словарь ресурсов, у которого есть цвет с таким же ключом
<Color x:Key="Background">#00000000</Color>
Одно переопределяет другое.
И как быть? Переименовывать один из цветов? А затем шатать ВЕСЬ стиль, чтобы исправить все ссылки по этому ключу? А завтра появится еще один стиль и давай поновой.
Неужели нет способа как-то ограничить область видимости кистей? Может есть какой-то контейнер, в который можно сапизнуть все кисти?.
Как git сабмодуль.
Тогда у тебя в основном проекте и контроль будет из какой ветки тянуть версию библиотеки, так и пользователи сами у себя смогут впилить ветку с нужными фичами и переключаться на нее.
Так что учи git submodule.
дык в этом и есть смысл - можно переопределить лишь часть, остальное унаследуется.
И ты подгружаешь, а значит переопределяешь одни значения перегруженными из подгруженного стиля.
Если ты не хочешь их переопределять - тогда хули они делают в стиле что переопределяет дефолтный
Ты можешь переопределить обратно - создать стиль на основе подгруженного, который вернет плохие места назад, но вообще "ну а как ты хотел" - идет поиск ближайшего стиля по дереву и первым встречается твой перегруженный.
давай имена стилям, наследуй, в общем СТРАДАЙ.
В остальном ...ну да в WPF с этим неудобно сделали.
Но не потому что можно переопределить, а потому что херово как раз с наследованием. Его нужно задавать явно.
Объясни тогда, какова практика работы?
Допустим, Вася Пупкин сделал стиль для кнопки (пикрил 1).
Он вывел две кисти для удобного редактирования стиля. После присоединения этого словаря стилей, кисти с ключами "Button.Background" и "Button.Outline" становятся общедоступными.
Второй сотрудник — Костя Синичкин, увидев эти кисти, решает забиндить их к каким-то другим элементам (они же в едином стиле). А через неделю заходит босс и говорит, что в нашем меню добавляется новая кнопка - СУПЕР КНОПКА!, не простая, а с совершенно новым стилем, и наш уважаемый третий сотрудник Петя Клюшкин, уже подготовил под это дело словарь ресурсов (пикрил 2).
Петя Клюшкин, как и Вася Пупкин тоже вывел две кисти с ключами "Button.Background" и "Button.Outline". И что же произошло? Все, что делал Костя Синичкин к херам переопределилось. Костя Синичкин ругает Васю Пупкина, что то поменял стиль, а тот утверждает, что этого не делал.
Что Пете Клюшкину теперь делать? Переименовывать все совпадающие ключи, о совпадениях которых студия тебе не расскажет? Ты вообще в другом отделе. Ты не можешь просто переименовать ключи, ты должен перелопатить весь стиль.
ЭТО ПИЗДЕЦ. Я не знаю как донести важность инкапсуляции. Даже в одиночном проекте я могу через месяц забыть, что под каким-то ключом уже есть стиль и не понимать шо вообще произошло.
Допустим я создал класс на основе словаря
public class BrushDictionary : Dictionary<string, SolidColorBrush> { }
Затем в ресурсах объявил класс и заполнил кистями.
<ResourceDictionary
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
<local:BrushDictionary x:Key="MyBrushes">
<SolidColorBrush x:Key="COLOR_NAME1" Color="#FFF4F513"/>
<SolidColorBrush x:Key="COLOR_NAME2" Color="#FFF313F5"/>
</local:BrushDictionary>
</ResourceDictionary>
А как теперь взять кисть? Пробовал:
Background="{DynamicResource ResourceKey=MyBrushes[COLOR_NAME2].Item}"
Ошибку не выводит, но выглядит как Null. При StaticResource мгновенно ругается, что не может найти ресурс с таким ключом.
Хз.
Ты как то пытаешься усидеть на всех стульях
И глобальный словарь чтобы кто угодно мог перегружать
И хочешь запретить перегружать
Словари это как бы глобально
ОСОБАЯ кнопка и ГЛОБАЛЬНОСТЬ вместе не живут
Непонятно как в 2к22 не иметь мультиселект для тривью. Вроде даже в WinForm была галочка.
впф заброшен очень давно. там дохера косяков которые никто не чинит
и не делает нужных вещей вида диалога выбора файла
я сейчас скрыл их в абстракт классе и наследую от него но все равно получается слишком дохуя
может быть имеет смысл выделить все настройки в отдельный класс-настройку?
ну такие стили позволяют в ресурсах переопределить кисть допустим.
И в ресуре задается тема всего приложения.
Почему вдруг твоя особая кнопка должна менять общую тему приложения. Пусть для нее будет свой стиль где все и будет вшито. Зачем для этого делать свой словарь кистей? чтобы поменять если что их? ну так поменяешь сам стиль какая разница то.
Хз как иначе. при интеграции словарей они же мержатся и в итоге работаешь с одним большим словарем и никак не сделать разделение если ключи совпадают.
Ну группируй настройки. Далее проблемы только хранения чтобы можно было хранить эту структуру....ну где ты там ее хранишь.
Посмотри на appsetings.json в том же асп.нет - там же иерархия которую можно читать и прямо по строкам или же забиндить на граф объектов (будет аналог десериализации из жсон, только без конвертеров)
группировать в смысле в объект, так?
у меня они все (сейчас 10, я потом еще хочу дополнительные добавлять для большего контроля) вот как на пике под копирку
>Почему вдруг твоя особая кнопка должна менять общую тему приложения.
Потому что у них совпадают ключи? Может ты стиль вытащил из пыльного чулана и непонятно как ты в будущем в приложении хочешь назвать базовые стили.
Я просто не понимаю как столько лет существует впф и ни у кого нет на эту тему вопросов. Может есть какой-то способ. Допустим я хочу хранить все свои кисти в Dictionary >>500900 , меня и такой подход более чем устроит, но чет не получается оттуда вытащить.
ты неправильно ставишь вопрос
сначала ты решаешь как будешь хранить, раз уж ты хочешь не только читать как вот в асп.нетах всяких. Ты хочешь редактировать и сохранять. А значит должен выбрать как ты это будешь делать
А потом уже смотреть что может предложить тебе выбранная система конфигурации.
система хранения такая - из настроек собирается xml, упаковывается в файл на диске а потом при нужде разворачивается.
ну если не вдумываться что ты можешь
1 ты можешь создать общий стиль на который ссылаться через BaseOn и там наплодить в ресурсах кучу кистей
2 ты можешь просто сделать свой класс MyDynamicResource который есть MarkupExtension и он тебе достанет откуда нужно. А стандартный DynamicResource ищет просто по ключу и про твой словарь знать не знает
3 по идее можно юзать тупо биндинг. Есть объект, у него данные - ну так просто биндинг - уж он то в отличие от Static/DynamicResource ищет как тебе нужно.
Правда тут нужно будет искать по имени, а оно ж может быть хер знает где определено. (хотя можно и по типу поискать)
У тебя ридонди конфиг
Нафиг тебе хмл
Да и даже если он - он тоже десереализуется в граф классов
И всё же вопрос был про систему работы с конфигом
Из стандартных в старом дотнете какая то на хмл основанная
Можно читать и писать
А в вебе там новомодный конфиг. Он только на чтение и собирает в себя разные форматы
Но если только читать то абсолютно изи сделать хоть свое
Да даже если хранить - оно легко
Велик не значит плохо работает
Это просто значит что левый человек сразу не будет знать где что в коде
>Нафиг тебе хмл
система сериализации в конкретно моем случае принимает только хмл. это не моя система если что и лезть внутрь и чето там менять я не собираюсь. сказано хмл значит хмл.
я вообще не про конфиги с вебами вопрос задавал, а как правильно организовать работу с раздувшимся от переменных классом.
твой вопрос вообще изначально не очень понятен. Хз что значит асбтракт класс. Есть класс работы с конфигом. Это может быть класс "дай значение такого то ключа" или тупо граф DTO объектов.
И твое "очень много" я трактовал как "у меня 100000 полей в 1 классе"
да, я хреново вопрос поставил
полностью выложить слишком много кода выходит в экран не влезет, но я что-то такое вот делаю примерно
я хочу завернуть все проперти с полями которые используют потомки ClassBase в отдельный класс и хотел узнать как это лучше всего сделать и может быть есть какой-нибудь паттерн на эту тему
Бесплатная замануха, а потом плати!
может у тебя проф версия стоит? я один раз так тоже лоханулся, пришлось перекачивать
Сказали залогиниуться и пропадёт. Пришлось аккаунт делать в мелкософте. Но это всё равно не бесплатный софт получается, а подписка бесплатная на неопределенный период и непонятно что если я хочу на оффлайн компе аутировать
.
Добавлять через асинк. Чекай как делают прогрессбар.
Решил я, значит, хоть как-то изолировать стили. Создал юзерконтрол, содержащий TreeView, и чтобы стилем для дерева не засирать все приложение, добавил стиль не в <Application.Resources/>, а в <UserControl.Resources/>.
И затем я беру и сей юзерконтрол добавляю в окно. И что бы вы думали? ... Не найден стиль. При этом юзер контрол этот стиль видит, а родитель — нет.
Как только я добавляю стиль в глобальные ресурсы — все норм.
Ну а чего ты ожидал? Естественно родитель не видит стиль контента.
Добавляй в глобалку.
@
Ну а чего ты ожидал? Естественно стили будут перегружены, ведь у тебя все в глобалке.
Хз, я несколько лет юзал комьюнити и лицензия не слетала. Сам мелкософтовский акк существует уже лет 5, на протяжении которого ставились студии.
Проверь тип лицензии, ну мб у тебя какой-то конфликт с "поломанной" версией.
Единственное что один вложен в ControlTemplate другого.
Я не могу запихнуть внутрь контрола грид, потому что это не будет гридом по сути.
Да всё нормально с xaml. Это везение если можно wpf кодить
И не всем же удается кодить именно вебапи
Вали с работы и дай посидеть на твоем месте тем кому повезло меньше
А ты вот умный значит найдешь себе изи
А шо если мне плагины делать нужно? Или как говорится, не стоит прогибаться под задачи, однажды они прогнутся под нас?
Алсо, основное отличие студенческой работы от реальной состоит в том, что в студенческой сначала выбирают технологию, а под нее придумывают задачу.
>>501759
>регистрация должна быть в разных классах
Так она в разных.
1. Я создал UserControl, в нем сделал депенденси проперти ButtonHeight
2. Я создал класс MyClass, наследующий TreeviewItem (ну мне нужна, типа, коллекция итемов внутри итема), в этом классе тоже создал депенденси проперти ButtonHeight.
3. Затем определяю стиль моего класса MyClass, где в Template пихаю UserControl.
И вот на этой стадии ругается на мой класс MyClass, мол, братан а уже зарегистрировано свойство с именем ButtonHeight.
Или может есть какой-то способ как "вытянуть" свойство UserControl наружу? Ну к примеру пикрил. Я в темплейт добавил юзерконтрол "MyUserControl", у которого есть свойство "ButtonHeight". Такого свойства в TreeViewItem нет. Как мне его сделать доступным снаружи? Я очевидно начинаю колхозить свой класс с дублирующими именами свойств.
На Grid.Row не смотри.
Показывать нужно как ты свойства создаешь
А вообще я не понимаю какой огород ты городишь что Controltemplate зачем то меняешь
Да еще наследника задаешь да с высотой кнопки
Ты что вообще сделать пытаешься?
>Да всё нормально с xaml
Не-не. Хуйня это полная. Попытка перетащить уебищную фронтовую парадигму в нормальный язык. Даже долбаные js фреймворки вроде react'а в разы удобнее (хотя тоже дерьмом пахнут местами - и имя этому дерьму js)
>И не всем же удается кодить именно вебапи
Учись, так чтобы быть более востребованным как узконаправленный специалист. С пришествием .net Core вообще лафа наступила и профессия .net фулстека потихоньку отмирает, в пользу чистого бэк-энда.
>Вали с работы и дай посидеть на твоем месте тем кому повезло меньше
Вот только два месяца как поменял работу. Можешь занимать.
>Или как говорится, не стоит прогибаться под задачи, однажды они прогнутся под нас?
А то. Дело бизнеса "Бабки платить и завалити ебало". А что с этими бабками делать мы сами решим.
Да
А "не поломанные" вообще не ставятся
>Попытка перетащить уебищную фронтовую парадигму в нормальный язы
Ты бредишь. Шарп изначально десктопный язык. Винформс там изначально. И даже асп вебформсы шли по тому же пути.
И нет реакт не лучше а просто другое.
Если не нужно перегружать шаблон контрола то норм в wpf. Перегрузка просто сильно многословная.
Нужен TreeView. Но TreeViewItem должен быть со своим стилем, что-то на подобие слоя в фотошопе.
Меня простыня стиля как-то подзаебала, да и вообще работать в полуслепую. Я решил участок с Template вынести в UserControl, чтобы был свой xaml дизайнер и удобно было редактировать (пикрил).
А вот как этот юзерконтрол превратить теперь в TreeViewItem — хз.
я реально не пынямаю, напишите плиз код
при условии, что после Abu может быть, что угодно
Для папок
DirectoryInfo(@"C:\Users\Abu\Downloads").Name;
Для файлов (с расширением)
fileName = Path.GetFileName (path)
Для файлов (без расширения)
fileName = Path.GetFileNameWithoutExtension (path)
Substring()
>Шарп изначально десктопный язык
Десктоп и веб-хуйня несколько разные вещи. Инзачально там winforms был если чо. Ну и так-то это не часть языка если что, а отдельный фреймворк.
язык и фреймворк это разные вещи. сравнил мягкое с теплым.
та же "веб-хуйня" это тоже фреймворк
Так что направленность языка определяется стандартной поставкой, то есть что рантайм дает "искаропки". И для дотнета это были винформс (а потом WPF).
Так что веб-направленность после появления кроссплатформы пришла в дотнет (не нужно стало моно), а десктоп направленность была всегда.
ты опять даешь недостаточно информации. По скрину где тут вообще TreeView?
то что юзаешь дизайнер - похвально. Я помню проекты, где ВСЕ делалось через стили перегрузкой темплате. вот где реально дичь.
А так - ну опять же хз твоя проблема. У разных ItemControl при биндинге идет поиск DataTemplate и он сам обернет их в TreeViewItem/ListViewItem и как оно там еще.
Так я и писал изначально, что WPF и его xaml - это подтягивание веб-хуйни с ее разметкой, стилями и т.д. в десктоп.
Может не так в изначальном посте выразился, но как-то так.
>WPF и его xaml - это подтягивание веб-хуйни с ее разметкой, стилями
вот только это бред
html+css в дотнетах использовалась еще 20 лет назад в первых студиях даже были такие окна и можно было делать гуи.
xaml != html. xaml это хмл...ну да и все. хтмл описывает разметку, а хамл описывает граф объектов. То есть вот как в винформс там генерится код описывающий объекты гуи, так вот хамл это такое же описание, только в виде хамл.
хтмл не является описанием кода никоим образа. он просто описывает структуру
и стили же вообще сделаны иначе.
да и как бы гуи с разметкой и стилями - СЛИШКОМ ОБЩЕЕ понятие чтобы приписывать "из веб пришло".
>По скрину где тут вообще TreeView?
Это TreeViewItem, а TreeView - пикрил 1.
>то что юзаешь дизайнер - похвально.
Только вот мне придется щас скопировать оттуда разметку и вставлять прямо в темплейт стиля.
>У разных ItemControl при биндинге идет поиск DataTemplate и он сам обернет их в TreeViewItem/ListViewItem и как оно там еще.
Ну смотри. Вот на пикрил 2 я беру и между открывающим и закрывающим тэгом "TreeViewItem" пихаю еще три итема и они воспринимаются как ItemCollection (в темплейте за это отвечает ItemsPresenter).
Должен отметить, что в моем классе никак не указан ItemsPresenter и я не знаю как его обозначить. Соответственно разметка не знает куда пихать контент.
Если я попробую завернуть итемы в свой класс SubtoolItem, то идет попытка заменить контент самого SubtoolItem т.e. ContentPresenter. Собственно и вылезает ошибка:
XDG0040Свойство "Content" может быть задано только один раз.
брр. давай начнем с
"почему ты не используешь HierarchicalDataTemplate, а городишь свой огород?"
тогда может смогу понять что ты пытаешься сделать
Если я чет не использую, значит я об этом не знаю. Пошел гуглить.
Я знаю про TreeView, который юзает TreeViewItems, вот и пытаюсь своё как-то приклеить туда.
Сейчас нахожусь в польше, и хочу вкатиться в .net
Года 3-4 назад я проходил йоба курсы, обучающие работать с бэкендом (на .net asp core, тогда только только core вышел, кстати). Меня в конце них даже на работу пригласили, но я был не совершеннолетним, так что мне сказали приходите позже.
У меня есть пару пет проэктов на гите.
Но я совсем забыл сишарп, и не следил за обновлениями языка.
Я думаю по 5 часов 5 дней в неделю в течении следующих 2 месяцев изучать язык по роадмапу. Это будет где-то 200 часов минимум изучения.
Хватит мне столько времени, чтобы вкатиться на джуна, с условием что я имею представление как устоен интернет, и что я знаю алгоритмы, ооп, систему контроля версий, бд, тесты ну и по мелочи ещё? Опять же, мне по-сути надо только повторить всё
Какие книжки почитать? Джеффри Рихтера читал.
Ещё вопрос, какой стек выбрать? Я думаю либо backend, либо full-stack, но не знаю что используют для фронта. Я когда-то только ангуляр и чистый жс пробовал и всё. Посоветуйте что-нибудь.
прямое использование Item из хамл нужно только тогда, когда не используется биндинг списка. То есть при MVVM подходе крайне редко, почти никогда.
Вся структура данных определяется графом вьюмоделей, а гуи через биндинг все это рисует используя систему связывания вьюмодели с DataTempate (в котором твой UserControl)
TreeView не исключение.
>прямое использование Item из хамл нужно только тогда, когда не используется биндинг списка.
Да я и не собирался — чисто для теста, и заметил, что у TreeViewItem содержимое работает иначе.
Приложение, если что, консольное
какие еще контроллеры.
всякие классы выделяются чтобы изолировать изменения в них
и оперировать более высокими абстракциями.
Ну а степень всего этого зависит от нужд.
Я просто щас видос смотрю, тут чел делает приложение на чистой архетиктуре, вот там у него есть контроллеры. Использует web api
1168x464, 0:20
Танака Сан, кажется вам есть что сказать. Не молчите.
Аналога чего? Мы ж не телепаты, чтобы понимать, что твоя приложуха делать должна.
Во вторых тебе нужно хорошо осознать сначала, в принципе, понятие абстракции. Атомарно, так сказать. На уровне хотя бы классов, объектов их свойств и т.д. А потом уже лезть в более высокие уровни типа слоев или архитектуры.
А как вот тут
https://metanit.com/sharp/wpf/14.8.php
Идет привязка к свойству Nodes? У меня отказывается видеть свойства основного класса.
Пробовал в инициализации ставить DataContext = this
приложуха - телеграм бот. Принимает запросы от пользователя и выдаёт ифну из бд. Приложуха уже написана и более-менее работает. Но там каша из классов и тд. Хотел всё по полочкам разложить попутно изучая чистую архитектуру.
щас я тебе поясню на ёжиках.
вот допустим у тебя простая задача - взять нисколько файлов, читать построчно из каждого файла по строке, потом фильтровать, соединять как то и писать в выходной файл.
ну берешь ты метод Main и в нем открываешь File.OpenRead кладешь стримы в список, открываешь выходной файл File.OpenWrite - и в цикле начинаешь обходить этот список (кстати лучше очередь но не суть)
фильтровать и писать в вывод
задача выполнена? выполнена. Но выглядит как то "грязно"
И ты дербанишь на статические методы чтения, фильтрации и сохранения.
Стало чище, но "классы, где мои классы?"
Хз что такое классы, потому делаешь класс типа class App где в конструктор передаешь пути к файлам и метод Run() делаешь
Но разве "чистый код" такой???? Оопшно, но как то не SOLID-но.
Начинаем "чистокодить"
- выделяем класс LineReader, которыйй будет выдавать линии
- класс LineWriter, что инкапсулирует куда пишется вывод
- класс FilterStrategy чтобы определить как фильруется
- CombineStrategy чтобы определить стратегию комбинироания строк
Потом еще в голову "чистый код" стукнет и такой "а вдруг не из файлов читать"
и давай еще класс SourceReader вместо простого fileStream и вот уже LineReader работает с набором SourceReader
Ну и конечно LineReaderFactory и LineWriterFactory
Но понимаешь, что этого мало. Все как то жестко связано и ты рождаешь кучу интерфейсов
ILineReader/ILineWriter/IFilterStrategy/ICombineStrategy/SourceReader
подключаешь DI контейнер и регистрируешь все в нем.
И смотришь ты на эту гору кода (по сравнению с оригиналом) и задаешься вопросом
"а оно все нужно было то?"
А ответ....не так очевиден.
щас я тебе поясню на ёжиках.
вот допустим у тебя простая задача - взять нисколько файлов, читать построчно из каждого файла по строке, потом фильтровать, соединять как то и писать в выходной файл.
ну берешь ты метод Main и в нем открываешь File.OpenRead кладешь стримы в список, открываешь выходной файл File.OpenWrite - и в цикле начинаешь обходить этот список (кстати лучше очередь но не суть)
фильтровать и писать в вывод
задача выполнена? выполнена. Но выглядит как то "грязно"
И ты дербанишь на статические методы чтения, фильтрации и сохранения.
Стало чище, но "классы, где мои классы?"
Хз что такое классы, потому делаешь класс типа class App где в конструктор передаешь пути к файлам и метод Run() делаешь
Но разве "чистый код" такой???? Оопшно, но как то не SOLID-но.
Начинаем "чистокодить"
- выделяем класс LineReader, которыйй будет выдавать линии
- класс LineWriter, что инкапсулирует куда пишется вывод
- класс FilterStrategy чтобы определить как фильруется
- CombineStrategy чтобы определить стратегию комбинироания строк
Потом еще в голову "чистый код" стукнет и такой "а вдруг не из файлов читать"
и давай еще класс SourceReader вместо простого fileStream и вот уже LineReader работает с набором SourceReader
Ну и конечно LineReaderFactory и LineWriterFactory
Но понимаешь, что этого мало. Все как то жестко связано и ты рождаешь кучу интерфейсов
ILineReader/ILineWriter/IFilterStrategy/ICombineStrategy/SourceReader
подключаешь DI контейнер и регистрируешь все в нем.
И смотришь ты на эту гору кода (по сравнению с оригиналом) и задаешься вопросом
"а оно все нужно было то?"
А ответ....не так очевиден.
Пизжу. с DataContext завелось.
Но непонятно почему работает только если я итем сорс привязываю дважды: к TreeView, и к HierarchicalDataTemplate.
Если привязать только к TreeView, то не появляются сабитемы.
Если привязать только к HierarchicalDataTemplate, то вообще ничего не видно.
TreeView биндятся корневые ноды
к HierarchicalDataTemplate биндятся вложенные ноды.
ведь дерево это список списков списков...
ну а как иначе. ведь нода может не иметь вложенных нод
ты должен понимать что
у TreeView и у HierarchicalDataTemplate РАЗНЫЙ DataContext
у TreeView DataContext это твой список во вьюмоделе или где там у тебя, а у HierarchicalDataTemplate контекстом является сама нода и ItemsSource у HierarchicalDataTemplate это для биндинга ВЛОЖЕННЫХ узлов
то есть на твоем пике первый итемс будет искать во вьюмодели, а второй будет искать внутри забинденной ноды
Надо еще погуглить. Ща очень поверхностно все делаю.
И еще назревает вопрос:
Вот у меня есть мой юзерконтрол со свойствами, который будет выполнять роль итема.
А для списка данных я сделал отдельный класс с похожими свойствами. И список заполняю именно экземплярами этого класса.
Иначе получается, что мне придется дважды инициализировать грузный юзерконтрол — один для списка данных, другой для дерева. Или как-то можно экземпляр биндить, а не создавать новый?
Экземпляр создается всегда. Только тебя это волновать не должно - ты создавай вьюмодели себе, а оно само все.
Также ты можешь предоставить разные шаблоны для разных типов данных.
>то есть на твоем пике первый итемс будет искать во вьюмодели, а второй будет искать внутри забинденной ноды
Да, щас кликнул по "перейти к источнику" ItemsSource у HierarchicalDataTemplate и он перекинул меня к ItemsSource у TreeView.
Смущает только предупреждение в TreeView, что не найден контекст данных.
предупреждения в дизайн-тайм норма если ты не юзаешь d:DataContext
но даже с ним до сих пор херь со списками
а перекинуло тебя потому что у тебя не заполнен DataType, а оно до сих пор хреново все резолвится по спискам
>Также ты можешь предоставить разные шаблоны для разных типов данных.
О, кстати. А я все голову ломал как мне отделить папки от итемов.
как и везде в списковых контролах
ItemSource по типу итема ищет DataTemplate DataType="{x:Type"
если найдет то рисует иначе ToString()
так работают списковые контролы и ContentControl
там никаких проблем
ты просто создаешь 2 класса Folder и Item
у фолдера есть вложенный список.
На стороне хамл в ресурсы кладешь
<HierarchicalDataTemplate DataType = "{x:Type Folder}"
ItemsSource = "{Binding Path=Items}">
<TextBlock Text="{Binding Path=Name}"/>
</HierarchicalDataTemplate>
<HierarchicalDataTemplate DataType = "{x:Type Item}">
<Image/>
</HierarchicalDataTemplate>
В рантайме делаешь правильное дерево вьюмоделей и оно само все сбиндит
Джавист, ну-ка парашу чистить, уходи с треда
Допустим, у меня есть юзер контрол с какой-то там xaml-разметкой.
И мне нужен еще один, где меняется только 5% от первого. Не существует никакого наследования в плане xaml?
Спасибо, суть понял. В моем случае лучше оставить как есть, потому что кода не очень много но много , функционал не большой. Но мне энивей хочется натянуть это на нормальную архетиктуру. К тому же самому хочется пощупать, посмотреть как оно все там работает. Плюс если будут смотреть этот проект, явно будет плюсом, что есть какая-нибудь архетиктура.
Ну дербань по SOLID и паттернам. Чисто для форматирования мозга допустимо же.
В классе есть структура. Когда я методом в классе дергаю структуру - она не дергается. Меняю struct на class - дергается.
Я так понимаю что struct внутри класса не thread-safe (или дергать его не thread-safe???), а класс внутри класса - thread-safe.
Объясните плиз почему так?
Код.
Кажись я заразил тред словом "дергать".
В каком смысле дергать? Перезаписывать свойства структуры? нИпалучится. Свойство структуры дает тебе не ссылку, а значение.
Понел, спасибо, чёт ступил.
А можно тогда реальных примеров, когда надо использовать структуру вместо класса?
Вот пишет микрософт когда выбрать структуру вместо класса:
It logically represents a single value, similar to primitive types (integer, double, and so on).
It has an instance size smaller than 16 bytes.
It is immutable.
It will not have to be boxed frequently.
А можно примеры такого? Особенно про иммутабельность и >represent single value интересно
про single value перегнули палку. Это типа "если вы пилите ValueObject, то подумайте может структуру сделать, а не класс" Пример хотя бы DateTime
с иммутабельностью все просто - мутабельные структуры зло ибо компилятор активно создает защитные копии при попытке изменения полей структуры и мозг можно сломать отлавливая эти моменты.
Ну а выбирать структуру нужно когда хочешь поменьше грузить GC и от структуры есть польза и не так уж много вреда
В котлине типы стираются как и в джаве, потому что это косяк JVM
>А можно тогда реальных примеров, когда надо использовать структуру вместо класса?
Я с различиями столкнулся до степени, когда "иного пути нет" — это когда работал с отрисовкой графики, где у тебя в риалтайме идут расчеты координат по всяким формулам. Даже стандартные функции из библиотек для расчета каких нибудь периметров, дистанций или точек внутри фигуры, принимают ТОЛЬКО структуры. Причем примитивные т.е. вместо структуры Point(x,y), функция принимает отдельно x, и отдельно y.
А дело в том, что создание экземпляра класса это очень дорогостоящая операция. Может занимать в 10-100 раз больше времени, чем создание структуры. Она практически незаметна в так сказать, спокойном режиме (потому и возникают у тебя вопросы). Но если ты захочешь, к примеру, переместить фигуру прямоугольника по холсту и в каждом кадре попытаешься создать новый экземпляр класса прямоугольника с новыми координатами, то у тебя будет такой жидкий ФПС, что охуеешь. А если прямоугольников в кадре сотни?
Можешь сам потестить, посмотри тутор про бенчмарки и замеры скорости. Есть такой BenchmarkDotNet, и тутор от SimpleCode. Затем создай функцию, принимающую классы и принимающую структуры, после чего замерь память и время.
Короче, структуры нужны для краткосрочных событий, повторяющихся с высокой частотой. Тогда ты используешь структуры по принципу "быстро создал, быстро забыл". Необязательно это графика, это может быть цикл с перебором больших объемов данных. Вот внутри цикла ты можешь без зазрения совести создавать структуры.
Есть нюанс со стрингами, которые притворяются структурами, будучи классами, но это другая история.
Классы нужны в долгосрочной или среднесрочной перспективе — ты его один раз создал и дальше пользуешься. Экземпляры классов создают до цикла, и уже в теле цикла их обрабатывают (это не правило, но я так делаю). А то может случиться так, что сборщик мусора будет подчищать неиспользуемые экземпляры классов медленнее, чем создаются новые экземпляры — тогда твоя программа мало того, что захлебнется при расчетах, так еще и количество занимаемой памяти взлетит в небеса.
>А можно тогда реальных примеров, когда надо использовать структуру вместо класса?
Я с различиями столкнулся до степени, когда "иного пути нет" — это когда работал с отрисовкой графики, где у тебя в риалтайме идут расчеты координат по всяким формулам. Даже стандартные функции из библиотек для расчета каких нибудь периметров, дистанций или точек внутри фигуры, принимают ТОЛЬКО структуры. Причем примитивные т.е. вместо структуры Point(x,y), функция принимает отдельно x, и отдельно y.
А дело в том, что создание экземпляра класса это очень дорогостоящая операция. Может занимать в 10-100 раз больше времени, чем создание структуры. Она практически незаметна в так сказать, спокойном режиме (потому и возникают у тебя вопросы). Но если ты захочешь, к примеру, переместить фигуру прямоугольника по холсту и в каждом кадре попытаешься создать новый экземпляр класса прямоугольника с новыми координатами, то у тебя будет такой жидкий ФПС, что охуеешь. А если прямоугольников в кадре сотни?
Можешь сам потестить, посмотри тутор про бенчмарки и замеры скорости. Есть такой BenchmarkDotNet, и тутор от SimpleCode. Затем создай функцию, принимающую классы и принимающую структуры, после чего замерь память и время.
Короче, структуры нужны для краткосрочных событий, повторяющихся с высокой частотой. Тогда ты используешь структуры по принципу "быстро создал, быстро забыл". Необязательно это графика, это может быть цикл с перебором больших объемов данных. Вот внутри цикла ты можешь без зазрения совести создавать структуры.
Есть нюанс со стрингами, которые притворяются структурами, будучи классами, но это другая история.
Классы нужны в долгосрочной или среднесрочной перспективе — ты его один раз создал и дальше пользуешься. Экземпляры классов создают до цикла, и уже в теле цикла их обрабатывают (это не правило, но я так делаю). А то может случиться так, что сборщик мусора будет подчищать неиспользуемые экземпляры классов медленнее, чем создаются новые экземпляры — тогда твоя программа мало того, что захлебнется при расчетах, так еще и количество занимаемой памяти взлетит в небеса.
HierarchicalDataTemplate работает только с TreeView, а у него в стиле прописана стрелка, сигнализирующая вложенный контент (типа как пикрил). Короче, без переопределения стиля не обойтись.
да. с одной стороны WPF позволяет переопределить эти компоненты через стиль
с другой - рукожопные дефолтные шаблоны требуют полного переопределения шаблона
что не сильно сложно ибо 90% копипаст с ориг шаблона или с SO, но пипец портянка получается.
>HierarchicalDataTemplate работает только с TreeView,
не совсем верно. это TreeView работает с HierarchicalDataTemplate
ты можешь спокойно запилить свой контрол работающий с чем угодно существующим.
В классе данных, к которому привязывается TreeView, установил событие, срабатывающее при изменении свойств в этом классе: PropertyChangedEventHandler, наследуемый от INotifyPropertyChanged
Теперь при изменении свойств данных, автоматом меняются и свойства итемов TreeView.
А как сделать наоборот? На пикрил, у меня при раскрытии TreeViewItem срабатывает триггер, который меняет текст в свойстве Header. Визуально я вижу изменения, но событие PropertyChanged не срабатывает — данные остаются неизменными.
Как быть-то?
Хм... если я меня свойство изнутри итема, не через триггер, то все срабатывает.
Как будто сеттер триггера перезаписывает биндинг.
Ну на скрине ты никак не сообщаешь классу данных (который datacontext) о событии isexpanded, а всего лишь напрямую меняешь хидер
Для решения можешь погуглить вариант биндинга к isexpanded
Либо внутри теститем отслеживать ischecked и прокидывать датаконтексту
>а всего лишь напрямую меняешь хидер
Ну так у меня в итеме (пикрил) текст тоже двухсторонне привязан к свойству Header. При смене текста должен произойти пинок проперти Header, который связан с проперти datacontext.
Вот если я через событие поменяю Header, то datacontext это улавливает.
На комп нормально поставилось а на ноут не хочет.
Может это быть изза васянской версии винды? Я уже не знаю что ему блядь надо в чем причина.
Поставил покачто ВС код с .Нет СДК и пердолингом.
Вопрос в том, как мне вытащить событие, происходящее внутри итема. Меня, к примеру интересует событие изменения текста.
Даже если datacontext задетектит изменение свойства, ему не доступен экземпляр TreeView.
как вытащить как вытащить?
как и везде - биндинги к свойствам, или просто событие и там обратиться к вьюмодели.
Лично я вот такую портянку "кто на кого биндится без 0.5 не понять" не делаю. У меня есть вьюмодель и она является точкой схождения биндингов и в общем то хранилищем визуальной модели.
И вот так бы IsExpanded я прокинул минуя вьюмодеь только если бы ну реально нечего было делать ей во вьюмодели (я все таки различаю состояние (что рисовать) и сам вид (как рисовать))
Но в твоем случае тебе определенно это знание нужно - так не усложняй схему биндингов.
>ему не доступен экземпляр TreeView.
и нах не нужен вьюмодели твой тривью. Вьюмодель ничего не знает про вид. вообще НИЧЕГО. Она не знает кто на нее смотрит, кто ее использует и для чего (отображение). Ну логически она (вернее программист который ее пишет) конечно знает, ведь это вид просит ее "дай мне правильный стейт", но никакой другой связи нет.
>В джаве тоже ничего нет
толсто
>она помедленнее будет несмотря на все попытки оптимизаций
Последние годы основные оптимизации делались в GC. Ну и тут еще у жабы оверхед по памяти будет побольше из-за исторических ошибок
1. Бля хамл ниработаеть((((
2. TreeView ))))))))0
3. Бля вижл студия ниробить (((
Больше ничего нет, можно не читать.
Ты че такой злой? Рассказывай кто тебя обидел
Танака Сан, о каком опоганивании треда ты говоришь?
Это хорошо показывает, чем на работе занимаются шарписты на самом деле. Древний проприетарный дотнет фреймворк, формочки на винформах и WTF, программирование мышкой, засилье винды, а неткор+ - это мем вкатышей, поиграться и никогда не использовать в проде. Убийца жабы, говорите?))) Ну-ну.
Хули мне твоим неткором делать, блять, долбоеб? У меня плагин программы, существующей онли под шиндовс и мак (где без лицензи разраба ты хуй простой). Иди посмейся над создателем программы, клоун — он же точно тупее тебя.
Сидит тут деревенский дурачок, надувающий джаву через соломинку, и чет мне советует, нихуя не зная о ситуации. Вышлите претензии в письменном виде, милорд-обрыган, я обязательно их прочитаю своей жопой после того, как хорошенько просрусь.
> Древний проприетарный дотнет фреймворк
ты о чем вообще. WPF он на последнем дотнет 6 юзается
давно уже во всем переехали на последний дотнет
Задачи: подписание, расшифровка, проверка, ГОСТ 34.11-2012.
Насчёт BouncyCastle хз, но GostCryptography - тупо драйвер-обёртка для криптопровайдера и сама работать не будет без установленного КриптоПро CSP или аналога (а он платный и стоит немало). Более того, такие СКЗИ требует сертификации ФСБ, и, если это важно, как в случае с ЭЦП для госорганов, любая проверка контролирующими органами будет иметь серьёзные юридические последствия. Если BouncyCastle умеет сама в ГОСТ-2012, лучше эту либу юзать только для тестовых утилит и не более.
Хуй знает, у всех по разному получается поставить. Последнии дни совсем непонятно.
>Насчёт BouncyCastle хз, но GostCryptography - тупо драйвер-обёртка для криптопровайдера
Ну мне по факту это и нужно. Просто самому ручки у advapi32.dll и crypt32.dll дергать это тот еще геморрой. Я написал несколько методов, оно вроде работает, но в рот имел я все это барахло с указателями и unmanaged хренью поддерживать в будущем, хочется что-то готовое.
>без установленного КриптоПро CSP или аналога (а он платный и стоит немало). Более того, такие СКЗИ требует сертификации ФСБ, и, если это важно, как в случае с ЭЦП для госорганов, любая проверка контролирующими органами будет иметь серьёзные юридические последствия.
Ну это понятно, но это не моя проблема, а заказчика. В том смысле что стульев у него по факту всего два КриптоПро и ВипНет. По факту будет КриптоПро.
>Если BouncyCastle умеет сама в ГОСТ-2012, лучше эту либу юзать только для тестовых утилит и не более.
Они обе судя по всему умеют. Вернее GostCryptography изначально, а у BouncyCastle есть форк с их поддержкой.
Судя по тому, что я вычитал BouncyCastle более популярен и инфы по нему больше. Но честно говоря я в сорцы заглянул и там пиздец какой-то внутри, какая-то каша в которой хер разберешься. В GostCryptography все на первый взгляд более аккуратно и понятно выглядит и поддерживаемо будет проще если что. Но по нему и инфы меньше.
Допустим есть список путей, вроде этого
"Project\FolderA1\FolderB1\Item1"
"Project\FolderA2\FolderB1\Item2"
"Project\FolderA2\FolderB2\Item3"
далее выстраивается дерево
Project
. . .FolderA1
. . . . . . FolderB1
. . . . . . . . . . Item1
. . .FolderA2
. . . . . . FolderB1
. . . . . . . . . . Item2
. . . . . . FolderB2
. . . . . . . . . . Item3
Мне не важны индексы папок, меня интересуют только индексы итемов. Естественно, дерево не ридонли, а предполагается миграция итемов.
У меня идея — добавить свойство Index в каждую ноду, потому что индекс нужен мне в 100% операций.
Но если будет операция удаления\перемещения, то вызывается событие для всех остальных нод, и те прибавляют или убавляют свой собственный индекс на нужное значение.
>>503415
Я сейчас смотрю MVVM и чет там какие-то маня-ситуации.
>Вьюмодель ничего не знает про вид.
Охуительные истории. А теперь задача:
При выборе ноды в тривью, моя программа должна послать другой программе состояние этой ноды и ее индекс (ну потому что другая программа только это и понимает). И как же эта нода расскажет про свой индекс не зная где она находится? На деревне у дедушки?
Наверно предполагается, что вся остальная часть приложения работает в тех же условиях, иначе пук-среньк.
>Я сейчас смотрю MVVM и чет там какие-то маня-ситуации.
нет там никаких маня ситуаций. вьюмодель держит состояние вида, а вид синхронно рисует это все как ему хочется
>И как же эта нода расскажет про свой индекс не зная где она находится? На деревне у дедушки?
она знает где она находится. на уровне вьюмоделей у тебя тоже дерево. Представь что ты пишешь в консоли - ты построил дерево и вот это оно и есть - и ты можешь получить в нем индекс, что то менять и так далее.. Просто это дерево НИЧЕГО НЕ ЗНАЕТ (ему не нужно) про тривью ибо это просто дерево из вложенных объектов. НО вот тривью про это дерево знает и может его отрисовать.
В любой момент ты можешь выбросить WPF и заменить гуи на консоль. Так конечно нет смысла делать, но вот тестирование другое дело. Точно так же работает и мультиплафторма - вьюмодель одна, а под каждую платформу вид рисует по своему. И это можно ибо вьюмодель ни про кого не знает.
И да, хочется пощупать именно популярное и современное, поэтому варианты которыми пользуются 1.5 анонимуса не предлагайте.
>который только jQuery тыкал. React или Vue?
нужно взять фронтендера, а самому писать бэкенд.
фронтендера не кормить и иногда бить плеткой
и все будет тип-топ
Скажу только за реакт, т.к. только его знаю.
Он в принципе простой, если знаешь js, то на его освоение уйдет от 1 до 3 недель.
Но у него есть две разновидности (ну или парадигмы). Одна - это когда компоненты пишутся на классах, другая на хуках. Первая чем-то ближе к ООП и для бэкэндера будет попроще в освоении, но считается уже года 3...4 устаревшей и так уже не пишут. Вторая чем-то ближе к функциональщине и считается более актуальной. Но менее удобная и понятная на мой взгляд.
Я бы для себя наверное сейчас вью бы взял, т.к. думаю что с учетом знаний освоил бы его быстро. Но если бы это было с перспективой на профессию, то реакт в связке с .net чаще встречается. С другой стороны я в фулстеки возвращаться не собираюсь, так что точно попробовал бы вью.
Кажется я начинаю въезжать в логику MVVM паттерна. Ну по сути вьюмодель это как прилинкованный файл к xaml во всяких окнах, юзерконтролах и страницах, только живет своей жизнью.
верно до наоборот.
Есть разные способы работы с гуи. все они частично имеют общие подходы, так что опишу отличительные части.
1 типа как хтмл или хмл в андроид классик - описывается разметка и далее кодом все это дело собирается во что то. Классика - ловим событие и в хендлере допустим меняем цвет чего то напрямую. ну поверх этого делают еще биндинги в некоторых местах.
2 как в винформс контролы и их расположени описывается кодом (пусть даже этот код генерит дизайнер) сам гуи и далее код работает с этими контролами напрямую. Поверх этого тоже есть биндинг частично. А так - событие, хендлер, что то меняем в контролах.
3 WPF+MVVM - тут уже биндинг прикручен не сбоку, а является центральной частью и есть средства чтобы вюмодели просто содержали "что рисовать", а мощная система биндингов позволит декларативно связать с гуи, который знает "как рисовать". гуи и вьюмодели могут быть зеркальным отражением, а могут полностью отличаться. Главное от вьюмоделей - удобно представить данные для отображения и держать в себе состояние.
Тут уже обычные события редкие гости - их заменяют биндинги и реакцию на событие тоже заменяют биндинги.
4 MVU - жетпак композе, комбине у эпл, возможно мауи. Тут гуи описывается кодом и есть стейты (особые переменные). Если они меняются то происходит перевыполнение кода описывающего гуи. Конечно из-за оптимизаций меняется тот же контрол, который подписан на изменение стейта и это логически похоже на MVVM + контрол (который типа изменяет себя при изменении того, на что забинден), но
а) там нет биндингов - гуи следит только за стейтами и обновляется при их изменении. То есть можно образно считать что заново выполняется весь код описыващий гуи.
б) из за того, что это код, то типа код напрямую работает в гуи. вместо Visibility.Collapsed для кнопки юзается if(условие) { наша кнопка }. Если условие стал false то кнопка исчезнет при следующем проходе.
Ну тут в комбайне и в мауи не сильно это заметно ибо там классы используются с требованием конструктора, метода типа рендер (ну а чем это не контрол то обычный а? в чем раличие???), а вот в жетпак композ это функции и получается буквально код (от чего я ссу кипятком от такой гибкости, но считаю что WPF не хуже - просто в нем другой подход)
Так что вьюмодели это как типа толстые контроллеры в ASP.NET которые и команды принимают и говорят что рисовать, а видом является фронтенд, который все это рисует.
за счет центральной системы биндингов MVVM просто лютый вин. Ну правда там начинаются свои проблемы в виде "god viewmodel" но все же все равно удобнее обычного подхода как в винформс. И при некотором умении даже сверху можно прикрутить Lifetime (хоть WPF к этому подходит как винт вертолета подводной лодке)
верно до наоборот.
Есть разные способы работы с гуи. все они частично имеют общие подходы, так что опишу отличительные части.
1 типа как хтмл или хмл в андроид классик - описывается разметка и далее кодом все это дело собирается во что то. Классика - ловим событие и в хендлере допустим меняем цвет чего то напрямую. ну поверх этого делают еще биндинги в некоторых местах.
2 как в винформс контролы и их расположени описывается кодом (пусть даже этот код генерит дизайнер) сам гуи и далее код работает с этими контролами напрямую. Поверх этого тоже есть биндинг частично. А так - событие, хендлер, что то меняем в контролах.
3 WPF+MVVM - тут уже биндинг прикручен не сбоку, а является центральной частью и есть средства чтобы вюмодели просто содержали "что рисовать", а мощная система биндингов позволит декларативно связать с гуи, который знает "как рисовать". гуи и вьюмодели могут быть зеркальным отражением, а могут полностью отличаться. Главное от вьюмоделей - удобно представить данные для отображения и держать в себе состояние.
Тут уже обычные события редкие гости - их заменяют биндинги и реакцию на событие тоже заменяют биндинги.
4 MVU - жетпак композе, комбине у эпл, возможно мауи. Тут гуи описывается кодом и есть стейты (особые переменные). Если они меняются то происходит перевыполнение кода описывающего гуи. Конечно из-за оптимизаций меняется тот же контрол, который подписан на изменение стейта и это логически похоже на MVVM + контрол (который типа изменяет себя при изменении того, на что забинден), но
а) там нет биндингов - гуи следит только за стейтами и обновляется при их изменении. То есть можно образно считать что заново выполняется весь код описыващий гуи.
б) из за того, что это код, то типа код напрямую работает в гуи. вместо Visibility.Collapsed для кнопки юзается if(условие) { наша кнопка }. Если условие стал false то кнопка исчезнет при следующем проходе.
Ну тут в комбайне и в мауи не сильно это заметно ибо там классы используются с требованием конструктора, метода типа рендер (ну а чем это не контрол то обычный а? в чем раличие???), а вот в жетпак композ это функции и получается буквально код (от чего я ссу кипятком от такой гибкости, но считаю что WPF не хуже - просто в нем другой подход)
Так что вьюмодели это как типа толстые контроллеры в ASP.NET которые и команды принимают и говорят что рисовать, а видом является фронтенд, который все это рисует.
за счет центральной системы биндингов MVVM просто лютый вин. Ну правда там начинаются свои проблемы в виде "god viewmodel" но все же все равно удобнее обычного подхода как в винформс. И при некотором умении даже сверху можно прикрутить Lifetime (хоть WPF к этому подходит как винт вертолета подводной лодке)
В чем разнице в скорости между хранимкой, запросом ADO и Entity?
Насколько я понимаю дело в плане исполнения, для хранимки план исполнения строится после первого исползьования. АДО и Энтити всякий раз присылают новый запрос, приходится сторить новый план исполнения, так? Еще какая-то пежня есть с конвертацией данных. Короче тема мутная, под рукой никого нет кто объяснит, а найти никого не могу.
Теперь когда "поджигаю" произвольный тайл должны инвокнуться все на него подписанные. Я хочу чтоб инвокались (и загорались) как на пик2, а по факту происходит как на пик3. сорри за хуевую картинку
Как правильно подписаться и вызывать, чтоб было как на втором примере?
Выглядит как обход дерева/графа в ширину, но тогда мне надо будет строить граф от "поджигаемого" элемента и подписываться на окружающие тайлы проходя по нему?
От Vue все файлы на компьютере могут превратиться в сердечки
Нет здесь однозначно надо использовать неткор+ , а лучше джаву.
512x156, 0:13
К примеру, в моем итеме я хочу текст отображать в сокращенном варианте, если для него нет места по ширине, т.е. середина или конец заменяется на многоточие (видеорил).
Как это вписывается в концепцию MVVM?
Во-первых мне нужно событие изменения ширины итема.
Во-вторых я не могу железно привязать текст итема напрямую, нужно какое-то промежуточное свойство, которое биндится с вьюмоделью. А вот событие берет эти данные из свойства, обрабатывает стринг и вставляет в лейбл или текстблок.
Но везде пишут, что в связанном с xaml файле ничего кроме инициализации быть не должно, если хотите придерживаться трушности паттерна.
И ведь это малая часть вещей, которые меняют свой внешний вид в зависимости от состояния других элементов (при этом никак не влияют на содержимое данных).
Нахуя во вьиев модели что-то менять? Через интерактьён подписаться на событие изменения сизе чангед и всё там делаешь обработку
Вроде все воксельные сетки делятся на строки и чанки.
Проще залезть в соседнюю строку с тем же индексом, что и "источник горения" и быть уверенным, что это его сосед.
А так у тебя получается отдельный список для каждого вокселя. И так любая симуляция требует огромной оперативы. Если ты думал, что изобрел быструю симуляцию, то наверно нобелевку не получишь (в этом году).
повторюсь еще раз
в MVVM
VM (вьюмодели) отвечают за то ЧТО отображать
а V(вид) за КАК отображать.
то есть вьюмодель содержит этот "очень длинный текст итема" (что отображать), а сжатием при ресайзе заведует вид (как отображать)
и вьюмодель про многоточие ничего не знает. и про размер окна не знает. и про размер контрола не знает.
и то вьюмодель содержит не сам текст прямо (ну тут зависит), ведь не нужно забывать про локализацию
Да я понимаю. Просто потрясает радикализм делающих туторы по MVVM. Нет бы сказать "не пишите внутри вью логику того, что может изменить данные модели".
>не пишите внутри вью логику того, что может изменить данные модели".
это вообще про другое
вид может менять состояние вьюмодели
но типа не гуд ему лезть в саму модель напрямую, а типа гуд чтобы вьюмодель была между ними прослойкой.
> Проще залезть в соседнюю строку с тем же индексом, что и "источник горения" и быть уверенным, что это его сосед.
Но тогда условной "передачей горения" будет заниматься класс, в котором тайлы травы добавлены, например класс Поле это у меня, а я хотел, чтоб тайлы горели без участия поля, оно только заполняет/отрисовывает, поэтому хотел на ивентах
> А так у тебя получается отдельный список для каждого вокселя. И так любая симуляция требует огромной оперативы. Если ты думал, что изобрел быструю симуляцию, то наверно нобелевку не получишь (в этом году).
Я понимаю, при этом ещё циклические связи возникают при привязке получается (другое дело что горящие тайлы уже не инвокают повторно и как бы цикл рвется), но здесь как раз и вопрос в том, чтобы красиво горение шло (то есть сначала в ширину инвокалось, а уже потом в глубину), а не вглубь по одной цепочке.
Получается мне типа надо смотреть в сторону асинхронных событий или Parallel.Invoke?
Ты бы загуглил алгоритм, есть целые статьи по этому поводу.
https://www.researchgate.net/publication/355450242_Adaptive_Forest_Fire_Spread_Simulation_Algorithm_Based_on_Cellular_Automata
А еще я у одного японца на стриме по гудини заметил такой ресурс
https://citeseerx.ist.psu.edu
Там можно найти научные пдф-ки на разную тематику. Т.е. он забил что-то вроде "dune simulation" и нашел пару статей, которые описывали алгоритм симуляции песка дюны.
Я там мигом просмотрел твою тему и там рассматривается расчеты на основе ветра или плотности растительности. Ну и собсно посмотреть гудини, там тоже не раз встречал реализацию алгоритма распространения огня или ржавчины, правда не по пикселям, а по вертексам мэша, но какая разница?
А по поводу твоей организации, я не совсем понял как у тебя. Как я себе представляю:
Есть один или два слоя. Первый — земля (если она тоже бывает разных видов), второй — объект (трава, дерево, камень). Это два двумерных массива.
Что мешает обратиться к верхнему слою объектов и проверить если по указанному индексу объект со свойством горючести, а если есть, то "поджечь"?
Нужно просто установить порядок проверки "соседей" для твоего красивого горения. Ходишь по кругу своей точки и поджигаешь (мб с каким нибудь шансом горения — для неоднородности), потом повторяешь цикл проверки соседей по кругу для всех уже загоревшихся объектов.
Я уверен есть алгоритм прохода по кругу сетки двумерного массива (может даже в этих статьях)
Я помню как делал моды для 7 days to die, там у каждого блока был набор свойств: материал, ориентация в пространстве, прочность, состояние и т.д. Причем когда чанк вокселей записывался в файл, то все эти свойства соединялись в одно число т.е. от 0 до 100 записывались ID материала, затем каждая сотня отвечала за ориентацию. Каждая тысяча — прочность.
Все складывалось вместе и получалось что-то вроде такого: 10345. Битовым сдвигом разбивается и собирается.
> чтоб тайлы горели без участия поля, оно только заполняет/отрисовывает, поэтому хотел на ивентах
А что мешает создать второй класс и не нагружать этим поле?
У тебя поле вообще ничего не должно делать. Поле это просто массив объектов. GUI читает этот массив и визуализирует, на этом его фунциклирование заканчивается.
А вот другие процессы должны это массив "поле" как-то редактировать: один генерирует среду, другой симулирует горение, третий укладывает снег. Отдельный вопрос как они это будут делать одновременно, но то что задачи должны быть делегированы — это факт.
Спасибо, не так гуглил запросы про горение
> Нужно просто установить порядок проверки "соседей" для твоего красивого горения. Ходишь по кругу своей точки и поджигаешь (мб с каким нибудь шансом горения — для неоднородности), потом повторяешь цикл проверки соседей по кругу для всех уже загоревшихся объектов.
Это я делал, это работает, но хочется-то на ивентах, или на а ля агентах, чтоб тайлы травы общались друг с другом, а не с внешним слоем (или хотя бы чтоб через спец прослойку общались, но чтоб она их напрямую не контролировала)!
>>504889
> А вот другие процессы должны это массив "поле" как-то редактировать: один генерирует среду, другой симулирует горение, третий укладывает снег. Отдельный вопрос как они это будут делать одновременно, но то что задачи должны быть делегированы — это факт.
Ну так примерно и есть сейчас, просто из "поля" пока недовынес части, а так трава и поле это разные классы, да
Использовать только циклы.
А я могу.
Извини, чувак. Но "математика в программировании не нужна". А для решения этой задачи нужны базовые математические знания. Так что решения у задачи нет.
Я понял как разделить эти числа но до сих пор не могу решить как все эти числа между собой сравнить.
>чтоб тайлы травы общались друг с другом, а не с внешним слоем
Технически ты можешь запихнуть траву в отдельную коллекцию ObservableCollection, у которой есть событие на изменение.
Но давай проверим, что эффективнее. Допустим у тебя 100 спрайтов травы.
Если кто-то пукнет в "чатик" травы, то вся сотня всполошится и начнет проверять себя. Установить лимит на дальность проверки связей я не знаю как.
А если ты будешь ближайших чекать, то проверяться будут собственно только ближайшие. Конечно же чем больше огонь будет расти, тем больше циклов проверки и под конец будет проверяться всё и не только трава, но и Аллах, но это можно оптимизировать жизнью горения и удалять из списка те спрайты, которые горят давно — таким образом у тебя всегда будет n-количество горящих объектов.
У тебя должен быть отдельный буфер горящей травы, и отдельный процесс поджигающий и проверяющий время жизни травы. Может быть буфер в виде стака(очереди) Stack<T>, чтобы можно было легко добавлять новые объекты и удалять последние.
Ля че нашел.
https://triplebyte.com/blog/how-fire-spreads-mathematical-models-and-simulators
Исходник?
https://github.com/scipython/scipython-maths/tree/master/forest_fire
Там даже ветер можно настроить
Написано же, использовать только циклы. А с if любой дурак сможет.
Еще и переменные использует — вообще атас.
Спасибо большое :3
Ну бля, объебался, бывает.
Внутри EF лежит АДО кста (ну по крайней мере раньше лежал, хз что там с кором)
План выполнения тебе еще и поднасрать может кста(2), но да, аргумент
Как по нажатию кнопки запустить долгий, очень долгий процесс в другом потоке, да так, чтобы тот поток мог гуй обновлять?
В том, что если внутри обработчика я стартую другой поток/асинхронную хуйню/что угодно, то ничего не происходит. У меня просто глохнет UI
При асинке, если просто тупо чет пихать в проперти гуи, то ничего не произойдет. Нужно сихронизирваться с помощью инвока.
При любом обращении из асинхронной функции к ГУИ используешь инвок. Но лучше сразу собрать все "пожелания" в кучу и обратиться за один раз.
App.Current.Dispatcher.Invoke(async () =>
{
// здесь любой код, который относится в сторону ГУИ
//к примеру
MainWindow.Width = 300;
MainWindow.Title= "Pososi u traktorista";
});
Если асинхронная функция работает успешно, то фризиться интерфейс не должен. Он может не получать или передавать данные из-за отсутствия инвока, но точно не фризиться.
Они же в 10 строчек пишутся, или нужны какие-то требования по сбалансированности?
A Find, Remove, Traverse негры напишут?
Конечно можно скопировать из интернета, но так-то можно и list самому написать.
Ок, ещё 40 строчек.
Деревья нужны относительно редко, поэтому универсальных деревьев и нет из коробки (только XDocument, TreeView и подобные, между ними мало общего), к тому же, большинство применений деревьев настолько специфичное, что обычно пишут свои реализации на каждый случай или берут сторонние либы.
В любом случае, есть SortedSet, SortedDictionary и SortedList, они реализованы через деревья, но хуёво то, что там нельзя непосредственно работать с узлами, как следствие, обход в глубину или удаление поддеревьев там не применить.
если запускать из GUI то там для синхронизации нужны доп шаги - это Dispatcher/контекст синхронизации (можно даже хелперы слепить)
Если это MVVM то там биндинги, то там уже используется контекст синхронизации и доп усилия не нужны, но обновлять вьюмодели в многопотоке не гуд (не стоит правда путать многопоток и асинхронность)
Логично для кнопки, когда в ControlTemplate пихают прямоугольник, а в DataTemplate какой нибудть текстовый блок, подключенный ко вьюмоедли. В финале мы имеем текстовый блок в прямоугольнике.
Все это выглядит логично, если элемент раздроблен по частям. А что если я не могу вот так вот дробить? Что если у меня единый элемент? Допустим это тексбокс — текст в прямоугольнике. Я поясню в чем затык. Дело в том, что триггеры, типа выбора элемента или наведения курсора работают только в области ControlTemplate.
И куда пихать мой единственный текстовый бокс, если я хочу триггерами поменять его рамку, но и рыбку съесть и данные текста привязать ко вьюмодели?
Хм, есть DataTrigger.
Но как же все щас через жопу. Упростил в одном месте, сложности вылезли боком.
Там всё сложно, ибо с MVVM я не разобрался. Но биндинги есть. Внутри потока должно обновляться свойство, отвечающее за вывод
>но обновлять вьюмодели в многопотоке не гуд
А как быть тогда? Вот я (другой анон) сделал возможность подавлять вызов события изменения содержимого ObservableCollection.
Если происходят какие-то комплексные изменения коллекции данных, то я стопорю уведомитель и начинаю шатать коллекцию — удалять и добавлять, а затем снова включаю.
Если нужно что-то типа прогрессбара, то достаточно просто перезаписывать нужное свойство вьюмодели и ГУИ автоматом обновляется не стопорится.
>>505283
>ибо с MVVM я не разобрался
Давай вместе разбираться. Я уже начинаю въезжать, кроме нюансов — там шаг в сторону и расстрел.
Я себе отдельный проект для тестов вывел, только он на VB. Хотел плавно перейти на шарп, но совмещать несколько проектов на разных языках не очень удобно — линк проектов работает только в одну сторону..
Пробовал апельсиновый, но производительность на мой взгляд падает. С другой стороны тебе это не важно.
ControlTemplate описывает шаблон самого контрола. У него даже есть спец биндинг TemplateBinding
DataTemplate описывает шаблон контента (тот самый ItemPresenter, который мы используем в ControlTemplate) - и подходящий DataTemplate ищется по типу контента или же устанавливается дефолтный.
Через httpclient отправляю запрос, данные получаю, всё ок. А как правильно сделать "автоматическую" отправку запросов, то есть каждые полчаса ?
>А как быть тогда?
С чем быть?
Сами биндинги которые идут на GUI они сохраняют в себе контекст синхронизации и защищены от "нельзя контрол вызывать в другом потоке".
Но ты можешь быть внутри твоих вюмоделей или контролов подписан на изменение допустим ObservableCollection - и эта подписка будет вызвана в другом потоке.
Если ты говнокодишь и запускаешь что то долгое асинхронное внутри вьюмодели и оно внутри и работает (сами все шаги во вьюмодели) то тебе нужна синхронизация
а) если там асинки то await по дефолту (если не юзаешь Fody.ConfigureAwait) вернет в UI поток
б) а если контекст потерян, то для синхронизации тебе нужен Dispatcher. но тут уже велосипедят кто во что горазд
- Кто то юзает Dispatcher прокидывая его в вьюмодель - можно сказать "фуу", но он то лежит в System.Windows.Threading, а не в Presntation
- другие используют класс хелпер типа UIDispacther который имеет статические методы и инициализируется нужным Dispatcher на старте приложения. Ну чтобы не запутаться в эти диспатчерах. Есть в некоторых фреймворках, ну и вот https://learn.microsoft.com/ru-ru/archive/msdn-magazine/2014/april/mvvm-multithreading-and-dispatching-in-mvvm-applications
- странный вариант вида
uiFactory = new TaskFactory(TaskScheduler.FromCurrentSynchronizationContext());
в конструкторе вьюмодели. и далее синхронизация вида
uiFactory.StartNew( () => эта задача работает в UI потоке );
Если же ты говнокодишь иначе, то есть "а хули вьюмодель сама делает всю работу? ее дело только держать состояние визуальной части, а...пусть сервисы работают" и значит вьюмодель тоньше и вызывает сервис "сделай че то там", и ты обычно передаешь
1 IMyOperationContext какой нибудь - где ты можешь влепить класс обертку над твоей вьюмоделью, что будет менять твою вьюмодель и заботиться о потоках (или если лень говнокодить больше меры, то сама вьюмодель может реализовывать этот кастомный интерфейс (говнокодим как хотим) только не забывай про потоки. Вот через нее долгая операция может менять гуи (через изменения вьюмоделей конечно)
2 IProgress - он может быть как частью IMyOperationContext, так и отдельно - и его дефолтная реализация захватывает контекст синхронизации при создании, то есть дополнительных шагов не требует
3 CancellationToken для отмены операции же. Чтобы на гуи жмакнул и можно отменить.
>А как быть тогда?
С чем быть?
Сами биндинги которые идут на GUI они сохраняют в себе контекст синхронизации и защищены от "нельзя контрол вызывать в другом потоке".
Но ты можешь быть внутри твоих вюмоделей или контролов подписан на изменение допустим ObservableCollection - и эта подписка будет вызвана в другом потоке.
Если ты говнокодишь и запускаешь что то долгое асинхронное внутри вьюмодели и оно внутри и работает (сами все шаги во вьюмодели) то тебе нужна синхронизация
а) если там асинки то await по дефолту (если не юзаешь Fody.ConfigureAwait) вернет в UI поток
б) а если контекст потерян, то для синхронизации тебе нужен Dispatcher. но тут уже велосипедят кто во что горазд
- Кто то юзает Dispatcher прокидывая его в вьюмодель - можно сказать "фуу", но он то лежит в System.Windows.Threading, а не в Presntation
- другие используют класс хелпер типа UIDispacther который имеет статические методы и инициализируется нужным Dispatcher на старте приложения. Ну чтобы не запутаться в эти диспатчерах. Есть в некоторых фреймворках, ну и вот https://learn.microsoft.com/ru-ru/archive/msdn-magazine/2014/april/mvvm-multithreading-and-dispatching-in-mvvm-applications
- странный вариант вида
uiFactory = new TaskFactory(TaskScheduler.FromCurrentSynchronizationContext());
в конструкторе вьюмодели. и далее синхронизация вида
uiFactory.StartNew( () => эта задача работает в UI потоке );
Если же ты говнокодишь иначе, то есть "а хули вьюмодель сама делает всю работу? ее дело только держать состояние визуальной части, а...пусть сервисы работают" и значит вьюмодель тоньше и вызывает сервис "сделай че то там", и ты обычно передаешь
1 IMyOperationContext какой нибудь - где ты можешь влепить класс обертку над твоей вьюмоделью, что будет менять твою вьюмодель и заботиться о потоках (или если лень говнокодить больше меры, то сама вьюмодель может реализовывать этот кастомный интерфейс (говнокодим как хотим) только не забывай про потоки. Вот через нее долгая операция может менять гуи (через изменения вьюмоделей конечно)
2 IProgress - он может быть как частью IMyOperationContext, так и отдельно - и его дефолтная реализация захватывает контекст синхронизации при создании, то есть дополнительных шагов не требует
3 CancellationToken для отмены операции же. Чтобы на гуи жмакнул и можно отменить.
с MVVM все просто. Ты просто складываешь визуальное состояние из вьюмоделей, а гуи за счет биндингов сам отслеживает их изменение и подходящим способом отображает
в чем проблема?
Таймер не?
или таймер или запустить.
await Task.Delay(TimeSpan.From*, ct) //начальная задержка
while(!ct.IsCancellationRequested){
//отправляем
await Task.Delay(TimeSpan.FromMinutes(30), ct)
}
свойство OnBind требует Action<ComputeNode, ComputeNode>
тут же это свойство выставляется не напрямую на Action, а через лямбду, которая допускает, что Action может не быть в момент вызова с помощью ?.
Ну может оно там часто меняется на нулл или выставляется сильно поздно, а OnBind не переваривает нулл, поэтому и такое проксирование.
т.е. он таким образом пропускает все инвоки SInstance.ComputeControl.OnBind через себя?
спасибо
Небезосновательный намек понял.
а это все от того что вместо сурового нормально гуи делают пестроцветную хрень.
я хочу каждую проперти завернуть в класс со своим собственным эвентом, у него будет один подписчик, который будет иногда дергаться.
вот у меня пикрелейтед есть и таких по 6-7 штук на каждом объекте, объектов пока не знаю, например 20-30, а подписывать на эвенты я планирую UI, т.е. одновременно вызываться будет только один
можно ли сделать как-то иначе?
я юнитихолоп, не бейте сильно
тяжелая в чем?
в плане вызова это просто вызов метода через делегат (такого везде полно), то есть чуть медленнее прямого вызова
В плане удобства эвенты работы с ними конечно говно, но вот они такие вот в языке.
я скорее имел в иду память, там же есть какие-то аллокации?
или на таких объемах без разницы
если я правильно понимаю вот есть INotifyPropertyChanged, там только один эвент, но как он определяет что передать?
там самые обычные делегаты. вернее там multicast delegate, что эквивалентно иммутабельному списку обычных делегатов.
делегат это по совместительству описание сигнатуры вызываемого метода, потому он безусловно знает что передавать еще на этапе компиляции.
аллокации получишь если будешь постоянно подписываться/отписываться, ведь тогда будет рождаться новый multicast delegate на каждый такой чих
но это у тебя какой то дикий многопоток будет, а события и многопоток это как "жрать жидкое говно вилкой", то есть неудобно, но с и с ложкой лучше не станет.
Датабиндинг элементов UI работает с ObservableCollection, и при любом изменении коллекции автмоатически обновляются забинденные свойства. А знаешь как элемент узнает, что в коллекции было изменение? Внутри нее есть событие.
А теперь представь, что у тебя список или дерево с сотнями элементов, где каждый элемент подписан на сие событие. И это итпа нормально. Единственное что, если ты сам подписываешься, то не забудь отписаться, т.к. подписка — это хороший источник утечек памяти т.е. очиств переменную с классом, он не удалится и будет работать.
>>506097
спасибо, теперь более понятно
я решил отказаться от этого класса и все же посмотреть на eventargs
вот как на пике объект чисто с данными-проперти, его обновляю и на каждом изменении внешних проперти посылаю его вместе с eventargs и enum, а подписчик(и) будут брать этот enum и уже там раскидывать как надо
есть ли подводные камни?
помимо того как на другой стороне этот enum обрабатывать и не городить колоссальный свитч, я пока даже не представляю как за это браться. может забить и тупо обновлять вообще ВСЕ UI элементы через посланный объект в обработчике события? гулять так гулять
Во-первых уже есть специальный интерфейс INotifyPropertyChanged.
Там все уже сделано и не надо городить города, как у тебя.
А интерфейс вынудит тебя создать одно единственное событие, и один метод OnPropertyChanged вызывающий это событие.
В дальнейшем это событие работает для всех твоих свойств. Т.е. ты в своем свойстве CurveSamples, после всех своих делишек подставляешь ровно одну строчку OnPropertyChanged с именем своего свойства. Например:
OnPropertyChanged("CurveSamples") Можно даже имя не вставлять, если добавить атрибут CallerMemberName, который позволяет автоматом получить имя свойства или метода, вызывающего OnPropertyChanged.
И самое главное, что биндинги к UI автоматом работают с этим интерфейсом и сами подписываются на событие. Тебе достаточно только забиндиться к свойству, которое вызывает OnPropertyChanged. Ну и еще кое че подшаманить.
В целом, ты повторил основную идею INotifyPropertyChanged, только без списков пропертей (как ты собрался их обновлять в будущем? Это же жопа в плане обслуживания — тебе придется вручную вносить изменения каждый раз, когда какие0то свойства прибавились или убавились)
>>506104
> и не городить колоссальный свитч
вот меня, кстати, тоже интересует, а как WPF обрабатывает события INotifyPropertyChanged? Автоматом создает внутри свич на все биндинги?
Конечно, событие можно сформировать как угодно и передавать даже делегаты на исполняемый метод (или команды). Но по дефолту в EventArgs события OnPropertyChanged возвращается только стринговое имя свойства. Как биндинг знает что и чего?
Вот допустим у меня отдельным проектом идет словарь ресурсов со стилем. Рядом еще 5 проектов, которые мерджат этот словарь в свой стиль. Это что получается? Тупо xaml-конкатенация? В каждом проекте будет своя копия простыни присоединяемого ресурса?
Выглядит расточительно. Я уже пытаюсь не юзерконтрол делать, а отдельный проект под достаточно комплексные модули UI, но идут по пизде стили — их приходится подгружать отдельно.
просто пропертигеттер через рефлексию и далее этот геттер в словарик и всего делов.
Так, ща в главный аппликешин добавил словари и чому-то все остальные проекты не задали вопросов.
Почему хуйня-то? Под свои задачи блейзор самое оно, тем более для шарписта. А такие задачи в разных бизнесах могут возникать. Вон смотрел доклад какого-то чела с альфы, что ему пришлось внедрять какие-то штуки, и он выбрал блейзор. Все у него заработало. Расхваливал что майки не стали изощряться и просто повторили, типичный вебфреймворк, по структуре. То есть въехав в блейзор, будешь понимать как работают все прочие фрейморки на жиэсах.
А потом те же компоненты разора можно в формочках или впфе использовать, потому что блейзор гибрид и в этих десктопных окнах умеет жить. А значит тот же код можно использовать в абсолютно разных вещах. Это же охуенно по сути, надо только разобраться и научится понимать, где фулстак без js фреймворков невозможно реализовать, а где уже можно обойтись чистым дотнетом.
Как добавить C# в codeblocks?
Может срабатывает твоя функция один раз.
я же говорил что я юнитихолоп, в версии с которой я работаю нет биндингов и т.д. наш UI не знает про это если его не допиливать.
я бы с удовольствием воспользовался уже готовым решением, но информации по этой теме у нас практически нет, а то что есть какая-то шляпа
надо будет подробнее почитать про INotifyPropertyChanged и попытаться адаптировать
>>506251
да, мне нужна была деформация 3д модели по сплайну, это я уже насвинячил и уже было начал пилить версию которая будет вместо процессора использовать видеокарту, но окинул взглядом что за хуйню я нагородил и теперь хочу как нормальный человек сделать
>надо будет подробнее почитать про INotifyPropertyChanged и попытаться адаптировать
Да там все тоже самое, что и тебя. Просто шаблон интерфейса заставляет добавить событие и функцию для вызова события — всё. Ровно все то, что у тебя, только передается не индекс свойства, а его имя (да и то автоматически).
А при установке Visual Studio галочка на Unity скачивает Unity? То есть, если Unity уже установлено то можно её не ставить в Visual Studio?
а из имени на другом конце соответственно вытаскивается проперти и значение через какой-нибудь GetProperty.GetValue?
Угу
Можно так, а можно через сендер вытащить. В проперти нейм использовать как идентификатор.
Нет
Раньше - да.
Сейчас - скачивается unity hab, в котором нужно выбрать что тебе там скачать нужно.
Че меня триггерит.
Я не могу решить как правильно в плане архитектуры сделать.
Вот смотрите. 2 стула:
1. Делаем абстрактный TCP-сервер с интерфейсом как на прикриплейд. Дальше - от этого класса наследуемся и реализуем че нам там надо.
2. Делаем один TCP-сервер, в него передаем обработчик соединения, на которого положили то же самое что было бы в этом интерфейсе, но этот обработчик - передается снаружи. Соответственно - интерфейс у нас уже будет не INetworkServer, а IConnectionHandler.
Вот я блядь не знаю как лучше-то. Типа все во мне говорит - второе - лучше. Но потом шепот в ушко: Няша, наследование же не просто так придумали, чего ты его использовать не хочешь?
Не знаю короче. Че делать-то? Как быть?
Типа что я хочу получить-то?
Хочу что-то в духе:
var server = ServerBuilder()
.UseTcpTransport()
.AddTcpListener("0.0.0.0:8000")
.AddTcpListener("0.0.0.0:8001")
.AddExceptionHandler(e => Console.Error.WriteLine($"[ERROR] {ex}"))
.AddFilterFirst(x=>Console.WriteLine($"[{x.LocalEndPoint}] data rec {x.Input.Buffer.Length}"), y=>Console.WriteLine($"[{y.LocalEndPoint}] data snd {y.Out.Buffer.Length}"))
.Use<Mqtt>()
.Build();
await server.Run();
Как ты собираешься тестировать те классы, которые должны будут твой сервис потреблять?
Не скажу по твоей проблеме, но Божечки, какие же интуитивные лямбда-выражения в C#. В бейсике это просто жуть (как и реализация событий).
Хочешь сказать, что вся эта ебля с внедрением зависимостей была придумана тупо ради юнит-тестов?
Не только. Но это самый простой пример того зачем оно нужно.
Статический класс - это считай, глобальная переменная. Это сразу пиздос в плане многопточки, это сразу пиздос в плане: надо изменить поведение в одном месте, но не менять в других, это сразу пиздос в плане реальной разработки, потому что если ты меняешь статический класс - тебе нужно перетестировать буквально все места, где он используется.
Короче. Когда ты начнешь работать в реальной фирме, где делается реальный продукт, ты поймешь, насколько говняно самому писать статику. Еще сильнее ты это поймешь, когда у вас больше одного человека над одним проектом работает.
Сам разобрался, имя параметра должно было совпадать с именем поля.
public DirectoryNode(DirectoryInfo directoryInfo, DirectoryNode parent) : this(directoryInfo)
{
this.Parent = parent;
}
Меня интересует двоеточие после заголовка функции.
А, это типа перегрузка, но с выполнением кода основного конструктора. Равносильно
public DirectoryNode(DirectoryInfo directoryInfo, DirectoryNode parent)
{
this.New(directoryInfo);
this.Parent = parent;
}
У нас такой херни в бейсике нет.
return this.Directory == null ? string.Empty : this.Directory.Name;
Что вообще означают двоеточия в шарпе? Символ на все случаи жизни?
Писец, собрали все знаки. Ля как в бисике
Return If(Me.Directory Is Nothing, String.Empty, Me.Directory.Name)
Просто через запятую.
обзевабл коллекция в сама имеет событие внутри? Не будет двойного обновления?
Я такого не видел в других примерах кода. Там по дефолту все биндинги прекрасно обновлялись.
Так и это свойство тоже.
В итоге если я изменю итемы коллекции, то сначала произойдет событие в коллекции, а затем внешнее событие. Или одно переопределит другое?
ааа, понял.
Событие коллекции будет сообщать о внутренних изменениях.
Событие в свойстве будет сообщать об изменении самой коллекции.
У меня дефицит общения :3 Чмоки, сладкий.
https://stepik.org/course/114281/promo
если кто-то захочет, отпишитесь к посту оставлю телегу
Лол, просят за инфу, которая рассказана на первых 300 страницах asp.net в действии 45к. И ведь находятся дураки.
Да есть такое, но информация там годно подаваться должна, если бы хотя бы человек 10 набралось, можно было бы осилить
Дак что та инфа, если ее на практике не понятно как применять, мне как новичку например
во время инета подавай себе инфу как хочешь.
то есть можно остановиться на месте и ковырять пока не разберешься детально под 100 углами, чем идти дальше
и бесплатно
а тут ожидать волшебную таблетку...мде
>годно подаваться должна
Потому что дорого? Кек.
Там по структуре уроков видно, что темы можно взять из ютуба.
Покажи мне хоть один их тутор.
>то есть можно остановиться на месте и ковырять пока не разберешься детально под 100 углами
Люто двачую. Даже если прямо ответят на твои вопросы, тебе эта инфа будет пустым местом, пока ты 50 раз не исследуешь тему.
А с чего ты взял, что там тебе объяснят? Опять навалят маня-ситуаций, где их код работает идеально, но чуть в сторону и тупик.
Единственная причина — это заебать вопросами ментора и выбить из колеи курса. Дико горят, но так есть толк хотя бы. Всегда так делал, еще с института.
Алсо, Павел Шмачилин трехчасовые стримы ведет, по 20 стримов на тему. Можно весь отпуск нонстопом смотреть.
>>507483
Я 3 курса на степике прошел у этого автора, например по Linq ты такой информации собранной не найдешь нормально, на ютубе очень плохо эта тема освещена, много практических заданий. Тут вопрос в том, что ты получаешь собранную информацию и не надо понимать что в какой последовательности тебе изучать и тратить на это кучу времени. А по 50 раз исследовать и расширять полученную информацию лучше, чем какой-то набор статей разрозненный, ну 40 к я согласен за такую инфу платить бредово, но 4 - 7 к я за такую инфу бы отдал
У нас не найдется столько народу, чтобы платить по 5к. Это надо человек 10, в треде стольких нет.
Он на складчинах весит, но что-то движения особого там нет, ну скорее всего придется этот месяце по видеоуркам индуса идти, если вдруг кому нужен курс могу поделится по AspNet.6
но дело в том, что мозг устроен так, что он не понимает какую то часть и поэтому картина не складывается, все как то пипец сложно и связи не прослеживаются.
Как только этот кусочек понимается, то картина становится легкой и целостной.
И тут не проблема учителя - он видит картину по другому, для него она "да все там понятно", а ученик тупит и "не может уловить самую суть".
Будет ли плюсом что могу в angular и соответственно работать с данным с фронта, запросить что нибудь, отправить на бек и тд? Всякую фронтендную мишуру по типу html,css тоже умею.
namespace Std
{
class Program
{
static void Main(string[] args)
{
const double pi = 3.14;
double radius;
Console.WriteLine(pi);
radius = Convert.ToDouble(Console.Read());
Console.WriteLine(radius);
Console.WriteLine(radiusradiuspi);
}
}
}
Почему не работает???
>Дак что та инфа, если ее на практике не понятно как применять, мне как новичку например
На примере сраного интернет магазина-то, ну-ну.
>Единственная причина — это заебать вопросами ментора и выбить из колеи курса. Дико горят, но так есть толк хотя бы.
Вот этот дело говорит.
Кстати если про менторов говорить, может кто находил себе ментора платного, на youdo или freelance сайте, чтобы какую-то сложную или непонятную тему разобрать, поделитесь инфой
Ну если брать курсы, то в большинстве пишется интернет магазин, я вот слив нашел по WPF где пишется канбан доска с задачками, супер пупер приложение никто не пилит на учебных проектах, хотя было бы круто
Если что-то непонятно можешь спросить итт, или на so.
>пользователи никогда не скажут, что им не нравится цвет кнопки
Потому что у них не будет выбора? Ты смотришь со своей позиции, но я лично встречал людей, которые уходили в говнософт с блядской политикой, потому что "у них интерфейс не такой отсталый".
Мало кому хочется ездить в надежном тракторе — всем хочется комфорта и эстетического удовольствия, даже если этот комфорт временный под руководством пидорасов.
Необходимо запустить микросервисы на докере, уметь в красночерное дерево, уметь в поиск LCP и прочую хуйню для строк. Этого достаточно чтобы называться джуном.
Поясни за микросервисы. Это отдельные программы, которые выполняются в фоне и вызывают друг друга? Разве от этого не страдает скорость? В винде вот точно немаленькие накладные расходы при использовании com.
>то в большинстве пишется интернет магазин
Вот именно, что в большинстве. Т.е. каждый второй будет у себя в резюме ссылку на свой пет с недоделанным магазином какой-нибудь бесполезной хуйни.
Ну и если ты даже дойдешь до собеса, то первый вопрос будет - нахуя ты на шарпе делал то, что в любой cms делаетс в пару кликов.
Вот тебе нормальная идея:
Запили микросервис для сбора метрик с сервера.
1) Т.е. модуль который устанавливается непосредственно на сервере и по запросу может отдавать нужные метрики (память, диск, нагрузка и т.д.). Тут как минимум отработаешь REST, оптимизацию и научишься получать метрики разными хитровыебанными способами (причем еще и по разному в зависимости от системы)
2) Затем сервис-агрегатор, в котором регистрируются сервисы первого типа и он опрашивает их с заданной периодичностью и складирует данные у себя в БД. Плюс по запросу может отдать их в нужном количестве и разнообразии. Тут отработаешь работу с БД, Quarz, межсервисное взаимодействие, фильтры и сортировки в запросах и т.д (например через OData или вообще свой миниязык запросов придумать), можешь еще и аутентификацию прикрутить.
3) Ну и третье - это морда (например на WPF или React-е) которая будет обращаться к агрегатору и выводить данные в виде графиков-цифирок. Тут отработаешь взаимодействие с пользователем, те же запросы к сервису и т.д.
Короче что-то вроде самописного аналога Прометеуса+Графана.
Далее заводишь себе пару тройку vps-ок, раскидываешь на них свои сервисы и можешь в любой момент показать их работу кому угодно. Если сделаешь толково, то даже сам сможешь этим пользоваться. Плюс немного подучишь работу со стороны девопса, т.к. в реальной работе часто нужно разворачивать всякую хрень, как минимум для тестов своего говнокода.
>Разве от этого не страдает скорость?
>В винде вот точно немаленькие накладные расходы при использовании com.
И при этом ты делаешь приложение, которое работает с базой данных по сокету и тебя не парит этот факт "ааааа производительность".
Все зависит от деления монолита.
Можно.
Калипта Анны, которая считается самой быстрой птицей в мире относительно своего размера, может развивать скорость до 80 км в час.
Задача
Напишите программу, чтобы вывести, сколько километров она будет преодолевать каждый час за 5 часов полета.
Выходные данные
80
160
240
320
400
Подсказка
Просто умножьте 80 на счетчик для каждой итерации.
Используйте цикл for для итеративного выполнения умножения.
Я вот сейчас час думал над тем, что требуется, даже заснул от того, что сложно понять. Что она. По условию задачки. Летит на максимальной скорости и надо просто количество км с нуля каждый час выводить. ПРИ УСЛОВИИ, ЧТО НЕПРЕРЫВНО ЛЕТИТ ПО ПРЯМОЙ!!!
Пиздос, ну кто так условия ставит.
А как проходит ваш день?
годно, спасибо
Enumerable.Range(1, 5).Select(i=>Console.WriteLine(i*80));
>которая считается самой быстрой птицей в мире относительно своего размера,
Пиздос у составителя задачи хлебушек в голове. За каким хером тут ремарка о размере. Вот поэтому сидишь и думаешь, что где-то проебался, думая куда тут размер приткнуть.
Вкатунов надо сразу приучать находить суть в многостраничных доках кабана, где много лишнего описания, не имеющего отношения к самой реализации.
Это хорошая идея, чтобы человек фильтровал информацию. Школьники и первокурсники очень туго воспринимают условия задачи и тот факт, что половина ответа всегда содержится в вопросе.
Когда научишься воспринимать инфу в целом, то даже будешь ловить кайф от затерявшихся между строк нюансов. Появится своего рода наблюдательность.
вот я хочу определить интерфейс такого вида
у меня есть два источника данных, один выдает float, другой выдает int, я бы хотел чтобы класс с этим интерфейсом мог одновременно и источник с int и источник с float обрабатывать, чтобы не городить дичь типа
MyClassInt : MyInterface<int>
и
MyClassFloat : MyInterface<float>
специально под каждый источник данных
как это лучше сделать?
Ну так ты производный класс тоже сделай дженерик.
Ты должен определять тип данных класса на стадии его объявления.
так источник данных уже на определенном классе будет
может сделать проверку в конструкторе? типа
if(typeof(T) == typeof(int)) использовать этот метод обработки
и т.д.
>if(typeof(T) == typeof(int))
Не нужны никакие проверки, если ты используешь дженерики.
У тебя на стадии объявления задается обрабатываемый классом тип. До этого момента, класс не должен ничего конкретизировать, кроме всяких свойств, у которых тип конкретный.
Я не помню как в шарпе, но в бейсике когда ты создаешь экземпляр класса, пишется вот такое:
New MyClass(Of Integer)
Т.е. ты говоришь, создай мне класс, который будет обрабатывать интеджер. А если тебе надо обработать флоат, то создаешь новый экземпляр
New MyClass(Of Float)
И у тебя будет два экземпляра класса, где каждый обрабатывает свой конкретный тип.
Суть дженериков в том, чтобы ты не писал по нескольку раз повторяющийся код, но под капотом он напишется за тебя. По факту у тебя будет две функции, одна под int, другая под float.
Если ты думаешь, что будешь юзать один экземпляр класса на оба типа, то так это не работает.
Если мы говорим про функции класса, где ты хош интеджер запихнул в аргумент, а хош флоат, то это уже называется перегрузкой. Но как ты наверно понял, удобство использования компенсируется неудобством создания. Для перегрузок тебе придется писать код несколько раз.
да е-мое.
>По факту у тебя будет две функции, одна под int, другая под float.
т.е. два экземпляра класса
так в итоге мне придется делать:
2 экземпляра класса-потребителя данных c дублированным кодом и 2 экземпляра класса-форвардера данных с дублированным кодом
это кмк уродство выйдет
вот бы было возможно сразу на старте узнавать что за данные и, ну не знаю, подменять внутренний делегат на doInt/doFloat/doEtc
Занимаюсь этой хуетой уже последние лет десять до этого были жалкие попытки вкатиться в гейдев через юнити. Последние пару лет всё больше думаю перебраться во что-то более стабильное и менее всратое нода катится непойми куда, фрагментация с дено/бан/пизда-твоего-трапа, низкое качество проектов, без пакетов хуй что сделаешь, write-only код, на фронте не лучше, реакт написан дропаутами без вышки с переизобретением всех хуёвых концепций прошлого до которых хватило ума соевых разрабов, ангуляр сдох, свелт сырой и популярен только у твитерских сойбоев, тулы переписывают на раст, потому что жс говно. Изначально выбор пал на Гошечку, так как она показалась простой для кододебила вроде меня. Вроде начал вкатываться, вроде всё понятно... но потом я начал упираться в примитивность языка (и это ещё на этапе изучения), которая начала просто раздражать. Позже понял что также сложно найти работу на удалёнке, когда ты по сути жуниор в Го, а на месте вакансий по Го и нет. В общем пока забросил Го, но думаю попробовать ещё раз вкатиться в бекенд через .Net/C#. Собственно вопроса на данном этапе два:
1. Насколько глубокл в легаси надо лезть при изучении платформы и языка? Пробежавшись по верхам вакансий, вижу много современных вещей уровня .Net 6. Но в тоже самое время вижу какие-то более древние вещи типа ASP.Net. Как часто нужны знания древних, когда работаешь над новыми проектами? Буду ли я огребать не поевши легаси лет десять назад? Вопрос скорее всего покажется идиотским, попробую пояснить по аналогии. Часто встречаю фронтов, которые начали свой путь с Реакта и до этого им не приходилось работать с DOM напрямую, писать чистый жс и тому подобное. Я вижу как они страдают когда надо закодить что-то снаружи современного джаваскрипта или разобраться с чем-то уровня Backbone.js или какого-то кода написаного в стиле ES5.
2. Второй вопрос по поводу Винды/Микрософта. Так или иначе когда сталкивался с .Net проектами или разрабами, они все юзали Windows/Azure/Visual Studio. Как обстоят дела с .Net разработкой из под macOS инбифо туда ли ты зашёл, сахарок?? Сижу на маке уже много лет, а до этого сидел под Линуксом уже не чисто на уровне мышычной памяти не могу использовать Windows. И соответсвенно мне было бы комфортно продолжать юзать всякие macOS'ы. Есть ли вообще смысл вкатываться в .Net с этим моим Маком? Или опять же буду огребать от несовместимостей, более слабых тулзов, нежелания работодателей выдавать оборудование от Apple?
Занимаюсь этой хуетой уже последние лет десять до этого были жалкие попытки вкатиться в гейдев через юнити. Последние пару лет всё больше думаю перебраться во что-то более стабильное и менее всратое нода катится непойми куда, фрагментация с дено/бан/пизда-твоего-трапа, низкое качество проектов, без пакетов хуй что сделаешь, write-only код, на фронте не лучше, реакт написан дропаутами без вышки с переизобретением всех хуёвых концепций прошлого до которых хватило ума соевых разрабов, ангуляр сдох, свелт сырой и популярен только у твитерских сойбоев, тулы переписывают на раст, потому что жс говно. Изначально выбор пал на Гошечку, так как она показалась простой для кододебила вроде меня. Вроде начал вкатываться, вроде всё понятно... но потом я начал упираться в примитивность языка (и это ещё на этапе изучения), которая начала просто раздражать. Позже понял что также сложно найти работу на удалёнке, когда ты по сути жуниор в Го, а на месте вакансий по Го и нет. В общем пока забросил Го, но думаю попробовать ещё раз вкатиться в бекенд через .Net/C#. Собственно вопроса на данном этапе два:
1. Насколько глубокл в легаси надо лезть при изучении платформы и языка? Пробежавшись по верхам вакансий, вижу много современных вещей уровня .Net 6. Но в тоже самое время вижу какие-то более древние вещи типа ASP.Net. Как часто нужны знания древних, когда работаешь над новыми проектами? Буду ли я огребать не поевши легаси лет десять назад? Вопрос скорее всего покажется идиотским, попробую пояснить по аналогии. Часто встречаю фронтов, которые начали свой путь с Реакта и до этого им не приходилось работать с DOM напрямую, писать чистый жс и тому подобное. Я вижу как они страдают когда надо закодить что-то снаружи современного джаваскрипта или разобраться с чем-то уровня Backbone.js или какого-то кода написаного в стиле ES5.
2. Второй вопрос по поводу Винды/Микрософта. Так или иначе когда сталкивался с .Net проектами или разрабами, они все юзали Windows/Azure/Visual Studio. Как обстоят дела с .Net разработкой из под macOS инбифо туда ли ты зашёл, сахарок?? Сижу на маке уже много лет, а до этого сидел под Линуксом уже не чисто на уровне мышычной памяти не могу использовать Windows. И соответсвенно мне было бы комфортно продолжать юзать всякие macOS'ы. Есть ли вообще смысл вкатываться в .Net с этим моим Маком? Или опять же буду огребать от несовместимостей, более слабых тулзов, нежелания работодателей выдавать оборудование от Apple?
почему ТУДА(метод Set, который принимает float) каст из инта не нужен, а ОТТУДА(int который передается обратно через ValueChanged) без каста в инт нельзя? в чем разница?
ну так int может implicit cast в float без потерь точности (не дробное же число)
а обратно cast теряет точность и поэтому требует явного указания.
теперь понятно, но все равно странно
мне просто казалось что C# это строгие типы и вот это все
а тут можно если на пол-шишечки, а вот тут нельзя, а тут вообще объект заворачиваем...
1. Если учить только .Net Core стэк (.Net 6, ASP .Net Core, EF Core и т.д.), и собеседоваться только на вакансии на нём, то в легаси особо лезть не придётся. Нормальные компании уже давно на него переметнулись и пилят сервисы только на нём. Вакансии с .Net framework лучше просто стороной обходить. С ними можно совсем на лютую дичь нарваться, типа первого ASP (что они вообще в начале 2000-х курили?) или ASP Web Forms. Уже достаточно вакансий на .Net Core(.Net 5, .Net 6).
2) .Net Core кроссплатформенный, нормально собирается и
работает под Mac OS (по крайней мере консольные приложения и веб-сервисы, шо там с гуём не знаю). С очень большой долей вероятности, сервисы вообще будут билдится в докер-образы и деплоиться в какой-нибудь кубер.
Под Mac OS есть Visual Studio, но она вроде урезана относительно виндовой, поэтому рекомендую разжиться лицензией на Rider от жид брейнс (в нормальных компаниях дают).
У меня коллега как раз сидит на маке и проблем не испытывает. Другой кстати, вообще на арчике. Тоже без проблем.
Есть обработчик нажатия кнопки, и надо сделать так, чтобы chat.Send() не вешал мне UI, при этом исправно обновляя его (там биндинг). Попытка сделать через таск попросту не работает
код на скрине плох. Он запускает таску и не дожидаясь ее окончания очищает текст в надежде, что таска успеет запуститься раньше очистки.
Так то можно юзать async/await в обработчике
или запустить Task.Run где юзать Dispatcher для обращения к контролу
Но вообще вся затея неправильная. Нужно сначала очищать поле ввода, а сообщение ставить в очередь на отправку с обдумыванием "а что делать если оно не отправится"
Мне нужен любой костыль, который просто это запустит, потому что это лаба, читай MVP, а не бизнес-приложение. async/await тоже ничего не делали. Про диспатчер не первый раз слышу, но он как-то крайне странно выглядит, и как его прикрутить я не понял. А ещё, что он собственно даёт
Вопрос от Василия Пупкина из города Костромы. Василий обнаружил, что код можно написать тремя разными способами. Детали вопроса на экране.
Время пошло.
...
Отвечает Александр Друзь:
Ещё варианты ответов будут? МБ Поташев что-то желает добавить?
> А как ты это определил?
Хелловорлд конпелируется без ошибок - значит выучил! Еее! Где мои 1000ККК зряплаты!?
Меняй на джаву, там больше вакансий
Деспетчер инвок выглядит странно, но без него никуда.
Представь, что ты в игре портал. Твой интерфейс находится в одной комнате, а твоя асинхронная функция находится в другой комнате. Ты из второй комнаты делаешь дыру в стене и пока портал существует, делаешь в первой комнате все что нужно и возвращаешься обратно.
Допустим у тебя есть сия конструкция.
Application.Current.Dispatcher.BeginInvoke(DispatcherPriority.Background,
new Action(() => Mouse.OverrideCursor = Cursors.Arrow));
Вот это твой портал. А вот в круглых скобках это та самая щель портала.
Application.Current.Dispatcher.BeginInvoke( );
А тут все то, что ты хочешь сделать со своим окном, пока скобки открыты.
new Action(() => this.Height = 100500) //Называется делегатом.
А это настройки портала:
DispatcherPriority.Background
Тут выше кто-то говорил, что биндинги могут UI даже из другого потока обновлять. Проблема в том, что таск, который я запускаю, в итоге ничего не делает. На второй стороне попросту не принимаются символы
Диспатчер это единственный вариант что-то асинхронно с UI запустить, чтобы при этом я мог этот UI обновлять?
>Тут выше кто-то говорил, что биндинги могут UI даже из другого потока обновлять.
С другим потоком всегда будут проблемы. Речь шла про асихронщину.
Биндинги на мой взгляд в первую очередь рассчитаны на связку с данными. У тебя могут быть трудности с перезаписью этих данных.
>Проблема в том, что таск, который я запускаю, в итоге ничего не делает.
Если нет инвока, то ничего не будет делать. Все верно.
Возникает исключение только если ты пытаешься из другого потока шатать свойства — тогда реально пишется "чел, я не могу это изменить т.к. оно в другом потоке". А если поток тот же, то исключения не возникает, но и результата тоже не будет.
>Диспатчер это единственный вариант что-то асинхронно с UI запустить, чтобы при этом я мог этот UI обновлять?
Биндинги. Но там нужна предварительная настройка.
Тебе не избежать инвоков. Вот возьми и создай отдельное решение с тестом инвоков. Можешь выложить сюда.
Меня они тоже бесят и я скорее их использую как заклинание.
А так там всякие сложности типа объект А ожидает синхронизации с объектом Б, и наоборот объект Б ожидает синхронизации с объектом А.
Есть Application.Current.Dispatcher.BeginInvoke
А есть textbox.Invoke
Так я и работаю с биндингами. Как мне их донастроить, чтобы они работали с асинхронностью/в отдельном потоке, при этом изменяя некоторый текст в гуе?
Хз, биндинги у тебя без асинхронности работают? Т.е. ты меняешь свойство из данных и у тебя автоматом меняется свойство твоего тексбокса? Стоит Mode=TwoWay и все такое?
Всё так. Теперь надо добавить асинхронности, потому что тяжёлая операция и бла-бла-бла
1224x576, 0:24
Возможно ты используешь invoke. Попробуй BeginInvoke.
Если у тебя хуйнянейм начинает инвокать с высокой частотой, то она тянет все внимание на себя и не дает работать другим операциям в окне. Это равносильно тому, что ты запустил функцию тупо в этом окне.
Используй BeginInvoke. Ее отличие в том, что она не с ноги ебашит и грит "вот она я, прими мои метод".
BeginInvoke стучит в дверь и спрашивает "можно войти?", у нее есть await — ожидание.
И на видерил (извини шо бейсик) я запустил одновременно два цикла.
раньше вроде был еще EndEnvoke и он должен был идти после BeginInvoke, но сейчас его не нашел.
Нене, у меня на данный момент только то, что было на скрине закомменчено. Такс не сработал, так что я ищу обходные пути
Есть только обработчик кнопки и в нём тяжёлая функция, которую желательно бы стартануть где-нибудь в другом месте, чтобы она при этом обновляла гуй
Ну да, выносишь функцию отдельно, это первым делом.
Если она долго считает, но используется с малой частотой, и тебе хочется, то делаешь эту функцию асинхронной, а в конце return task (или как там у вас). А то что эта функция возвратит, ты пихаешь в свойство текста.
Если как у меня в примере, где функция очень часто обращается к гуи, то используешь InvokeAsync.
Плохая идея, а если операция будет длиться дольше 50 миллисекунд?
Она и так вроде как отдельно вывешена. Там рядом разве что очистка поля ввода
Частота зависит от пользователя. Возвращает она примерно нихрена, поэтому я не знаю, куда внутри await засовывать
>что биндинги могут UI даже из другого потока обновлять
если мы говорим ПРО WPF, то да - свойства вьюмодели можно обновлять из другого потока, а биндинг который привязан к этому свойству обновит гуи через контект синхронизаци (конечно затрачивая на это время и тормозя алгоритм в другом потоке)
(но при этом не Add/Remove у биндинга коллекций)
на твоем скрине вообще не пойми что это впф или винфрмс и где там биндинги или хотя бы обновление чего либо в гуи.
Я понял в чем у тебя проблема. Стринг хоть и притворяется структурой, но он все же ссылочный тип.
Когда ты таску передаешь ссылку, то таск начинает шатать ее и не давать другим заюзать. И у тебя случается подвисон.
Передай текст во временную переменную (любые операции со строкой порождают новую строку), которую потом отправляй в Task.
>если мы говорим ПРО WPF, то да - свойства вьюмодели можно обновлять из другого потока, а биндинг который привязан к этому свойству обновит гуи через контект синхронизаци
Нихуя, щас сам пробовал. WPF.
- Создал текстовый бокс.
- Привязал его к депенденси проперти типа string.
- Передал в таск это проперти как аргумент, где в цикле начал нещадно и безостановочно юзать.
Результат: подвисон.
И да, проперти — это часть класса MainWindow, и биндиг вероятно не виноват в неисполнении своих обязанностей т.к. виснет все окно.
Но ведь когда ты создаешь экземпляр класса вьюмодели, то ведь с этого омента этот экземпляр начинает принадлежать STA-потоку окна.
Падажжи, в таск отправляется делегат, в моём случае лямда, которая уже принимает стрингу. Плюс та самая стринга больше нигде не юзается. Попробую, конечно, но звучит странно
Ах ну да.
Если юзать INotifyPropertyChanged, то обновление свойства будет по событию. Проверил — работает.
Однако ж, заработало. Спасибо
потому что жава это говно мамонта, где сидят заскорузлые жависты, которые не умеют в новое.
А шарписты нормальные ребята и с радостью отбрасывают устаревшее говно и не считают нужным его продолжать жрать.
Ну я тоже думал что хрень, но с новым экземпляром стринга у меня завелось. Но если я передаю ссылку напрямую, то виснет.
Передается ссылка на оригинальное совйство и таск начинает эту ссылку блокировать для остальных.
Алсо >>508961 как анон писал >>508935 , если ты биндил к свойству через INotifyPropertyChanged, то там вообще не важна занятость свойства. Свойство отправляет событие и элемент гуи работает именно с событиями.
>Свойство отправляет событие и элемент гуи работает именно с событиями.
не думаю. думаю что биндинг получает событие, достает значение свойства из объекта в абы каком потоке, а потом уже маршалит его в контекст синхронизации для рисования в гуи.
вот код приложил, допустим если на каждом объекте есть условие(изменился). они могут изменяться, например child1 будет изменен, child2 нет, если родитель не изменен, то обновить только child1, в противном случае всех. я как-то так хочу сделать.
как вообще подобные иерархические "деревья" строят?
я нигде не учился и не программист вообще не бейте палками
Когда нужно обходить графовые структуры , то лучше всего использовать BFS( https://e-maxx.ru/algo/bfs ) или DFS ( https://e-maxx.ru/algo/dfs ), в зависимости от того, какой порядок тебе нужен. Лучше всего взять стандартную реализацию одного из них (они простые, всего-то стэк/очередь + цикл) и дополнить своими кусками кода.
Во первых .Net Framework 4.8 поддерживается до сих пор и будет поддерживаться до тех пор пока жива 10-я винда, а это минимум до 2025-года. А с учетом того, что и в 11-й он будет, то и того дольше.
А у .Net Core и .Net смысла нет дольше LTS-ки держать, т.к. новые версии - это по сути и есть мажорные обновы платформы и переход с одной, на другую вообще минимальные усилия по меркам бизнеса занимает.
Если проекты построены нормально (а чаще всего это так, т.к. в шарпе исторически и традиционно более жесткие требования к чистоте кода), то переход с версии на версии вообще между делом может происходить в течение пары спринтов.
Гугли "Обход дерева в ширину" и "Обход дерева в глубину" и выбирай то, что соответствует твоим потребностям.
Заметил, что в каждом треде каждого раздела найдется такой пассивно-агрессивный попукиватель.
Перекати.
А тебя мы для чего держим
Тс. Не пали контору.
Делай так. Базарю, еще захочешь!
Есть ли какой-то простой способ узнать оригинальный IPадрес-порт по которому моя хуйня доступна снаружи?
Ну. Т.е. смотрите. Моя хуйня - за натом. Сидит на 80 порту на виртуалке. Одмены настроили проброс. И вот я - забываю на каком порту внешнего IP-адреса висит моя хуйня. Хочу чтобы на веб-морде можно было посмотреть этот адрес-порт, чтобы если кому-то надо - не лезть в почту и не искать проброс.
решается очень просто - сканируешь весь диапазон IP
их не так уж много, всего чуток миллиардов.
Сделать запрос к какому-нибудь checkip.dyndns.org, но так можно узнать только IP. Так что лучше вынести эти данные в конфиг, всё равно они будут редко меняться.
Я в глаза долблюсь или 41-й тред по шарпу смыло?
У меня даже из подписок тред пропал
1) Решил поизучать с# и столкнулся с проблемой запуска кода в стандартном проекте, не могу запустить и кнопка запуска серого цвета, с хот кеем тоже самое
2) Я немного изучаю Java и хотелось бы узнать чем же c# по вашему мнению лучше и в каких областях имеет преимущество.
Спасибо
>столкнулся с проблемой запуска кода
Какая IDE хоть?
>чем же по вашему мнению лучше
По "нашему мнению" всем чем можно. Для меня прежде всего удобство и широта возможностей.
Можно ебашить жесткий ООП, лайтовую функциональщину и ламповую байтоеблю
Можно в винду, можно в линукс, а можно и в сраку мак
Можно в десктоп, можно в кровавый энтерпрайз, можно в иссушающий геймдев.
Сахарок, ммм.
Главное, что в любой области которую выберешь, при использовании шарпа все это делается легко и приятно, особенно после прихода Core.
Джава лучше. Больше вакансий, легче изучать. Стек не зависит от хотелок одной фирмы. Ничего не переделывается в каждой версии, а имеется обратная совместимость, т.е. код для джавы 1.0 можно выполнить на джава 18.
код!!! шарпа тоже можно выполнить
речь идет про бинарную совместимость, но из за этого у жавы хуже рантайм - типов нет, структур нет - все в угоду старья (legacy)
Структуры очень спорный момент. Не факт даже, что они ускорят выполнение, но вот проблем (особенно в многопоточных приложениях) добавят.
Что значит не факт. Еще какой факт.
Даже в жаве примитивные типы оптимизированы как структуры ибо это имеет значимый эффект. А в шарпах есть ref структуры, что еще быстрее.
А насчет многопотока - сдуру можно и.... (цензура)
Зато у жавы есть котлин который неплохо смотрится на фоне жадного до выразительности шарпа (аж трисёт)
Да хуета какая-то. В 3д-разделе тоже удаляли целые треды, посвященные конкретному пакету, и тоже были теории на подобии твоей, мол админ не любит тот софт.
Но слишком много совпадений.
Что с двачем происходит? Бардак какой-то.
хз. так то асп.нет неплохая штука в плане реализации
жаль что MVC если для стандартных сайтов со страничками
но обычно ж пишем вебапи, а там нормусик
Я вообще не понимаю что и к чему там. Куча кода, куча каких-то файлов-папок. А вместо объяснения, говорят пиши контроллер в такой-то папке, иначе ничего работать не будет. Почему надо писать там? Зачем нужны другие папки? Что там наворочено под капотом?
Вообще, нельзя было сделать просто набор методов для работы с HTTP? А уже где и что размещать, программист решал бы сам.
Потому что конвенция.
Конвенция дает структурность и понимание, чтобы был порядок и все работало как положено, и чтобы левый программист не тыкался как слепой котенок не понимаю как у тебя все организовано
>нельзя было сделать просто набор методов для работы с HTTP
ну почему нельзя? льзя. вот сделали для любителей такого "как в тех микрофреймворках вот мы тоже так могем"
и для любителей вебформс тоже сделали подобие.
Но конкретно asp.net MVC он исповедует MVC как там дедушка Ruby On Rails завещал всем делать - потому эти все фреймворки похожи в разных языках (кроме питона в силу его особой модульности) и вот я после пхп в асп.нет сразу знаю где чего лежит.
(хотя конечно МVP, с которым я имел дело в пхп, удобнее)
Читай "Asp.net в действии", есть на русском, там все исчерпывающе объясняют.
> Почему надо писать там?
Общепринятое соглашение. Впрочем никто не мешает задать собственные пути для контроллеров и прочего.
>А вместо объяснения, говорят пиши контроллер в такой-то папке, иначе ничего работать не будет. Почему надо писать там? Зачем нужны другие папки? Что там наворочено под капотом?
Ну так прекращай смотреть говновидосики с говнокурсами и начни читать умные книжки и статьи. Там все это написано.
>Asp.net в действии
Дак книга не успела выйти, а уже устарела. Там дотнет 3, а сейчас уже 7. Ни один пример даже не откомпилируется.
Видимо моча психанула.
Как раз с 5 на 6 самый сильный слом произошёл. Всё поменялось кардинально.
Что такого кардинального? Всего лишь убрали класс стартап, переместив все в билдер. Все методы остались прежними.
Роуты тоже поменялись
но мне бы хотелось чтобы и ShapeMaker и ShapeTemplate не знали про конкретные Shape
Ну первая этакое подобие абстрактной фабрики (паттерны это модно)
второе это просто фабрика (паттерны это модно)
а учитывая что мы не знаем что там происходит
если бы мы знали что это такое, мы не знаем что это такое
Да.
Это микрософты вытекают. Сколько можно обновлять дотнет? Почему нельзя сбавить темпы и выкатывать новую версию раз в 3 года хотя бы. Вы сами-то успеваете отслеживать все эти изменения?
RabbitMQ - обязательно
Кафка - встречается крайне редко. Если знаешь рэббит, то сможешь в любое время и ее изучить.
Кубер - не нужен, докер - нужен.
Если бы так и было, у нас до сих пор был бы .net framework, никакой кроссплатформенности, никакой контейнеризации, никакого linq и т.д.
Маши крыльями или сдохнешь.
Везёт же
мимо джун без опыта
Кто-то может сказать почему не хочет запускаться? НА всякий случай переустановил и не помогло
Удали всякие юнити, профилировщики и прочий мусор, что ты наустанавливал.
- Выбран не тот проект для старта. Нам не видно же
- не тот фреймворк. Может там тот что нет в системе
- русификация студии самая вероятная причина
У меня русифицированная студия, полет нормальный.
Видна субъективная неприязнь к русификации.
Сделай полный скрин экрана, чтобы было видно код, обозреватель решения и панель инструментов.
Запили.
Админ, ты? Зачем удалил тред?
Когда у меня функция возвращает кортеж, то у меня во всплывающей подсказке над именем функции идет подпись "Types:", но там пусто.
>У меня русифицированная студия, полет нормальный.
а у дофига новичков нет ибо
>Видна субъективная неприязнь к русификации.
нерусифицированная студия выдает ошибки на англ языке, которые можно загуглить в инете.
Та же херня с русифицированными исключениями.
В Visual Studio по дефолту все показывается.
>нерусифицированная студия выдает ошибки на англ языке
У каждой ошибки есть код. Этот код еще и URL ссылка, которую можно тыкнуть и перейти сразу в MDSN.
Допустим я хочу, чтобы событие MouseMove работало только при зажатой левой кнопке.
Могу ли я подписаться в событии MouseButtonDown и отписаться при MouseButtonUp. Хочу реализовать функцию Drag n Drop.
Конечно можешь, это так и делается как бы.
Возьми из шапки.
И узнать там что это за ошибка (хотя и так понятно из её текста что она значит)
Но это не дает ответа ПОЧЕМУ У МЕНЯ ЭТА ОШИБКА
Вот я щас кликнул по ссылке ошибки
https://learn.microsoft.com/en-us/dotnet/visual-basic/language-reference/error-messages/name-name-is-not-declared
И это с русскоязычной студии
Частный случай
Если бы все было так просто то SO был бы чист от этих вопросов
И гугл выдача тоже
>там вакансий для джуна очень мало
Джуны никому не нужны вне зависимости от стека технологий. Ну только разве если 1С выучишь.
Ищи крупные компании, которые берут джунов и стажеров, и смотри, какие технологии там используются.
А что ты хотел там компилировать? Где точка входа?
Ок, какие шаги мне нужно сделать и какой код написать, чтобы была точка входа ?( смотрел туториал , там тип создал такой же проект и сразу запустил … ) спасибо
Просто создай новый проект консольного типа и все. В него уже будет включен класс Program с методом Main, который ты сможешь запустить.
Во всяких TreeView и ListView событие SelectedItemChanged срабатывает по MouseDown (а не по MousUp), что делает невозможным такие вещи, как Drag n Drop.
Я уже устал назвать WPF дебилизмом. Но как это дерьмо обходить? Есть возможность самому узнать на как какой итем указывает курсор?
Какой же говнокод получился.
SelectedItemChanged биндится к свойству вьюмодели и просто там существует.
А потом событие MouseButtonUp заглядывает во вьюмодель к упомянутому свойству выше и "выделяет" его.
А я с ним работал
У нас еще девопса не было, поэтому любое обновление говносайта шло через ручную остановку IIS и копирования всех измененных файлов
Ну и создания папочки бекап_дата
Вы видите копию треда, сохраненную 29 ноября 2022 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.