Владимир Коротенко, в вопросе вроде про радиочастотные (из тех что встречал подключаются или по аналогу, или по оптике). IvanchikGLV уточните пожалуйста модель наушников, модель материнки и как именно они к ней подключены.
Komandarm, в netinst i386 32-битные UEFI загрузчики точно есть, только что качнул и проверил.
в полном и лайв аналогичных версий по-идее тоже должны быть.
брал ссылку тут
Komandarm, значит образ не UEFI, скачал первую попавшуюся убунту - она не UEFI действительно.
у debian есть i386 сборки с UEFI, попробуйте с них для начала загрузиться.
Владимир Шаблий, да, бывает экзотика. у меня разок было смешнее - API-шка чужая отдавала вроде бы нормальный json, но штатные десериализаторы им давились - пришлось писать минималочку чисто под этот кейс.
Что интересно потом апишку починили и костыль ушел в историю.
Владимир Шаблий, это по-моему эпический отказ, ибо каждый приличный сериализатор умеет в экранирование)
не, я вполне могу представить такой кейс - но это странно
Александр Андропов, string в base64 переводить большого смысла нет, base64 как раз придуман для того чтобы в изначально текстовых протоколах (rest, email и так далее) мочь передавать бинарные данные.
покажите доку на API, что и в каком формате вы ожидаете?
Задача странная - зашифрованная захардкоженная строка ничем особенным не отличается от логина и пароля (подсмотрели строку и ее используете для доступа к API) это если дешифровать сервером.
Если клиентом то значит ключ так или иначе должен быть на клиенте.
Может быть лучше зашить в сервер и клиент TLS (чтобы не только сервер предъявлял клиенту сертификат но и клиент серверу)?
Nulltiton, смотрите, у вас сейчас UI владеет всем, что в общем случае неверно.
для передачи данных между формами стоит использовать паттерны проектирования UI (MVC, MVVM и т.п.)
т.е. у вас например View оповещает контроллер, контроллер обновляет состояние модели, View (та же или совсем другая, не суть) обновляет на себе свойства, которые привязаны к модели.
По поводу сохранения: обычно архитектура такая, есть классы User (только свойства пользователя) и UserRepository, хранящий в себе CRUD операции над моделью (добавление, получение, удаление, изменение).
Если API у вас не анемичный (а предполагает те или иные логические действия и проверки) то выделяете еще один слой. Один из основных критериев готовности архитектуры к развитию - вы можете любой слой заменить другим (при условии совместимости интерфейсов) и у вас ничего не сломается.
Такой подход называется "луковая архитектура" - каждый слой взаимодействует только с двумя соседними.
Портятся данные вот к чему - статическое поле является общим для всех экземпляров класса, поэтому статические поля в нестатических классах надо применять хорошо понимая зачем именно вы этого хотите.
Form2, button1 - зло, в большом приложении будет Form18, button138 - как будете поддерживать?
В дизайнере можно раздать нормальных названий (MainForm, UserAddDialog, etc)
Мешать логику с обработчиками кнопок - зло, завтра UI будет другой.
Мешать DTO c сохранением данных - зло, завтра будет другая база, API или вообще файлы.
DTO для хранения данных и для обработки клиентом строго говоря не равны друг-другу.
static'и следует юзать понимая что это и зачем - в примере вы откроете 2ой экземпляр форм_1 и не будете понимать почему у вас данные портятся.
OmitDefaults (или IgnoreDefaultValues, емнип по разному может называться) в Json сериализаторах штука известная и десериализатор штатно от такого ломаться не должен - отсутствие поля равно дефолтному значению поля.
AgentSmith72, у вас файл открывается по относительному пути ("DB/users.json") и не копируется в выходной каталог.
При отладке в среде и при запуске собранного бинарника текущий каталог будет разный (в первом случае корень запускаемого проекта, во втором - папка где лежит бинарь) - вероятно отсюда и различное поведение.
P.S. освойте .gitignore, чтобы в репо debug, obj и прочие ненужные вещи не попадали.
AgentSmith72, сможете минимал репро на гитхаб выложить? по отдельности все выглядит верно, но раз не работает значит где-то вы неверно заклинания применили.
Для готового девайса имхо слишком узкий круг применения, потому готовых и не нашлось.
Предложил бы рассмотреть малину или аналоги с нужным количеством карт-ридеров и любым linux с dd.
Как вариант старый нет- или ноутбук.
По скорости правда минус - за недорого вы будете ограничены usb2.0 и возможно не самым быстрым режимом SD карты, т.е. для сильно быстрых карт вы получите заниженные значения скорости.
IvanchikGLV уточните пожалуйста модель наушников, модель материнки и как именно они к ней подключены.