[Айнар]

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

[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]

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