Разобрался с ini файлами. Можно сохранять конфигурации программ. Но вот слышал, что можно не только ini использовать. Типа получше что-то есть, а ini уже устарела и не будет поддерживаться в Windows.
 Какие советы будут? Например, нужно сохранить положения кнопок на форме, цвета Label, размеры Memo. Кроме ini, что можно еще использовать?

Реестр. Кстати, один из пунктов для успешной сертификации программы Microsoft'ом - если эта программа сохраняет свои параметры в реестре.

Зависит от размера данных.
Небольшой, IMHO, лучше(удобнее) в реестре, иначе в IniFile`е.

Выбор также может зависеть от требований к программе,
но основной критерий - религиозные убеждения автора  

Последнее время стало модно использовать xml)

А причем тут Windows и ini ?

INI надежна тем, что если сохранять параметры программы в ее же папку, то обычно не бывает проблем с доступом. А если в реестр сохранять и не будет прав доступа, то плакали твои настройки.

INI - форева   

Ты не прав, в Висте есть проблемы, если программа устанавливается в папку program files на системном диске. Видать эта папка контролируется правами (контроль прав пользователей). Виста просто не даёт создавать у себя в папке файлы, пока не отключишь контроль прав. Кстати (по непроверенным данным) в последнем релизе висты контроль прав отключен по умолчанию.

А при том, что нужно читать документацию!!! 


Доступ на чтение из реестра есть даже у гостя. Доступ в ветку HKEY_CURRENT_USER\Software (а именно туда рекомендуется сохранять настройки) есть у всех пользователей системы. А сохранять все в папку программы не совсем хороший тон, т.к. у разных пользователей могут быть разные настройки.

  
У меня виста, есть прога, пишет INI к себе, вооще без проблем, даже с полностью включенными настройками в windows.

Добавлено @ 09:48

Первое вообще не понятно, с какого перепуга ? Я даже на чистом 95 тестировал свои программы, без osr2, все пашет отлично.
Второе, на чтение то есть, а записывать чем будешь, если доступ админ закроет ? Это точень часто.
А если много пользователей, то там же в папке создаешь профайлы, очень многие и очень хорошие программы так делают, и удалаять настройки легко, если что нибудь пользователь напортачил, да и вообще при деинсталяции удалять проще  

Это сообщение отредактировал(а) ZBugz - 28.7.2008, 09:50

Нну то что в qip ini используется  вроде пашет без проблем...(Config.ini - там такой файлик видел)
2 Qu1nt насчет xml - подробнее можно?   

Это ты не по адресу вопрос задал. У Майкрософта спроси, чего он не рекомендуют. Если работает, то это еще на значит что все правильно, а значит что оставили для обратной совместимости. Но кто может утверждать, что в Vienna не откажутся от ini?

Доступ в HKEY_CURRENT_USER\Software?   Сам-то понял?

Хорошие? Может с точки зрения пользователя они и хорошие, а вот если посмотреть на них глазами программиста...

Бред! Тот же Тотал не хочет сохранять настройки в свой же Wincmd.ini Ругается что нет прав. Вот если отключить контроль (так называемый UAC) или разрешить изменение этого файла, то тогда без проблем.

про xml расскажите  

Добавлено через 13 секунд
    

В DRKB есть целый раздел про xml.

2 Poseidon понял, спасиб)))

Ниче не будет. Это просто пропаганда реестра с 95 виды.

Все закрывается, вчем проблема ?

Хрен один, если туда залезут, то и туда смогут.

А у меня работает   Я как раз эти моменты тестировал  

В итоге помимо реестра, можно сохранить ini в профайл пользователя или накрайняк, если правда это временный файл, то temp.

Рекомендую использовать 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-файлов, их использование может быть оправдано в случаях, когда реестр использовать нельзя - например, "мобильные" приложения на флешке. Во всех прочих случаях реестр (обычно) является предпочтительным местом хранения настроек. 


Либо вы не всё нам говорите, либо вы администратор, либо вы угробили настройки системы по-умолчанию. Аплодисменты.

2 CodeMonkey с компонентами буду разбираться, если что у тебя спрошу   
про xml еще не фига не понятно....

Скачаю и проверю если не забуду  У меня видео карта накрылась дома   А на работе только XP  

Добавлено через 14 минут и 4 секунды

Да в том то идело, у меня создает....   Видуху поченю, восстановлю все по дефолту, проверим еще раз, я потому что тестировал, все работало.

Совершенно верно, неспорю

Всмысле нельзя отключить ? Заходишь в панель управления, учетные записи и пользователи и выключаешь.

Нет, именно в программ файлэс\app 

Это имеется ввиду, что поставил виндовс, ниче не рогая, сразу же ставишь порограмму.

Да кстати ты не прав, вещь очень нужная, очень много крупных фирм так делают, даже в нашей такое есть, не у всех конечно, у наших клиентов есть, но тоже не у всех. Это политика безопасности фирмы, устраивать пользователям при каждой загрузке новый год. Все что пользователь наработает, он сохраняет или на сервер или на флэшку, взависимости от важности данных.

Ну не чем не отличается от реестра, так как я выше уже сказал.

И при всем при этом виндовс юзает ini с такой любовью и очень много, одни настройки папок чего стоят.  Так что умный, не умный, а факт фактом. Достаточно запустить поиск ini файлов на чистой системе и все станет ясно.

Да вот нет, специально тестил по дефолту... Короче как поченю комп, так перепроверю, а то сомнения в меня нагшнали...   


З.Ы. Ну а вообще автору темы, что реестр может быть запрещен, что запись на диск, что виндовс рекомендует реестр, в тоже время пишет кучу ini сам, поэтому, что ini, что реестр, тот же хрен, тока вид с боку и все будет работать, если написать с умом.

Вот тебе же говорят, что нельзя, а ты все заладил "у меня можно, у меня можно". Усли у тебя там Винда из серии "Фак ю билл", то это еще не говорит о том, что на "нормальной" версии будет так же. Еще раз тебе повторю, на лицензионной Висте в программ файлс ini - файлы по дефолту защищены от изменения.

Перечитай еще раз фразу, на которую ты так ответил. Человек имел ввиду что Майкрософт никогда не сделает UAC отключенной по дефолту. Мы им должны в ноги кланятся, что они вообще оставили возможность это отключать (а могли ведь и фигу показать, безопастность типо).

Вы неправильно поняли. Внимательнее читайте о чём речь шла.


Мне казалось, что в этом топике речь не идёт о корпоративном софте? Разумеется, если речь идёт о корпоративных приложениях, то мы вправе диктовать почти любые требования - от жёстко заданного набора софта и настроек до фиксированной конфигурации железа и сети. Но, позвольте, мы говорим о таких программах как Total Commander, Word, Delphi, Opera, Photoshop, QIP и т.п. Т.е. софт "из коробки". Никто из пользователей в здравом уме не будет блокировать запись в HKCU. А вот запись в папку с программой - да. Кроме того, для Program Files такие запреты уже стоят (имеется ввиду для не админов, разумеется). И в той же корпоративной среде практика работы не под админом распространена больше, чем среди простых пользователей.


Не путайте тёплое с мягким. Случай с папками - как раз тот случай, когда нельзя использовать реестр (подсказка: сценарий с перемещением/копированием папки). Кроме того, требования к ОС и к приложениям - наверное это всё же разные вещи и не следует их сравнивать. 
Ещё пример немножко в тему. Речь идёт о всяких "My games" и "My ebooks" в Моих документах. Microsoft сделала большую ошибку, введя папки типа "Моя музыка" и "Мои рисунки". Нет, поймите меня правильно, ничего плохого нет в том, что они появляются из коробки, подталкивая пользователя к наведению порядка в своей рабочей папки. Пользователь всё равно после установки будет настраивать систему в соответствии со своими требованиями и удалит/переместит/оставит эти папки как ему хочется.
Проблема в том, что многие программы, не подумав, создают в моих документах свои аналоги (и часто - не локализованные). Но первейшее правило гласит: в папке мои документы не должно быть файлов, которые созданы не пользователем. Это МОИ документы, что здесь деляют сейвы от GTA? А этот My ebooks? Я до сих пор не могу найти [CENSORED], который постоянно упрямо пересоздаёт эту папку. Как только я его найду - ноги его на моей машине больше не будет. Для данных приложения есть Application Data, а папка мои документы - для меня и ТОЛЬКО для меня. Абсолютно без исключений. Я знаю немало людей, которые из-за таких вот приложений просто забрасывают папку мои документов и создают какую нибудь C:\Documents\Shurik\. Это очень плохо.
К чему я это? Ах, да, мораль такова: что хорошо для ОС, необязательно хорошо для приложений. Так что используйте свою голову.


Знаете, помимо уже указанных причин, есть такое хорошее слово: "совместимость". Рекомендую почитать вот эту занимательную историю: Длинная и печальная история ключа Shell Folders (кстати, пример на тему, почему для чтения системных настроек нужно использовать WinAPI, а не читать напрямую из реестра).


С этим я согласен. Замечу только, что с реестром возможности напортачить меньше. Т.к. по-умолчанию мы пишем именно в HKCU (т.е. куда надо). Имеется ввиду, стандартные классы Delphi, разумеется (ну и всякие сейвилки, типа тех же Persistence-компонент от JEDI). Для ini-файлов нет такого "места притяжения" (а если есть, то обычно это - в папке с программой). Поэтому очень часто ini не попадают в Application Data. Если ты опытный программер с головой - это не проблема, ты можешь самостоятельно решить, где и как будет правильно. Для новичков же, чтобы они ничего не напутали, лучше дать совет: "свои настройки - в реестр"!

Это сообщение отредактировал(а) CodeMonkey - 15.6.2009, 11:16

в общем-то да, я оказался не прав, никакого отключения по умолчанию не будет.

Это сообщение отредактировал(а) Akella - 30.7.2008, 09:42

Блин, ты сам упертый наглухо   Кто тебе сказал что у меня не лицензионный виндовс ? Самая что не на есть настоящая лицензия с ключом активации.

ZBugz, тише, тише

Добавлено через 1 минуту и 6 секунд
Откуда участникам дискуссии знать какой у тебя windows, лицензионный или нет? Тем более такие вопрос не прилично задавать, это типа как у девушки про возраст спрашивать.   

Ну все верно, я не спорю, просто смотря на что и с какой целью и для  пишеться софт, это нужно брать в расчет. Так что для пользователей, может и реестр хорошь, в моем случае INI для корпорации, а универсально тогда наверное будет так, если нельзя в ini, значит в реестр и наоборот  

Добавлено через 50 секунд

Боша не буду  

Это сообщение отредактировал(а) ZBugz - 30.7.2008, 14:17

Я тоже использую ini активно, так легче программу по локалке распростанять. Одну настроил и раскопировал по остальным компам. Особенно если настроек много. А после переустановки ОС достаочно вернуть каталог программы в сад и ссылку создать на рабочем столе. Тут уж нужно смотреть самому программисту по месту, так сказать. Может что-то удобнее в реестре, что-то удобнее на диске.

Это сообщение отредактировал(а) Akella - 30.7.2008, 14:21

Akella, читал твой последний пост, сразу возникла идея про экспорт и импорт настроек. Потом так думаю: "а куда же экспортировать?". Ответ пришел сразу... в ini   

Интересная ссылка в тему про настройки:
Beware of roaming user profiles

А можеш подсказать где можно почитать требования к сертификации программ Microsoft'ом?

http://www.google.com/search?q=Windows+Vis...tware+Logo+Spec
http://www.google.com/search?q=Windows+XP+Software+Logo+Spec

По поводу сохранения ини рядом с прграммой в программ файлс.
Виста спокона даст туда сохранить ни чего не сказав, но зайдя под другим пользователем файла там не будет т.к фактически он будет хранится C:\Users\Frees\AppData\Local\VirtualStore\Program Files\Project1\
причем из программы у меня так и не получилось узнать куда на самом деле упал файл

Frees, не верю, покажи код сохранения

http://www.sql.ru/forum/actualthread.aspx?tid=577551

Добавлено через 49 секунд
проверять наличие файла надо под админом

А зря ;)


Это механизм виртуализации. Ещё одни костыли для кривых программ, чтобы они не упали при обновлении Windows: Управление учетными записями пользователей Windows Vista: взгляд изнутри (Марк Руссинович) Registry Virtualization in Windows Vista
Но о виртуализации в этом топике речь не шла.

Для определения, виртуализирован ли процесс, нужно получить его токен и вызвать GetTokenInformation с TokenVirtualizationEnabled (TOKEN_INFORMATION_CLASS Enumeration).

Это сообщение отредактировал(а) CodeMonkey - 31.7.2008, 12:12

зато шла о сохранений в програм файлс

Вопрос был задан о том, как правильно делать.
А вы говорите, что пишите как хотите - виртуализация всё скроет. Отличный ответ.

Всё равно как на вопрос "в чём писать программы для Windows" ответить "в Turbo Pascal-е".

я не имел в виду токого!

я просто хотел обратить внимание на проблемы которые могут возникнуть если писать в ини и ложить его рядышком

Прошу прощения, что не так вас понял.


Возможно, стоило акцентировать на этом внимание, потому что вашу фразу

я понял именно так, как указал выше.

Спасибо.

Лично моё мнение:
Если нужно эти сохранённые параметры менять, то однозначно INI файл. 
Если это просто сохранение параметров, которые никто явно менять не будет - реестр.
Если речь о базе данных, многие параметры, общие для всех, можно (и нужно) хранить прямо в базе.

Почему INI: Потому что в реестре я могу соохранить ключ-(подключ)-значение. А потом ты откроешь реестр, найдёшь ключ EnableSmartEnumeration и долго будешь чесать репу что это за параметр, и за что отвечает. А в ini я напишу:

И у тебя не будет сомнений.

Ну, если уж так придираться, то можно написать толковый help, в котором будут описаны все параметры реестра и что они делают. И это будет более профессионально, чем коментарии в ini.

можно ещё сказать, что в реестре проще хранить многостроковые и двоичные данные. Плюс иерархия против одного уровня, плюс возможность установки прав на каждый ключ, плюс наличие встроенного специализированного редактора. Ммммм....  может ещё что забыл.

Достаточно сравнить механизмы:
1.
 а) Открыть help, найти информацию о ключах и о том какой ключ за что отвечает.
 б) Открыть Regedit, найти этот ключ, исправить.

2.
 а) Открыть INI почитать за что отвечает ключ, тут же исправить.

Второе явно проще. Насчёт доступа - это не вопрос реестра. Это вопрос бизнес-логики программы кому и к каким параметрам давать доступ. С реестром согласен только в плане иерархических данных (частично) и двоичных - там действительно это будет удобнее. Но опять же, выносить эти вещи в доступные настройки, имхо, ни к чему. Правке адвансед-юзером подлежат только простые параметры, которые не могут привести к краху приложения! Визуальные настройки среды (хотя это лучше и делать визуально, через окно настроек, чтобы пользователь тут же видел результат), какие-то параметры отображения данных, и так далее.

О чем вообще речь? С каких это пор настройки программ меняются не выставлением "галок" и выбором из менюшек, а ковырянием в файлах? Вы явно чуток отстали от технологий...

вот уже учусь сохранять параметры прямо в базе, для определнных прог. А для других сохраняю в ini файле - так как параметры и настройки в программе постоянно меняются . С реестром пока тяжеловато.  Не освоил еще никак   

Хоть мы немножко ушли в топике в сторону, но я думаю, что стоит сказать ещё пару слов про виртуализацию, а то многие даже не в курсе, что она есть (не говоря уже про то, зачем она нужна). Пост навеян топиком Как сохранить настройки в файле под Vista?
Виртуализация позволяет работать в Vista старым кривым программам, которые пытаются писать свои даные в не предназначенные для этого места (Program Files, Windows и т.п.). Она предназначена только для обеспечения совместимости.
Если такая програма под обычным пользователем пытается писать файл, например, в Program Files, то вместо этого она будет работать с файлом в папке C:\Users\<имя-пользователя>\AppData\Local\VirtualStore\Program Files. Очевидно, что для новой программы такая попытка приведёт к возврату ошибки "в доступе отказано". Кроме того, также очевидно, что такая старая программа будет работать только в Vista, в XP она не работала изначально (имеется ввиду - под обычным пользователем).
Виртуализирован ли процесс можно определить в диспетчере задач (Task Manager) - просто добавьте столбец "Виртуализация". Про программное определение я уже сказал выше.

Как Windows определяет, старая программа или новая? 
Виртуализация включается если:

• процесс 32-разрядный.
• процесс запущен интерактивным пользователем.

Виртуализация не включается:

• если процесс 64-разрядный
• для процессов администратора
• для служб
• для вызовов с олицетворением
• для приложений с манифестом, в которых указан requestedExecutionLevel

Как отключить виртуализацию? Во-первых - можно создать стандартный манифест с настройками (см. например http://www.google.com/search?&q=reques...utionLevel+MSDN ). Во-вторых, используя SetTokenInformation с TokenVirtualizationEnabled можно отключить виртуализацию программно. И, наконец, можно щёлкнуть правой кнопкой по процессу в Диспетчере Задач и выключить её из контекстного меню.

Это сообщение отредактировал(а) CodeMonkey - 4.10.2008, 15:25

Довольно неплохой обзор "ini-файлы VS реестр" (Реймонд Чен): Why are INI files deprecated in favor of the registry? (также рассматривается XML).

Это сообщение отредактировал(а) CodeMonkey - 4.10.2008, 15:28

Я в своих проектах делаю так...
По запуску программа читает "стартовые" параметры из ini файла, переданного ей в качестве параметра (если ничего не передавалось, то ищется ini файл в папке с программой, имя файла совпадает с имененм программы). Сделано для того, что бы можн было легко переносить программу мжду пользователями, а так же легко, с помощью ярлыков создавать разные окружения для одного пользователя. В этом файле настроек по минимуму (например, настройки соединения с базой данных, путь к ветке в HKCU/Software куда сохраняются остальные настройки, да еще пара-тройка параметров, которые после установки не требуют изменения, например, номер терминала, или какой-нить уникальный код приложения).
Все остальные настройки пользователя (как то размер и положение окон и фреймов) - по указанному в ини ключу в HKCU.
Все настройки специфичные для компьютера (которые не изменяются от пользователя к пользователю) - в HKLM/Software... Тем самым блокруется изменение этих настроек самими пользователями, без участия администратора.
Вот, сопсна, все

Ура  Купил видуху и два новых харда, сделал рэйд, воткнул Vista, хорошо что вспомнил про INI.
Сразу же поставил свою программу, Vista с нуля, даже без дравов, все насройки изначальные. Программа сохраняет настройки в C:\Program Files\Программа, сохранил настройки, вообще проблем не возникло. Так что ini легко работает в Viste по умолчанию.

Мы у себя используем везде ini.

Какие плюсы:

1. Софт запросто переживает переустановку винды. Многие винду-то и не хотят только из-за этого переставлять - на перенастройку софта нужно убить иногда неделю работы. Очень жалко, что, например, делфя не хранит свои установки в инишке, а все файлы - в одной, своей, папке. Винду из-за этого переставить не представляется возможным - просто работа встанет.
2. Софт запросто переживает атаку вирусов. Даже если вся винда и все экзешники мёртвые, то можно всё за 1-2 часа переставить. Иначе - возня, в лучшем случае, на полдня. Хотя, я понимаю, что лучше предохраняться, чем потом лечится - однако, что твоится у юзеров - сами знаете.
3. Инишку проще править руками, если параметры имеют хорошие названия (это же, правда, и частичный минус).
4. Софт проще настраивать на множестве установок - просто раскопировал инишку - и везде всё будет работать гарантировано одинаково.
5. Софт проще удалённо отлаживать. Инишки бывают достаточно толстые, множество параметров, и, что бы юзера долго не пинать - что у него и как настроено - проще забрать себе инишку, реально неоднократно помогало.

Добавлено через 12 минут и 2 секунды
Насчет Висты. Да - наваротили они там те еще навороты...
Что нужно, что бы инишки хорошо работали под вистой? Писать в какую-нибудь попку, доступную для записи юзеру (мы пишем в AppData - она одна для всех юзеоров) и добавить в экзешник (или рядом с ним) ресурс - манифест. Ну и с инсталлером есть особенности. Но, в целом, работать можно.

1 и 2, в данном случае, одно и то же ;).
Я для себя уже давно решил, что все настройки будут храниться в xml - больше возможностей + расширять проще.

ИНИ всего лишь придуманный стандарт официальный или нет - это не имеет значение, так что привязка к ОС тут вообще не причем... 

Читай с самого начала внимательнее. Спор был про INI и ее совместимость по дефаульту в Vista. Все прекрасно работает.

Это сообщение отредактировал(а) ZBugz - 17.11.2008, 20:57