Цитата:
Сообщение от Alegun
Легко решается переименованием (cnf.~ini) при первом пуске новой версииТам же, при первом пуске анализируется наличие/состояние компонент, если оно отличается от дефолтных, их не трогатьНет, форма останется одна, просто при смене учётки будет загружаться "образ" под конкретную запись
И видимо главное, здесь наблюдается смешивание понятий относящихся к самой программе и контентом ей создаваемым, такое нужно разносить в пространстве
|
Спасибо за идею! Думаю, ее можно развить в нужном направлении.
Сервис работает в многопоточном режиме одновременно со всеми учетными записями: 1 поток - 1 учетка. Настройки, которые вводит пользователь влияют на логику работы потоков.
Я часто выпускаю обновления в виде изменения возможных настроек - это можно отнести к метаданным (набор возможных настроек). То, что заполняет пользователь, можно отнести к данным пользователя (состояние набора настроек). А то, чем оперирует сервис помимо настроек, можно отнести к данным сервиса.
Т.к. учетные записи не переключаются, а работают в разных потоках одновременно, придется все же создавать несколько экземпляров форм, полагаю.
Пока что не совсем понятно как именно при первом запуске обновленной программы сравнивать 2 ини файла (новый мною высланный и старый пользовательский), чтобы определить различия и из старого ини файла заполнить свойства контролов в новом.