[mikls]

При работе с обычным lisp файлом для записи в файл использовалась команда вида (setq FILE (open fullpath "w")), где fullpath - это полный путь к текстовому файлу в формате txt. Но при загрузки сборки vlx/fas/prv, в которую был добавлен текстовый файл, программа перестала работать, так как по указанному пути текстового файла нет (данный файл находится в сборке). Как правильно указать путь к файлу в данном случае? И еще вопрос: будут ли сохраняться изменения в текстовом файле внутри сборки или перезаписанный текстовый файл хранится где-то в другом месте?

[nolte]

во во тоже ломаю голову над этим, прибавь еще DCL файл (куда то надо его положить дабы диалог запустить). пока что теория моя следующая: положить в корневой каталог автокада, или посмотреть в настройках пути файлов, предположить и проверить, что одинаковы для разных версий када и перенести туда TXT и DCL файлы, прописав их в лиспе предварительно. Весь вопрос путь этот правильный или нет пока что не проверял это только теория, если кто может высказаться по этому поводу сэкономит нам с mikls уйму времени.

[Дима_]

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

[mikls]

Да, если текстовый файл физически лежит в какой-то папке, и в лиспе прописан этот путь, то все работает. Но только не понимаю какой тогда смысл класть в сборку текстовый файл, если все-равно работаю с другим файлом? Просто хотелось скрыть текстовый файл от просмотра, а получается можно в сборку положить только lisp-файл, а в папку со сборкой (или другую папку заранее прописав в лиспе путь к ней) скопировать тестовый файл.

[Andrey_13]

Сообщение от Дима_ з.ы. а вобще я против dcl...

А какую вы предлагаете альтернативу для создания диалоговых окон?

[gomer]

Текстовые файлы можно внедрять в vlx-приложение и читать оттуда, но тогда их нельзя будет изменить. Использование относительных путей позволяет использовать файлы из подпапок. Тут проблема скорее в организации, чем в лиспе...

[nolte]

gomer,
если я включил DCL в сборку, то вопрос как к ней обратиться какой путь прописАть

[Дима_]

Сообщение от Andrey_13 А какую вы предлагаете альтернативу для создания диалоговых окон?

Их множество и в зависимости от задачи что-то может быть более, менее удобней - пути решения есть opendcl (я его правда не разу не использовал), можно через связку COM, можно через импорт Net/Arx функций-оберток, можно просто через запуск стороннего exe файла - который "отвечает" подключившись через тот-же com обратно автокаду (здесь плюс, что регестрировать ничего не надо - только exe'шник найти), либо отвечает через какие-нибудь более "олдскульные" вещи типа реестра или файла (ихмо это если совсем туго с автокадом). На сейчас я пользуюсь "своей внутренней" сырой недоделкой вызова классов из .Net библиотек (любых, только чтоб версия Net и версия автокада совпадали - такой аналог импорта системных vla...), в том числе и WinForms например.
то notle - по моему просто имя_файла.dcl - в сборке он сам найдет.

[gomer]

Сообщение от nolte какой путь прописАть

Никакой, просто имя файла с расширением. В таком случае автокад будет искать сначала внутри vlx-модуля, а уж потом на диске

[nolte]

Проверю (осталось только dcl и лисп к нему дописать ). Спасибо

[Дима_]

Сообщение от nolte Проверю (осталось только dcl и лисп к нему дописать

Молодец повеселил!

[Andrey_13]

Сообщение от Дима_ Их множество и в зависимости от задачи что-то может быть более, менее удобней

Как вариант иногда стоит вообще обойтись без диалога, использовав getint, getkword и т. п. функции.

[mikls]

С текстовым файлом такой вариант почему-то не работает (FILE nil).

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

Как пример работы с dcl без предоставления dcl: http://autolisp.ru/2010/03/15/dcl-dialogs-create/

[gomer]

Сообщение от Кулик Алексей aka kpblc пример работы с dcl без предоставления dcl

как по мне, от лукавого эта писанина, зачем, если диалог особой ценности не несет, да и не всегда можно писать на диск, куда хочешь

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

В %temp% можно писать всегда. Иначе 90% программ работать просто не будут.

[gomer]

Сообщение от Кулик Алексей aka kpblc В %temp% можно писать всегда. Иначе 90% программ работать просто не будут.

Это если есть место на диске ...

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

Ага, и если есть компьютер

[gomer]

Был у меня один случай, когда программа (тв-плейр) отказывалась работать, оказалось она сама накидала в темп гигабайтные файлы по самое не хочу и ей банально не хватало места для слива

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

gomer, ты собираешься на dcl писать диалоги размером в несколько гигов? Ну ты даешь

[ShaggyDoc]

Если говорить про внедрение текстовых файлов в VLX, то в этом нет никакого смысла. Да, теоретическая возможность есть. При этом фактически текстовый файл просто "прикопируется" в конце VLX. Точно также можно, например, командой copy "прикомпилировать" данные к EXE. Но толку от этого мало.

Данные в файлах надо хранить отдельно - чтобы их можно было изменять. Никакой "защиты" этих текстов нет. Точно так же незачем компоновать в VLX и DCL-файлы. Это только лишние хлопоты для себя. Какие могут быть "секреты" в DCL?

И если отбросить всю эту "прикомпоновку", то остается FAS-файл. Вот в нем есть большой смысл. Это и защита кода и увеличение производительности. Защита кода - от "обезьяны с гранатой", чтобы не "улучшали". Но квалифицированный специалист всегда и без вскрытия кода напишет такую же программу, а скорей всего еще лучше. Ну, если конечно в коде не запрятана какая-то уникальная формула - "тады ой".

Конечно, DCL безнадежно устарел. Альтернатив полно (см. #8). Замечу, что OpenDCL (на мой взгляд) самый тупиковый путь, да его уже и забросили. Не стоит тратить время на изучение дополнительных оболочек с неизвестной перспективой - лучше уж освоить оригинал. Считается "модным" .NET - так и осваивайте эту платформу.

[gomer]

А, спорить с вами бесполезно... Замечу, что OpenDCL уже доступен для автокад 2015, не смотря на финансовые затруднения. Раннее была анонсирована поддержка zwcad.