| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Delphi: Общие вопросы > сохранение конфигурации ini или не ini? |
| Автор: Teleport 27.7.2008, 18:50 |
| Разобрался с ini файлами. Можно сохранять конфигурации программ. Но вот слышал, что можно не только ini использовать. Типа получше что-то есть, а ini уже устарела и не будет поддерживаться в Windows. Какие советы будут? Например, нужно сохранить положения кнопок на форме, цвета Label, размеры Memo. Кроме ini, что можно еще использовать? |
| Автор: Данкинг 27.7.2008, 18:56 |
| Реестр. Кстати, один из пунктов для успешной сертификации программы Microsoft'ом - если эта программа сохраняет свои параметры в реестре. |
| Автор: Riply 27.7.2008, 19:03 | ||
Зависит от размера данных. Небольшой, IMHO, лучше(удобнее) в реестре, иначе в IniFile`е. Выбор также может зависеть от требований к программе, но основной критерий - религиозные убеждения автора  |
| Автор: Qu1nt 27.7.2008, 19:49 |
| Последнее время стало модно использовать xml) |
| Автор: ZBugz 28.7.2008, 08:15 | ||
А причем тут Windows и ini ? INI надежна тем, что если сохранять параметры программы в ее же папку, то обычно не бывает проблем с доступом. А если в реестр сохранять и не будет прав доступа, то плакали твои настройки. INI - форева  |
| Автор: Akella 28.7.2008, 08:39 | ||
Ты не прав, в Висте есть проблемы, если программа устанавливается в папку program files на системном диске. Видать эта папка контролируется правами (контроль прав пользователей). Виста просто не даёт создавать у себя в папке файлы, пока не отключишь контроль прав. Кстати (по непроверенным данным) в последнем релизе висты контроль прав отключен по умолчанию. |
| Автор: Poseidon 28.7.2008, 08:41 | ||||||
|
| Автор: ZBugz 28.7.2008, 09:46 | ||||||||||||
 У меня виста, есть прога, пишет INI к себе, вооще без проблем, даже с полностью включенными настройками в windows. Добавлено @ 09:48
Первое вообще не понятно, с какого перепуга ? Я даже на чистом 95 тестировал свои программы, без osr2, все пашет отлично. Второе, на чтение то есть, а записывать чем будешь, если доступ админ закроет ? Это точень часто. А если много пользователей, то там же в папке создаешь профайлы, очень многие и очень хорошие программы так делают, и удалаять настройки легко, если что нибудь пользователь напортачил, да и вообще при деинсталяции удалять проще |
| Автор: Teleport 28.7.2008, 10:25 |
| Нну то что в qip ini используется вроде пашет без проблем...(Config.ini - там такой файлик видел) 2 Qu1nt насчет xml - подробнее можно?  |
| Автор: Poseidon 28.7.2008, 11:16 | ||||||||
Сам-то понял?
|
| Автор: Teleport 28.7.2008, 12:04 |
| про xml расскажите Добавлено через 13 секунд  |
| Автор: Poseidon 28.7.2008, 12:44 | ||
|
| Автор: Teleport 28.7.2008, 13:01 |
| 2 Poseidon понял, спасиб))) |
| Автор: ZBugz 28.7.2008, 13:16 | ||||||||
Ниче не будет. Это просто пропаганда реестра с 95 виды.
Все закрывается, вчем проблема ?
Хрен один, если туда залезут, то и туда смогут.
А у меня работает  Я как раз эти моменты тестировал В итоге помимо реестра, можно сохранить ini в профайл пользователя или накрайняк, если правда это временный файл, то temp. |
| Автор: CodeMonkey 28.7.2008, 14:37 | ||||||||||||||||||||||||
Рекомендую использовать http://homepages.codegear.com/jedi/jvcl/, конкретно - компоненты TJvAppRegistryStorage + TJvFormStorage. Позволяют не писать кода вообще. Можно просто кинуть на форму, настроить где хранить настройки и указать (мышкой), какие свойства каких компонентов на форме сохранять. Всё.
Да, ini файлы действительно считаются устаревшим способом хранения настроек ещё с Windows 95. Но нужно понимать, что ini-файл - это обычный текстовый файл, и ничто вам не мешать создавать, читать и изменять текстовые файлы.
Большой объём данных лучше вообще в отдельном файле хранить, ибо это - уже не настройки.
Неверно. Если программа располагается в Program Files, то использование ini-файлов в папке с программой невозможно из под любых пользователей, кроме администраторов. Кроме того, такой подход создаёт проблемы с несколькими пользователями. Правильное место для размещение ini-файлов - папка Application Data.
Если идёт сохранение в правильное место реестра (HKCU/Software), то права - есть.
Точно бред. UAC - это вспомогательное средство, облегчающее переход пользователей с административных учётных записей на обычные. Такой переход - одно из главных направлений дальнейшего развития Windows, ноэтому UAC ни при каких обстоятельствах не может быть отключен в конфигурации по-умолчанию.
Куда к себе? В какой-нибудь левый D:\Soft\App?
Это ещё как?
Такому администратору нужно руки оторвать. Это всё равно что на папку Temp deny all для всех поставить. А вот запретить запись в папку с программой - это правильное дествие. И это +1 причина, почему ini-файлы в папке с программой - плохое решение.
Уже было сказано, почему это плохо: многочисленные проблемы с правами на файлы.
Знаете, не просто так эту "пропаганду" развернули. ОС подразумевает определённую идеологию. Любые вещи в ней можно делать "правильно" и "неправильно". Так вот, в Windows использование ini - неправильно. Вам говорят как надо делать, чтобы писать качественные приложения в Windows. А вы говорите - типа, я самый умный, буду делать как хочу. А потом после выхода новой ОС имеете кучу проблем и вините во всём MS: ах, они черти, лишь бы мне жизнь усложнять. Не считая случая ярых идеологов ini-файлов, их использование может быть оправдано в случаях, когда реестр использовать нельзя - например, "мобильные" приложения на флешке. Во всех прочих случаях реестр (обычно) является предпочтительным местом хранения настроек.
Либо вы не всё нам говорите, либо вы администратор, либо вы угробили настройки системы по-умолчанию. Аплодисменты. |
| Автор: Teleport 28.7.2008, 18:19 |
| 2 CodeMonkey с компонентами буду разбираться, если что у тебя спрошу про xml еще не фига не понятно.... |
| Автор: ZBugz 30.7.2008, 07:52 | ||||||||||||||||||||||
Скачаю и проверю если не забуду У меня видео карта накрылась дома А на работе только XP  Добавлено через 14 минут и 4 секунды
Да в том то идело, у меня создает....  Видуху поченю, восстановлю все по дефолту, проверим еще раз, я потому что тестировал, все работало.
Совершенно верно, неспорю
Всмысле нельзя отключить ? Заходишь в панель управления, учетные записи и пользователи и выключаешь.
Нет, именно в программ файлэс\app
Это имеется ввиду, что поставил виндовс, ниче не рогая, сразу же ставишь порограмму.
Да кстати ты не прав, вещь очень нужная, очень много крупных фирм так делают, даже в нашей такое есть, не у всех конечно, у наших клиентов есть, но тоже не у всех. Это политика безопасности фирмы, устраивать пользователям при каждой загрузке новый год. Все что пользователь наработает, он сохраняет или на сервер или на флэшку, взависимости от важности данных.
Ну не чем не отличается от реестра, так как я выше уже сказал.
И при всем при этом виндовс юзает ini с такой любовью и очень много, одни настройки папок чего стоят.  Так что умный, не умный, а факт фактом. Достаточно запустить поиск ini файлов на чистой системе и все станет ясно.
Да вот нет, специально тестил по дефолту... Короче как поченю комп, так перепроверю, а то сомнения в меня нагшнали...  З.Ы. Ну а вообще автору темы, что реестр может быть запрещен, что запись на диск, что виндовс рекомендует реестр, в тоже время пишет кучу ini сам, поэтому, что ini, что реестр, тот же хрен, тока вид с боку и все будет работать, если написать с умом. |
| Автор: Poseidon 30.7.2008, 08:31 | ||||
|
| Автор: CodeMonkey 30.7.2008, 08:45 | ||||||||||
Вы неправильно поняли. Внимательнее читайте о чём речь шла.
Мне казалось, что в этом топике речь не идёт о корпоративном софте? Разумеется, если речь идёт о корпоративных приложениях, то мы вправе диктовать почти любые требования - от жёстко заданного набора софта и настроек до фиксированной конфигурации железа и сети. Но, позвольте, мы говорим о таких программах как Total Commander, Word, Delphi, Opera, Photoshop, QIP и т.п. Т.е. софт "из коробки". Никто из пользователей в здравом уме не будет блокировать запись в HKCU. А вот запись в папку с программой - да. Кроме того, для Program Files такие запреты уже стоят (имеется ввиду для не админов, разумеется). И в той же корпоративной среде практика работы не под админом распространена больше, чем среди простых пользователей.
Не путайте тёплое с мягким. Случай с папками - как раз тот случай, когда нельзя использовать реестр (подсказка: сценарий с перемещением/копированием папки). Кроме того, требования к ОС и к приложениям - наверное это всё же разные вещи и не следует их сравнивать. Ещё пример немножко в тему. Речь идёт о всяких "My games" и "My ebooks" в Моих документах. Microsoft сделала большую ошибку, введя папки типа "Моя музыка" и "Мои рисунки". Нет, поймите меня правильно, ничего плохого нет в том, что они появляются из коробки, подталкивая пользователя к наведению порядка в своей рабочей папки. Пользователь всё равно после установки будет настраивать систему в соответствии со своими требованиями и удалит/переместит/оставит эти папки как ему хочется. Проблема в том, что многие программы, не подумав, создают в моих документах свои аналоги (и часто - не локализованные). Но первейшее правило гласит: в папке мои документы не должно быть файлов, которые созданы не пользователем. Это МОИ документы, что здесь деляют сейвы от GTA? А этот My ebooks? Я до сих пор не могу найти [CENSORED], который постоянно упрямо пересоздаёт эту папку. Как только я его найду - ноги его на моей машине больше не будет. Для данных приложения есть Application Data, а папка мои документы - для меня и ТОЛЬКО для меня. Абсолютно без исключений. Я знаю немало людей, которые из-за таких вот приложений просто забрасывают папку мои документов и создают какую нибудь C:\Documents\Shurik\. Это очень плохо. К чему я это? Ах, да, мораль такова: что хорошо для ОС, необязательно хорошо для приложений. Так что используйте свою голову.
Знаете, помимо уже указанных причин, есть такое хорошее слово: "совместимость". Рекомендую почитать вот эту занимательную историю: http://transl-gunsmoker.blogspot.com/2008/12/shell-folders.html (кстати, пример на тему, почему для чтения системных настроек нужно использовать WinAPI, а не читать напрямую из реестра).
С этим я согласен. Замечу только, что с реестром возможности напортачить меньше. Т.к. по-умолчанию мы пишем именно в HKCU (т.е. куда надо). Имеется ввиду, стандартные классы Delphi, разумеется (ну и всякие сейвилки, типа тех же Persistence-компонент от JEDI). Для ini-файлов нет такого "места притяжения" (а если есть, то обычно это - в папке с программой). Поэтому очень часто ini не попадают в Application Data. Если ты опытный программер с головой - это не проблема, ты можешь самостоятельно решить, где и как будет правильно. Для новичков же, чтобы они ничего не напутали, лучше дать совет: "свои настройки - в реестр"! |
| Автор: Akella 30.7.2008, 09:36 | ||
в общем-то да, я оказался не прав, никакого отключения по умолчанию не будет. |
| Автор: ZBugz 30.7.2008, 14:12 | ||||
Блин, ты сам упертый наглухо  Кто тебе сказал что у меня не лицензионный виндовс ? Самая что не на есть настоящая лицензия с ключом активации. |
| Автор: Akella 30.7.2008, 14:15 |
| ZBugz, тише, тише Добавлено через 1 минуту и 6 секунд Откуда участникам дискуссии знать какой у тебя windows, лицензионный или нет? Тем более такие вопрос не прилично задавать, это типа как у девушки про возраст спрашивать.  |
| Автор: ZBugz 30.7.2008, 14:16 | ||||||
Ну все верно, я не спорю, просто смотря на что и с какой целью и для пишеться софт, это нужно брать в расчет. Так что для пользователей, может и реестр хорошь, в моем случае INI для корпорации, а универсально тогда наверное будет так, если нельзя в ini, значит в реестр и наоборот Добавлено через 50 секунд
Боша не буду |
| Автор: Akella 30.7.2008, 14:21 |
| Я тоже использую ini активно, так легче программу по локалке распростанять. Одну настроил и раскопировал по остальным компам. Особенно если настроек много. А после переустановки ОС достаочно вернуть каталог программы в сад и ссылку создать на рабочем столе. Тут уж нужно смотреть самому программисту по месту, так сказать. Может что-то удобнее в реестре, что-то удобнее на диске. |
| Автор: Poseidon 30.7.2008, 14:26 |
| Akella, читал твой последний пост, сразу возникла идея про экспорт и импорт настроек. Потом так думаю: "а куда же экспортировать?". Ответ пришел сразу... в ini |
| Автор: CodeMonkey 30.7.2008, 15:27 |
| Интересная ссылка в тему про настройки: http://blogs.msdn.com/oldnewthing/archive/2005/06/30/434209.aspx |
| Автор: yus 31.7.2008, 05:43 | ||
А можеш подсказать где можно почитать требования к сертификации программ Microsoft'ом? |
| Автор: CodeMonkey 31.7.2008, 09:24 | ||
http://www.google.com/search?q=Windows+Vista+Software+Logo+Spec http://www.google.com/search?q=Windows+XP+Software+Logo+Spec |
| Автор: Frees 31.7.2008, 11:22 |
| По поводу сохранения ини рядом с прграммой в программ файлс. Виста спокона даст туда сохранить ни чего не сказав, но зайдя под другим пользователем файла там не будет т.к фактически он будет хранится C:\Users\Frees\AppData\Local\VirtualStore\Program Files\Project1\ причем из программы у меня так и не получилось узнать куда на самом деле упал файл |
| Автор: Akella 31.7.2008, 11:31 |
| Frees, не верю, покажи код сохранения |
| Автор: Frees 31.7.2008, 11:32 |
| http://www.sql.ru/forum/actualthread.aspx?tid=577551 Добавлено через 49 секунд проверять наличие файла надо под админом |
| Автор: CodeMonkey 31.7.2008, 11:52 | ||||
А зря ;)
Это механизм виртуализации. Ещё одни костыли для кривых программ, чтобы они не упали при обновлении Windows: http://technet.microsoft.com/ru-ru/magazine/cc138019.aspx http://msdn.microsoft.com/en-us/library/bb530198.aspx Но о виртуализации в этом топике речь не шла. Для определения, виртуализирован ли процесс, нужно получить его токен и вызвать http://msdn.microsoft.com/en-us/library/aa446671.aspx с TokenVirtualizationEnabled (http://msdn.microsoft.com/en-us/library/aa379626(VS.85).aspx). |
| Автор: Frees 31.7.2008, 11:54 | ||
зато шла о сохранений в програм файлс |
| Автор: CodeMonkey 31.7.2008, 12:34 | ||
Вопрос был задан о том, как правильно делать. А вы говорите, что пишите как хотите - виртуализация всё скроет. Отличный ответ. Всё равно как на вопрос "в чём писать программы для Windows" ответить "в Turbo Pascal-е". |
| Автор: Frees 31.7.2008, 12:35 | ||
я не имел в виду токого! я просто хотел обратить внимание на проблемы которые могут возникнуть если писать в ини и ложить его рядышком |
| Автор: CodeMonkey 31.7.2008, 12:43 | ||||
Прошу прощения, что не так вас понял.
Возможно, стоило акцентировать на этом внимание, потому что вашу фразу
я понял именно так, как указал выше. |
| Автор: yus 1.8.2008, 08:02 | ||||
Спасибо. |
| Автор: KotBegemotKlg 1.8.2008, 22:39 | ||
| Лично моё мнение: Если нужно эти сохранённые параметры менять, то однозначно INI файл. Если это просто сохранение параметров, которые никто явно менять не будет - реестр. Если речь о базе данных, многие параметры, общие для всех, можно (и нужно) хранить прямо в базе. Почему INI: Потому что в реестре я могу соохранить ключ-(подключ)-значение. А потом ты откроешь реестр, найдёшь ключ EnableSmartEnumeration и долго будешь чесать репу что это за параметр, и за что отвечает. А в ini я напишу:
И у тебя не будет сомнений. |
| Автор: Poseidon 4.8.2008, 23:10 | ||
|
| Автор: CodeMonkey 5.8.2008, 02:33 | ||
можно ещё сказать, что в реестре проще хранить многостроковые и двоичные данные. Плюс иерархия против одного уровня, плюс возможность установки прав на каждый ключ, плюс наличие встроенного специализированного редактора. Ммммм.... может ещё что забыл. |
| Автор: KotBegemotKlg 5.8.2008, 12:23 | ||
Достаточно сравнить механизмы: 1. а) Открыть help, найти информацию о ключах и о том какой ключ за что отвечает. б) Открыть Regedit, найти этот ключ, исправить. 2. а) Открыть INI почитать за что отвечает ключ, тут же исправить. Второе явно проще. Насчёт доступа - это не вопрос реестра. Это вопрос бизнес-логики программы кому и к каким параметрам давать доступ. С реестром согласен только в плане иерархических данных (частично) и двоичных - там действительно это будет удобнее. Но опять же, выносить эти вещи в доступные настройки, имхо, ни к чему. Правке адвансед-юзером подлежат только простые параметры, которые не могут привести к краху приложения! Визуальные настройки среды (хотя это лучше и делать визуально, через окно настроек, чтобы пользователь тут же видел результат), какие-то параметры отображения данных, и так далее. |
| Автор: Poseidon 5.8.2008, 20:44 | ||
|
| Автор: Teleport 5.8.2008, 22:33 |
| вот уже учусь сохранять параметры прямо в базе, для определнных прог. А для других сохраняю в ini файле - так как параметры и настройки в программе постоянно меняются . С реестром пока тяжеловато. Не освоил еще никак |
| Автор: CodeMonkey 9.8.2008, 12:56 |
| Хоть мы немножко ушли в топике в сторону, но я думаю, что стоит сказать ещё пару слов про виртуализацию, а то многие даже не в курсе, что она есть (не говоря уже про то, зачем она нужна). Пост навеян топиком http://forum.vingrad.ru/forum/topic-223808.html Виртуализация позволяет работать в Vista старым кривым программам, которые пытаются писать свои даные в не предназначенные для этого места (Program Files, Windows и т.п.). Она предназначена только для обеспечения совместимости. Если такая програма под обычным пользователем пытается писать файл, например, в Program Files, то вместо этого она будет работать с файлом в папке C:\Users\<имя-пользователя>\AppData\Local\VirtualStore\Program Files. Очевидно, что для новой программы такая попытка приведёт к возврату ошибки "в доступе отказано". Кроме того, также очевидно, что такая старая программа будет работать только в Vista, в XP она не работала изначально (имеется ввиду - под обычным пользователем). Виртуализирован ли процесс можно определить в диспетчере задач (Task Manager) - просто добавьте столбец "Виртуализация". Про программное определение я уже сказал выше. Как Windows определяет, старая программа или новая? Виртуализация включается если:
|
| Автор: CodeMonkey 4.10.2008, 15:22 |
| Довольно неплохой обзор "ini-файлы VS реестр" (Реймонд Чен): http://blogs.msdn.com/oldnewthing/archive/2007/11/26/6523907.aspx (также рассматривается XML). |
| Автор: Sansa 6.10.2008, 06:16 |
| Я в своих проектах делаю так... По запуску программа читает "стартовые" параметры из ini файла, переданного ей в качестве параметра (если ничего не передавалось, то ищется ini файл в папке с программой, имя файла совпадает с имененм программы). Сделано для того, что бы можн было легко переносить программу мжду пользователями, а так же легко, с помощью ярлыков создавать разные окружения для одного пользователя. В этом файле настроек по минимуму (например, настройки соединения с базой данных, путь к ветке в HKCU/Software куда сохраняются остальные настройки, да еще пара-тройка параметров, которые после установки не требуют изменения, например, номер терминала, или какой-нить уникальный код приложения). Все остальные настройки пользователя (как то размер и положение окон и фреймов) - по указанному в ини ключу в HKCU. Все настройки специфичные для компьютера (которые не изменяются от пользователя к пользователю) - в HKLM/Software... Тем самым блокруется изменение этих настроек самими пользователями, без участия администратора. Вот, сопсна, все |
| Автор: ZBugz 16.11.2008, 11:35 |
| Ура Купил видуху и два новых харда, сделал рэйд, воткнул Vista, хорошо что вспомнил про INI. Сразу же поставил свою программу, Vista с нуля, даже без дравов, все насройки изначальные. Программа сохраняет настройки в C:\Program Files\Программа, сохранил настройки, вообще проблем не возникло. Так что ini легко работает в Viste по умолчанию. |
| Автор: Makhaon 16.11.2008, 20:30 |
| Мы у себя используем везде ini. Какие плюсы: 1. Софт запросто переживает переустановку винды. Многие винду-то и не хотят только из-за этого переставлять - на перенастройку софта нужно убить иногда неделю работы. Очень жалко, что, например, делфя не хранит свои установки в инишке, а все файлы - в одной, своей, папке. Винду из-за этого переставить не представляется возможным - просто работа встанет. 2. Софт запросто переживает атаку вирусов. Даже если вся винда и все экзешники мёртвые, то можно всё за 1-2 часа переставить. Иначе - возня, в лучшем случае, на полдня. Хотя, я понимаю, что лучше предохраняться, чем потом лечится - однако, что твоится у юзеров - сами знаете. 3. Инишку проще править руками, если параметры имеют хорошие названия (это же, правда, и частичный минус). 4. Софт проще настраивать на множестве установок - просто раскопировал инишку - и везде всё будет работать гарантировано одинаково. 5. Софт проще удалённо отлаживать. Инишки бывают достаточно толстые, множество параметров, и, что бы юзера долго не пинать - что у него и как настроено - проще забрать себе инишку, реально неоднократно помогало. Добавлено через 12 минут и 2 секунды Насчет Висты. Да - наваротили они там те еще навороты... Что нужно, что бы инишки хорошо работали под вистой? Писать в какую-нибудь попку, доступную для записи юзеру (мы пишем в AppData - она одна для всех юзеоров) и добавить в экзешник (или рядом с ним) ресурс - манифест. Ну и с инсталлером есть особенности. Но, в целом, работать можно. |
| Автор: aktuba 17.11.2008, 01:55 | ||
1 и 2, в данном случае, одно и то же ;). Я для себя уже давно решил, что все настройки будут храниться в xml - больше возможностей + расширять проще. |
| Автор: lukas 17.11.2008, 20:42 | ||
ИНИ всего лишь придуманный стандарт официальный или нет - это не имеет значение, так что привязка к ОС тут вообще не причем... |
| Автор: ZBugz 17.11.2008, 20:57 | ||||
Читай с самого начала внимательнее. Спор был про INI и ее совместимость по дефаульту в Vista. Все прекрасно работает. |
