[Айнар]

Подскажите пожалуйста как сделать в ЛИСПе, чтобы при следующем вызове команды по умолчанию выводился по умолчанию параметр введенный ранее. типа вот этого: "Specify fillet radius <0.0000>:"

[gomer]

Объявляй переменную глобально или пиши в реестр...

[hwd]

Сообщение от Айнар Подскажите пожалуйста как сделать в ЛИСПе, чтобы при следующем вызове команды по умолчанию выводился по умолчанию параметр введенный ранее. типа вот этого: "Specify fillet radius <0.0000>:"

Смотря что понимается под "ранее":
1. "Ранее" в текущем сеансе работы
2. "Ранее" в предыдущих сеансах работы

Если (1), то gomer прав насчёт использования глобальной переменной.
Если (2), то хранить подобные настройки в реестре - не лучшая идея, под это дело лучше бы подошёл xml-файл (имхо).

[Disney]

Сообщение от gomer Объявляй переменную глобально или пиши в реестр...

Ты думаешь, если бы Айнар, знал о том что такое глобальные переменные или тем более реестр, он бы задал такой вопрос?

Сообщение от AutoLISP и Visual LISP в среде AutoCAD К локальным переменным относятся переменные, имена которых заданы при описании функций либо в перечне аргументов, либо в перечне рабочих переменных. Такие переменные существуют только внутри функции, в которой они определены, и их значение не передаются наружу. Остальные переменные, который не являются локальными, считаются глобальными, и им отводиться специальное место в именном пространстве текущего документа и в текущем сеансе работы

Для ввода предыдущего значения, по-умолчанию
[IMG]http://s42.***********/i095/1009/48/f34422ffe6be.gif[/IMG]
, я использую конструкцию вот такого типа:

Код:

[Выделить все]

(defun c:test (/ entered_value)
  (setq	Einar_last_entered_value_test
	 (if Einar_last_entered_value_test 
	   Einar_last_entered_value_test 
	   0 
	 )
	entered_value
	 (getreal
	   (strcat
	     "\nВведите значение <"
	     (rtos Einar_last_entered_value_test)
	     ">: "
	   )
	 )
	entered_value
	 (if entered_value
	   entered_value
	   Einar_last_entered_value_test
	 )
	Einar_last_entered_value_test
	 entered_value
  )
)

. где entered_value - локальная переменная, Einar_last_entered_value_test - глобальная переменная.

Сообщение от hwd лучше бы подошёл xml-файл (имхо).

Можно по подробнее, давно хочу чтоб "ранее" было не только в текущем

[Айнар]

Нужно "Ранее" в предыдущих сеансах работы

[E-degtyarev]

Нужно "Ранее" в предыдущих сеансах работы

Для таких вещей я использую простые текстовые файлы используя функцию (open "......" "w") и (open "......" "r"). может не красиво, но работает.

В качестве основы для записи и считывания файла взял команду Appload из R13, реализованную Lisp-ом. (см. вложение)

[Do$]

http://forum.dwg.ru/showthread.php?t...E0%ED%ED%FB%F5

[hwd]

Сообщение от Disney Сообщение от hwd Смотря что понимается под "ранее": 1. "Ранее" в текущем сеансе работы 2. "Ранее" в предыдущих сеансах работы ...лучше бы подошёл xml-файл (имхо). Можно по подробнее, давно хочу чтоб "ранее" было не только в текущем

Можно. Озвученный видео-пример с исходниками разместил здесь.

[EfremenkoDO]

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

Код:

[Выделить все]

