| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Реестр или ini ?
Пастор © (2002-07-05 08:57:00)Как вы думаете, где лучше хранить настройки программы ?
Александр (2002-07-10 13:41:00) [1]Самое лучшее решение - INI. Реестр и так всем збит, если каждый туда все будет заносить, о система будет работать медленнее. Работать с ИНИ удебнее и бысрее. Плюс эо совесем не зависит от ОС и этот файл можно скопировать куда угодно.
Евген (2002-07-10 11:52:00) [2]
> Doctor Deejay ©
Я извиняюсь, а можно какое-нибудь описание компонента и желательно с примерами.
cyborg (2002-07-08 16:44:00) [3]Dmk © EXEшник гораздо легче править чем расшифровать данные, можно извратиться так, что ни кто расшифровать не сможет, разве только лет через 100.
dimanew (2002-07-08 06:21:00) [4]> Виктор Щербаков
Если нужна древовидная структура используй XML. IMHO очень
удобно.
Dmk (2002-07-08 02:14:00) [5]2 cyborg © (07.07.02 08:50)
Кул хацкер Вам и Exe поправить может :)
С Уважением.
Anatoly Podgoretsky (2002-07-07 09:49:00) [6]AL2002 © (06.07.02 22:32)
Администратор ничего тебе заводить не будет, есть папка для хранения пользовательских настроек, вот в ней и храни, после этого быстро придешь к мысли о правильном написании программ.
cyborg (2002-07-07 08:50:00) [7]Dmk © шифровка это не защита от пользователя, а защита от кул хацкеров. Пользователю тыщу лет не надо лазить по файлам программы.
AL2002 (2002-07-06 22:32:00) [8]Не, шифровка — это как вариант.
>Пастор
INI можно где угодно хранить. Нехай админ заводит папочку, где можно INI держать, вот и всё.
Dmk (2002-07-06 21:50:00) [9]Простите за любопытство, но что же это за программы такие вы пишите, что настройки надо защищать от User"a? Они могут привести к краху программы? или системы? в случае если пользователь что-нибудь не так настроил.
Пастор (2002-07-06 21:32:00) [10]Сам я всегда использовал ini но вот подумал, может лучше перейти на reg.. Из всех ответов я понял, что лучше всего это ini, но на некоторых компьютерах администратором запрещена запись в Program Files и в таком случае моя прога работать не будет ?
Тогда у меня возникает вопрос - насколько много таких компьютеровс такими администраторов, т.е. какая вероятность того, что моя прога не заработает ?
PS: всем спасибо за интерес к этой теме !
GrayFox (2002-07-06 21:03:00) [11]в регедите5,0 возможно два типа файла, в который экспортируются настройки (ключи): win9x/NT4 Registration Files (Regedit4) и Registration Files (RegEdit5) . Первый тип привычнее - обычный текстовый файл, второй вроде бинарный.
Из API функций надо использовать RegSaveKey and RegRestoreKey (есть правда еще RegLoadKey, RegReplaceKey, но там судя по справке какие-то ограничения)
AL2002 (2002-07-06 20:55:00) [12]Вариант!
GrayFox (2002-07-06 20:51:00) [13]если настройки в реестре хранятся, то можно просто сохранить рег файл с настройками, всего делов-то
AL2002 (2002-07-06 20:22:00) [14]Thanxx за компонет. Пока неясно только в какой палитре он появится. А чё это за XTools? А адресок не кинешь?
AL2002 (2002-07-06 20:19:00) [15]Я не про падение, а стремление майкрософта к централизации.
Зачем это им нужно? Такое ощущение, что для того чтобы вести статистику что юзеры юзают и что у них проинсталлено. (я не параноик, просто само напрашивается). Вот это мне и не нравится.
wicked (2002-07-06 19:26:00) [16]хех... вот ведь как получается... одним из основных аргументов, прозвучавших здесь против использования реестра было то, что это рекомендуется Майкрософтом...
воистину, умом Россию не понять и мегабайтом не измерить...
аргумент про падение виндовс вообще притянут за уши, так как при этом у пользователя совсем другие проблемы, нежели сохранение настроек пары утилит... для того, чтобы такого не было, достаточно вшить в программу набор стандартных настроек и предусмотреть вариант, когда нужной ветки в реестре попросту не окажется...
единственным аргументом против реестра могу назвать случаи, когда его вообще использовать нерационально... например, в программах автозапуска компакт-дисков (камень и плевок в сторону киевского то "диво")...
а в общем, можно подвести итог - использовать надо то, что целесообразней, что легче использовать в данном случае и с чем имеется опыт работы...
Doctor Deejay (2002-07-06 19:16:00) [17]Вот и компонент
====================================================
unit xRegistr;
{ let"s you access windows registry easy as ini-file replacement }
interface
uses
Windows, Classes, Dialogs,
SysUtils, Controls, Graphics, Forms,
Registry;
type
TRegBranch = (rbClassesRoot,rbCurrentUser,rbLocalMachine,
rbUsers,rbPerformanceData, rbCurrentConfig,rbDynData);
TxRegistry = class(TComponent)
private
FRegistry : TRegistry;
FItem : String;
FValue : String;
FOnChange : TNotifyEvent;
procedure SetKey(const Value: String);
function GetKey: String;
procedure SetItem(const Value: String);
procedure SetBranch(const Value: TRegBranch);
function GetBranch: TRegBranch;
public
constructor Create(aOwner:TComponent); override;
destructor Destroy; override;
function ReadString: String;
procedure WriteString(const Value: String);
function ReadInteger: Integer;
procedure WriteInteger(Value: Integer);
function ReadBool: Boolean;
procedure WriteBool(Value: Boolean);
function DeleteKey: Boolean;
function DeleteItem: Boolean;
procedure EnumKeys(Strings: TStrings);
procedure EnumItems(Strings: TStrings);
published
property Branch: TRegBranch read GetBranch write SetBranch;
property Key: String read GetKey write SetKey;
property Item: String read FItem write SetItem;
property OnChange: TNotifyEvent read FOnChange write FOnChange;
end;
procedure Register;
implementation
{ TxRegistry }
constructor TxRegistry.Create(aOwner: TComponent);
begin
inherited Create(aOwner);
FRegistry:=TRegistry.Create;
FRegistry.OpenKey("Software\",True);
FItem:="";
end;
destructor TxRegistry.Destroy;
begin
FRegistry.Free;
inherited Destroy;
end;
procedure Register;
begin
RegisterComponents("xTools", [TxRegistry]);
end;
procedure TxRegistry.SetKey(const Value: String);
begin
if Value<>GetKey then
begin
FRegistry.CloseKey;
FRegistry.OpenKey(Value,True);
if Assigned(FOnChange) then FOnChange(Self);
end;
end;
function TxRegistry.GetKey: String;
begin
Result:=FRegistry.CurrentPath;
end;
procedure TxRegistry.SetItem(const Value: String);
begin
if Value<>FItem then
FItem:=Value;
end;
procedure TxRegistry.SetBranch(const Value: TRegBranch);
var
aKey: String;
begin
if Value<>GetBranch then
begin
aKey:=GetKey;
case Value of
rbClassesRoot : FRegistry.Rootkey:=HKEY_CLASSES_ROOT;
rbCurrentUser : FRegistry.Rootkey:=HKEY_CURRENT_USER;
rbLocalMachine : FRegistry.Rootkey:=HKEY_LOCAL_MACHINE;
rbUsers : FRegistry.Rootkey:=HKEY_USERS;
rbPerformanceData: FRegistry.Rootkey:=HKEY_PERFORMANCE_DATA;
rbCurrentConfig : FRegistry.Rootkey:=HKEY_CURRENT_CONFIG;
rbDynData : FRegistry.Rootkey:=HKEY_DYN_DATA;
end;
SetKey(aKey);
end;
end;
function TxRegistry.GetBranch: TRegBranch;
begin
case FRegistry.Rootkey of
HKEY_CLASSES_ROOT : Result := rbClassesRoot;
HKEY_CURRENT_USER : Result := rbCurrentUser;
HKEY_LOCAL_MACHINE : Result := rbLocalMachine;
HKEY_USERS : Result := rbUsers;
HKEY_PERFORMANCE_DATA: Result := rbPerformanceData;
HKEY_CURRENT_CONFIG : Result := rbCurrentConfig;
HKEY_DYN_DATA : Result := rbDynData;
end;
end;
{ deletes a key and all his subbranches }
function TxRegistry.DeleteKey: Boolean;
begin
Result:=FRegistry.DeleteKey(Key);
end;
{ Deletes one Value from the branch }
function TxRegistry.DeleteItem: Boolean;
begin
Result:=FRegistry.DeleteValue( FItem);
end;
{ Enumerates all subkeys for a key }
procedure TxRegistry.EnumKeys(Strings: TStrings);
begin
FRegistry.GetKeyNames(Strings);
end;
{ Enumerates all values for a key }
procedure TxRegistry.EnumItems(Strings: TStrings);
begin
FRegistry.GetValueNames(Strings);
end;
function TxRegistry.ReadString: String;
begin
Result:=FRegistry.ReadString(FItem);
end;
procedure TxRegistry.WriteString(const Value: String);
begin
FRegistry.WriteString(FItem,Value);
end;
function TxRegistry.ReadBool: Boolean;
begin
Result:=FRegistry.ReadBool(FItem);
end;
procedure TxRegistry.WriteBool(Value: Boolean);
begin
FRegistry.WriteBool(FItem,Value);
end;
function TxRegistry.ReadInteger: Integer;
begin
Result:=FRegistry.ReadInteger(FItem);
end;
procedure TxRegistry.WriteInteger(Value: Integer);
begin
FRegistry.WriteInteger(FItem,Value);
end;
====================================================
Doctor Deejay (2002-07-06 19:15:00) [18]Это компонента. Просто сохрани содержимое в пас-файл и инсталлируй. Работает как с реестром, так и с ини. Взял из xTools, но последняя версия была под Д3, поэтому пришлось переделать.
А по поводу обсуждаемой темы, то я ближе к ини, но в последней моей проге без реестра не обошлось, т.к. нужно было сохранить параметры, которые зависят от данной звуковухи. Ну а т.к. прога без инсталляции, то при переносе на другой комп начнется что-то страшное....
Но если можно обойтись без реестра, то лучше без него обойтись. Он и тормознутый к тому же. Кто не верит - пусть вспомнит как ACDSee при инсталляции регистрирует свои расширения в реестре. На моем P1 200 MMX этот процесс занимает секунды 3. А если не 20 записей нужно сделать а под 1000.
Короче ини намного шустрее, да и руками править можно. А если кому пароли хранить нужно, так реестр не поможе. Тут шифровать нужно :)
Удачи
AL2002 (2002-07-06 16:58:00) [19]Я вообще уважаю проги, которые не нужно инсталлировать. Зверею, когда у 50Кб-й проги запускается инсталлшилд и реестр замусоривается. INI лучше. А крякнуть прогу, которая в реестре что-то там запишет для своей "защиты" тоже элементарно.
Да и вообще, если Гей-Тс что-то навязывает – значит, это делать не надо.
Вот если б компоненту какую, чтобы с ИНИ хорошо работала... (мечтательно)
cyborg (2002-07-06 16:02:00) [20]Anatoly Podgoretsky © интересно, а как же тогда программы пишут файлы? Что, вообще нельзя становится писать что ли?
| |
Страницы: 