;;;FileName 	- имя файл ini
;;;Section 	- секция ini
;;;key 		- ключ ini
;;;Default	- значение по умолчанию (если не обнаружит значения в фале)
(defun read-ini	(FileName Section Key Default / IniSection str)
  (setq File (open FileName "r"))
  (if (= File nil)
    (progn
      Default
    )
    (progn
      (setq IniSection (strcat "[" (strcase Section) "]"))
      (setq str (read-line File))
      (setq temp T)
      (while (and (/= str "///")
		  (/= (strcase str) IniSection)
	     )

	(progn
	  (setq str (read-line File))
	  (if (= str nil)
	    (setq str "///")
	  )
	)
      )
      (if (= str "///")
	(progn Default)

	(progn
	  (setq str (read-line File))
	  (if (= str nil)
	    (setq str "///")
	  )
	  (while

	    (and (/= str "///")
		 (/= (strcase (substr str 1 (vl-string-search "=" str)))
		     (strcase Key)
		 )
		 (/= (substr str 1 1) "[")

	    )
	     (progn
	       (setq str (read-line File))
	       (if (= str nil)
		 (setq str "///")
	       )
	     )
	  )
	  (close File)
	  (if (= (strcase (substr str 1 (vl-string-search "=" str)))
		 (strcase Key)
	      )
	    (progn
	      (setq str (substr str (+ 2 (vl-string-search "=" str))))
	      str
	    )
	    (progn Default)
	  )
	)
      )
    )
  )
)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;запись в ини

(defun write-ini (FileName   Section	Key	   Value
		  /	     IniSection	str	   Lstr
		  insertion  elem	curSection
		 )
  (setq insertion :vlax-false)
  (setq File (open FileName "r"))

  (if (= File nil)
    (progn
      (setq Lstr
	     (append Lstr (list (strcat "[" (strcase Section) "]")))
      )
      (setq Lstr (append Lstr (list (strcat Key "=" Value))))
    )
    (progn

      (setq str (read-line File))
      (if (= (substr str 1 1) "[")
	(setq curSection (strcase str))
      )

      (while (/= str nil)
	(progn
	  (if
	    (and (/= (strcase (substr str 1 (vl-string-search "=" str)))
		     (strcase Key)
		 )
		 (= (strcase curSection)
		    (strcat "[" (strcase Section) "]")
		 )
	    )
	     (progn
	       (setq Lstr (append Lstr (list str)))
	     )
	     (progn (if	(/= (strcase curSection)
			    (strcat "[" (strcase Section) "]")
			)
		      (setq Lstr (append Lstr (list str)))
		    )
	     )
	  )


	  (if (= (strcase str) (strcat "[" (strcase Section) "]"))
	    (progn
	      (setq Lstr (append Lstr (list (strcat Key "=" Value))))
	      (setq insertion :vlax-true)
	    )

	  )
	  (setq str (read-line File))
	  (if (/= str nil)
	    (if	(= (substr str 1 1) "[")
	      (setq curSection (strcase str))
	    )
	  )
	)
      )


      (if (= insertion :vlax-false)
	(progn
	  (setq	Lstr
		 (append Lstr (list (strcat "[" (strcase Section) "]")))
	  )
	  (setq Lstr (append Lstr (list (strcat Key "=" Value))))
	)
      )
      (close File)
    )
  )

  (setq File (open FileName "w"))
  (if (/= File nil)
    (progn
      (foreach elem Lstr (write-line elem File))
    )
  )
  (close File)
)

[hwd]

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

"Работать" и "хранить свои настройки" - это не одно и то же. Работать нужно уметь и с реестром, поскольку AutoCAD много чего хранит именно в нём. Если говорить о том, в каких файлах хранить свою информацию, то возможно (но не обязательно) следует учитывать возможности языка, на котором программист пишет. Если кто-то пишет на языке, который не имеет в своём арсенале функций по работе с xml, но имеет функции для работы с текстовыми файлами, то возможно, что такому разработчику будет удобней работать с ini-файлом (хотя, честно говоря, я не вижу совершенно никаких трудностей в том, чтобы с тем же успехом создавать xml). Если же в языке функционал для работы с xml имеется, то лучше использовать xml, а не ini, поскольку возможно, что в дальнейшем с файлом ваших настроек потребуется работать из внешних приложений или же тот, кто будет писать код - будет писать его на языке, умеющем работать с xml. Если это будет ini-файл, то программисту придётся тратить своё время на написание парсера. А ежели это будет xml - этого делать не придётся.

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

Если коротко - я против ini-файлов.

Offtop: з.ы. Хотя на данном форуме преобладают лиспописатели, которым вопросы совместимости и удобства поддержки, к сожалению побоку.

[zamtmn]

>>Если коротко - я против ini-файлов.
стоит учесть что за данные планируется хранить, если не особо структурированные, например несколько не связаных значений - зачем xml?

Если коротко - я против тотальной подсадки на xml. а за пихание всякой лабуды в реестр - нужно руки отрывать. иногда плакать хочется глядя в regedit... зачем это там?

[Кулик Алексей aka kpblc]

ИМХО: ini превосходно подходит для одноуровневой организации информации.
xml - для сложноструктурированной.
Но и то, и другое (по крайней мере с точки зрения лиспа) требует обращения к файлам, то есть достаточно медленные операции. Мне кажется (подробных исследований не проводил), что доступ к реестру будет осуществляться быстрее.
Как бы то ни было, все равно хранение информации надо продумывать - любой механизм можно угробить

[hwd]

Сообщение от zamtmn если не особо структурированные, например несколько не связаных значений - зачем xml?

имхо - для порядка. Что произойдёт, если юзер подправит такой ini-файл, случайно поменяв местами две строки? В xml можно автоматически проверять структуру файла и его содержимое на корректность (с помощью xsd-схем). А как вы проверите ini-файл? Можно конечно проверить, но для этого нужно будет писать опять же кучу кода.

любой механизм можно угробить

Чтобы этого не случилось, как раз и существуют xsd-схемы. По ним можно даже сгенерировать нужный xml-файл с нуля.

[Кулик Алексей aka kpblc]

Сообщение от hwd Что произойдёт, если юзер подправит такой ini-файл, случайно поменяв местами две строки?

А ничего Если, конечно, реализация чтения-записи грамотная

[hwd]

Сообщение от Кулик Алексей aka kpblc А ничего Если, конечно, реализация чтения-записи грамотная

А если он укажет не допустимое значение? Тоже ничего, если "грамотная реализация". Но ты упускаешь один момент - эту реализацию нужно писать. В случае использования xml - эта реализация уже есть в виде xsd-схем.

[Кулик Алексей aka kpblc]

Андрей, ты про схемы-то не это, не тово... В общем, не надо
Для затравки несколько функций, которые я использую для работы с ini-файлами (используется некоторое количество библиотечных функций, но суть от этого меняется мало).

[hwd]

Сообщение от Кулик Алексей aka kpblc ты про схемы-то не это, не тово... В общем, не надо

поясни

[Do$]

Удалено

[zamtmn]

>>Тоже ничего, если "грамотная реализация"
Без грамотной реализации и xml не поможет.
Я не спорю xml - индустриальный стандарт... но тут в основном не професионалы. Есть некоторый предел сложности данных до которого xml - излишество

[ShaggyDoc]

С INI-файлом ничего не произойдет, даже если поменять местами строчки. Вручную. И с юзером ничего не произойдет. Правильная программа (не такая примитивная как в #9) прочитает информацию. И хранить в INI можно структурированную (несколько уровней) информацию. Достаточно задавать соответствующие имена секций и переменных.

А вот с XML, при всех его несомненных преимуществах для многих целей все гораздо сложнее. Требования к синтаксису более строгие. Жестокие! XML должен быть и valid и well-formatted. Да еще, возможно, соответствовать какой-нибудь XSD-схеме.

И "что произойдет если юзер подправит такой XML-файл"? Даже не меняя местами строки? XML от таких правок также ничем не защищен.

Но для работы с XML необходимы дополнительные парсеры, причем гораздо более сложные, чем для INI. Вот hwd всё время на XML напирает потому что работает с .NET. А посади его в другую среду? Хотя бы в "чистый WIN-api" с написанием программы в "Блокноте"? Вот и кончился весь XML.

Поэтому все неоднозначно. В случаях с настройками, например "последним значением" нет смысла применять сложные решения.

за пихание всякой лабуды в реестр - нужно руки отрывать. иногда плакать хочется глядя в regedit... зачем это там?

Обычные рассуждения начинающих программистов. Которые, типа, пишут программы, круче чем вся Microsoft. Плакать хочется и пацталом валяться.

Руки им надо отрывать за то, что лезут с regedit.

[hwd]

Сообщение от Кулик Алексей aka kpblc Для затравки

Загрузил файл _kpblc-ini-datas-read.LSP. Смотрю функцию _kpblc-ini-datas-read

* Параметры вызова: * file имя файла. Если файла нет, возвращает nil

Не всё выслал?

[Кулик Алексей aka kpblc]

Конечно, не все. Я выложил для анализа кода (ну и надеюсь, что получу рекомендации по улучшению )

[hwd]

Конечно, не все. Я выложил для анализа кода (ну и надеюсь, что получу рекомендации по улучшению кода )

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

Как видим - получена ошибка.
Содержимое тестового ini-файла:

Код:

[Выделить все]

[файлы настроек]
localsettingsfile=C:\Documents and Settings\All Users\Application Data\GpsmCAD\LocalSettings.xml
[каталоги]
[файлы библиотек]

[Кулик Алексей aka kpblc]

Уговорил. Попробую все в один файл засунуть... Дай только примерно часа 2 - срочной работы немеряно.

[hwd]

Сообщение от Кулик Алексей aka kpblc Уговорил. Попробую все в один файл засунуть... Дай только примерно часа 2 - срочной работы немеряно.

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

[EfremenkoDO]

Сообщение от ShaggyDoc Правильная программа (не такая примитивная как в #9) прочитает информацию

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

[Кулик Алексей aka kpblc]

В #24 добавил полностью работающие коды (lsp и fas)

[hwd]

Сообщение от ShaggyDoc И "что произойдет если юзер подправит такой XML-файл"? Даже не меняя местами строки? XML от таких правок также ничем не защищен.

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

Но для работы с XML необходимы дополнительные парсеры, причем гораздо более сложные, чем для INI.

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

А посади его в другую среду? Хотя бы в "чистый WIN-api" с написанием программы в "Блокноте"? Вот и кончился весь XML.

Давайте не будем обсуждать сферического коня в вакууме. Мы живём в то время, когда существует множество удобных технологий и ориентироваться на ситуации вроде "а что, если у тебя будет только мэнфрэйм и перфокарты" - это глупо (имхо). У каждого из нас всегда будет под рукой то программное обеспечение, которое нам нужно для работы.

с написанием программы в "Блокноте"

Писать .net-код можно и в блокноте, скомпилировав затем исходники с помощью csc.exe. Это уж если кому охота поизвращаться....

[zamtmn]

Обычные рассуждения начинающих программистов. Которые, типа, пишут программы, круче чем вся Microsoft. Плакать хочется и пацталом валяться. Руки им надо отрывать за то, что лезут с regedit.

Ну вы видимо не много программ устанавливаете из интереса. я этим грешен...

Случай из жизни: Звонит коллега - "ВСЁ ПРОПАЛО". выполнял срочный заказ пользуясь одним небезизвестным и недешовым электротехническим сапром (последние технологии от микрософта, проект - база данных, net, xml, кароче всё серьезно). сломался винт. восстановил данные за деньги в спец.конторе. Всё вроде восстановилось, а проект не открывается - программа падает при открытии... от последней резервной копии - 3 дня авральной работы. Вскрытие показало, что программу валило отсутствие нескольких файлов нулевой длинны, файлы не были восстановлены т.к. не содержат данные. создал их руками и чудо - всё заработало

[hwd]

>Алексей Кулик
Да Лёша, теперь заработало. Есть одно маленькое замечание, показываю скрин:



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

Ну и... пустые группы в результирующем списке отсутствуют (хотя возможно это так тобою и задумано...).

[Кулик Алексей aka kpblc]

Пробелы не удалял, т.к. как-то не видел файлов с пробелами в начале и / или конце ключа. Поэтому и не предусматривал.
Пустые группы как-то тоже не видел: либо есть хранимая информация, и тогда нужны и группы, и ключи, либо этой информации нет, и ставить пустые заглушки туда смысла никакого. Это - не xml, тут валидность не настолько жестко определяется
Сугубо ИМХО.

[Дима_]

ИХМО по этому вопросу - в каком формате и где содеражть внутренние данные программы - дело сугубо личное и выбирать только исходя из задачи - форматы файла расчитанные на то, что с ними будет работать другая программа или в ручную править юзер - это бред и аттавизм (тем более если под net), если подразумеваеться использовать данные из другой программы - нужно сделать импорт\экспорт в формат под задачу - это может быть и xml, но как формат передачи данных - ихмо он не очень (в 90% случаев csv гораздо эффективней, да и библиотек для него не меньше) т.к. чтоб разобрать его программа должна четко знать (догадываться-то они пока не умеют) ,что и с каким полем нужно делать - xml удобен для хранения (в зазипованном виде) "сложновложенных" данных с "прицелом" на расширение формата (самое толковое и правильное применение в openoffice) - там он (XML) более чем оправдан, а в остальном, тем более если мы говорим про современные языки, никаких "ручных" правок файлов и залезание в "чужие" файлы быть не должно - для этого есть графические формы и протоколы обмена информацией между приложениями (com как минимум) - эксель фалы вы как програмно редактируете (читаете)?, а dwg - правильно вызывая сам эксель, автокад - вот это и есть правильный подход.
з.ы. для чего "чужой" программе лезть в Ваши настройки без Вашего участия лично для меня вопрос, а тем более если это документировать - это получаеться мне перед каждым действием проверять - не поменялись ли мои-же настройки?

[hwd]

Сообщение от Дима_ выбирать только исходя из задачи - форматы файла расчитанные на то, что с ними будет работать другая программа или в ручную править юзер - это бред и аттавизм (тем более если под net)

То, что мною процитировано выше - это и есть "бред и атавизм" (с).
Привожу пример:
У меня имеется маленькая библиотека, которая при запуске автокада выполняет синхронизацию определённых локальных каталогов с серверными. Управление синхронизацией ведётся через xml-файл. Изначально никакого GUI не было запланировано (нужно было быстро написать решение стоящей задачи, а вносить исправления в xml приходится не часто). Однако... вручную такой файл править всё же не хочется - потому позднее написал отдельное, внешнее приложение, работающее вне AutoCAD и позволяющее визуально, через GUI выполнять настройки этого (и не только этого) xml-файла. Т.о. налицо взаимодействия со сторонней программой, о котором я и писал выше и которое Вы назвали "бредом и атавизмом" (с).

Могла возникнуть и такая ситуация, при которой этот самый GUI писал бы не я. Тогда тот, кто решал бы эту задачу, всё так же, без каких либо сложностей нацарапал бы это приложение, заюзав Linq to XML или др. технологию. Однако если бы это был самописный на коленках ini-файл или тот же csv, который в подобной задаче "не пришей кобыле веник" - этот разработчик вспоминал бы меня не самыми лестными словами, т.к. ему пришлось бы писать пусть небольшой, но всё же парсер для такого файла, вместо того, чтобы юзать готовое решение.

Сообщение от Дима_ если подразумеваеться использовать данные из другой программы - нужно сделать импорт\экспорт в формат под задачу - это может быть и xml, но как формат передачи данных - ихмо он не очень (в 90% случаев csv гораздо эффективней, да и библиотек для него не меньше) т.к. чтоб разобрать его программа должна четко знать (догадываться-то они пока не умеют) ,что и с каким полем нужно делать - xml удобен для хранения (в зазипованном виде) "сложновложенных" данных с "прицелом" на расширение формата (самое толковое и правильное применение в openoffice) - там он (XML) более чем оправдан,

Про "90% случаев csv"(с) - хранение настроек и передача данных - это разные вещи, не надо софистики. Если нужно экспортировать данные в Ecxel, то понятное дело, что следует юзать csv, а не xml.

Сообщение от Дима_ чтоб разобрать его программа должна четко знать (догадываться-то они пока не умеют) ,что и с каким полем нужно делать

А вот это действительно бред. Т.е. если программе передать не xml, а csv, то она каким-то образом "узнает" что с ним делать? Чтобы программка "знала", программист как раз и пишет код, в котором реализует логику этого "знания". Технологии, предназначенные для работы с XML оперируют данными, а не ищут смысл.

Сообщение от Дима_ а в остальном, тем более если мы говорим про современные языки, никаких "ручных" правок файлов и залезание в "чужие" файлы быть не должно - для этого есть графические формы и протоколы обмена информацией между приложениями (com как минимум) - эксель фалы вы как програмно редактируете (читаете)?, а dwg - правильно вызывая сам эксель, автокад - вот это и есть правильный подход. з.ы. для чего "чужой" программе лезть в Ваши настройки без Вашего участия лично для меня вопрос, а тем более если это документировать - это получаеться мне перед каждым действием проверять - не поменялись ли мои-же настройки?

для чего и почему - я привёл простой пример выше. Приложения могут со временем расширяться и то, как хранятся его настройки - тоже не маловажно, поскольку с этими настройками могут в последствии работать и др. приложения. Яркий тому пример - AutoCAD, хранящий свои настройки в реестре, в следствии чего работать с ними неудобно. Гораздо удобнее было бы, если бы они хранились в xml-файле.

[Дима_]

HWD - вы бы успокоились и посмотрели про что я пишу - а не цитировали весь пост с "опровержением" - работа с настройками между программами через файлы ЛЮБОГО формата это не есть правильный путь, они должны быть закрыты как методы в ООП - целиковые - а опреировать тем что другая программа не сможет работать с моими файлами работать - так это изначально тупиковый путь. Стандартный формат надо выбирать из удобства конкретной задачи, а не из "виртуальных" потребностей.

[hwd]

Сообщение от Дима_ работа с настройками между программами через файлы ЛЮБОГО формата это не есть правильный путь

Согласен, я и не предлагал любой формат, а предлагал конкретный - xml.

они должны быть закрыты как методы в ООП

Не согласен. Если в процессе расширения приложения, потребуется добавить в файл настроек новый блок настроек, то тогда придётся перекомпилировать код класса, в котором содержатся упомянутые вами методы. А если обращаться как к xml- документу, то никаких изменений вносить не придётся. Я всегда оставляю зазор на возможное расширение, поскольку не люблю переписывать код.

опреировать тем что другая программа не сможет работать с моими файлами работать - так это изначально тупиковый путь. Стандартный формат надо выбирать из удобства конкретной задачи

Что тупикового в том, чтобы заранее предусмотреть хранение настроек в таком формате, в каком его было бы удобно использовать внешним приложениям? Вопрос риторический. Конкретная задача - хранение настроек в виде, удобном для работы с ними не только текущему программисту, но и удобном для тех, кто придёт работать после.

Предлагаю завершить полемику - не вижу в ней смысла. Пусть каждый хранит настройки в том формате, в каком ему больше нравится, хоть на перфокартах.

[gomer]

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

[Дима_]

То hwd - вот смотри ты пишешь программу которая рисует и хранит, например, линии и как "впередмыслящий" ты хранишь их описание в xml и соответственно документируешь - мол для "внешнего" изменения или чтения надо работать с таки-ми-то параметрами. Да до определенного времени все хорошо, ты можешь расширить "функциоанал" с поддержкой предыдущих версий, например добавить параметр цвет, толщину линии и т.д. Но в один прекрасный момент ты понимаешь, что хранить в формате (начальная точка - конечная точка) тебе не очень удобно, а гораздо интересней хранить, например, начальная точка, длинна, вектор (по факту получилось что ты постоянно их пересчитываешь). И приходиться тебе для поддержки старых версий "тащить опендицит" в виде начальной-конечной точки, а с ним и альтернативный вектор - то есть избыточность как данных, так и вычислений, хотя тебе уже эти начальные и конечные точки нафиг не нужны - только процесс тормозят. В моем-же случае ты прото добавляешь новую функцию (пересчета из нового формата в старый) и все - весь остальной функционал работатет как и прежде, с полной совместимостью со старыми программами (они так и будут работать медленней т.к. делают постоянно лишние вычисления), но новые будут быстрей - ведь по факту ты уже оперируешь совсем другими данными.
p.s. и не забываем, что программа об изменении своих-же настроек другими, либо не знает (не оперативно), либо постоянно их переспрашивает (долго).
p.p.s. я все это время не про формат говорю - а про принцип - а принцип хранить "мультипрограмные" настройки в файле устарел со времен dos'а (это не наш dwg.ru'шный юзер а ОС).

[zamtmn]

Не согласен. Если в процессе расширения приложения, потребуется добавить в файл настроек новый блок настроек, то тогда придётся перекомпилировать код класса, в котором содержатся упомянутые вами методы

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

[randomizr]

из второй таблицы засовываю в массив.

Никак не могу понять, как сделать, чтобы при такой, например схеме:

[Кулик Алексей aka kpblc]

Еще раз, но по-русски.