[alex-63]

Господа, программирующие на AutoLispe подскажите функцию возвращающую, загруженные приложения (arx dbx lsp vlx fas etc)
аналог команды _appload где можно было бы узнать с какой директории загрузилось приложение. Меня интересует vlx приложение.

alex-63

[hwd]

ObjectARX - в командной строке набрать: _arx _c
Lisp - в командной строке набрать: _lsp _c

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

[ытя]

(vl-list-loaded-vlx) - возвращает список имён загруженных .vlx

[alex-63]

Меня интересует путь откуда загружено приложение.
Нужна функция похожая на (arx) но чтобы возвращала путь и имя приложения причем не только arx а lsp vlx
(getPathLoadedApplication)->'("c:\ProgramFile\Autodesk\acapp.arx" "c:\etc\test.vlx ... )

[gomer]

Сообщение от alex-63 Меня интересует путь откуда загружено приложение.

из лиспа никак

[hwd]

Я знаю как на .net, получить пути для lisp/net. Насчёт получения путей для vba/arx - может и их удастся, но я не пробовал. Если мне не изменяет память, средствами автолиспа получить такие каталоги не удастся (например функция лиспа вроде как не может определить полное имя файла из которого она вызвана). Т.о. чтобы дать лиспу функционал, запрашиваемый топикстартером - нужно писать обёртку, написанную на objectarx/.net (мне видится решение именно таким).

[gomer]

Сообщение от hwd Насчёт получения путей для vba/arx - может и их удастся

Удастся... стоит поискать... уже обсуждалось и не раз

[alex-63]

Написал сам на c++ используя класс acDocManager из objectArx неужели нет доступа к этому классу из autoLispa ?
Код прилагаю может кому пригодиться т.к считаю она должна быть библиотечной функцией и почему ее до сих пор нет ?
Жаль что autolisp все меньше поддерживают в autodesk.

Код:

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

	static int ads_getloadedapplication(void)
	{
		//----- Remove the following line if you do not expect any argument for this ADS function
		struct resbuf *pArgs =acedGetArgs () ;
		// TODO: add your code here         
		resbuf *prbRet  = NULL;
		resbuf *prbTail = NULL;			
		AcApDocument *doc = acDocManager->curDocument();  
//		acutPrintf(_T("File Name %s"),doc->fileName());
int lispAppCount = doc->GetCountOfLispList();
if(lispAppCount > 0){	
	for(int i =0; i<lispAppCount;i++){
		AcLispAppInfo* appInfo;		
		if(appInfo=doc->GetItemOfLispList(i))
		{
			if(prbTail) { 
				prbTail->rbnext = acutNewRb(RTSTR);
				prbTail=prbTail->rbnext;
			             } else 
			{
				prbTail=acutNewRb(RTSTR);
				prbRet=prbTail;
						 }
						 acutNewString(appInfo->appFileName ,prbTail->resval.rstring);		
                //acutPrintf(_T("\n %s"),appInfo->appFileName);
		}//if
	} //for

if( prbRet )
	{ 	    
		acedRetList( prbRet );		
		acutRelRb( prbRet ); 		

	} 

} else
		// TODO: Replace the following line by your returned value if any
{
		acedRetNil () ;
}

		return (RSRSLT) ;
	}

[gomer]

Сообщение от alex-63 Написал сам на c++ используя класс acDocManager из objectArx неужели нет доступа к этому классу из autoLispa ?

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

[Pastor]

...аналог команды _appload где можно было бы узнать с какой директории загрузилось приложение. Меня интересует vlx приложение.

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

Если нужно просто в коде vlx-файла определить, откуда этот vlx загружен, то при условии, что файл расположен по одному из путей поддержки AutoCAD, путь можно узнать (setq fullpath (findfile "ИмяФайла.vlx")).

[Александр Ривилис]

Сообщение от Pastor Если нужно просто в коде vlx-файла определить, откуда этот vlx загружен, то при условии, что файл расположен по одному из путей поддержки AutoCAD, путь можно узнать (setq fullpath (findfile "ИмяФайла.vlx")).

И при условии, что он загружался без указания полного пути к нему. Если есть два файла с одним именем в путях доступа AutoCAD и загружен по полному пути не тот, который находится при помощи (findfile ...) то путь будет неверным.

Сообщение от alex-63 Жаль что autolisp все меньше поддерживают в autodesk.

Как поддерживался, так и поддерживается.

Сообщение от alex-63 Код прилагаю может кому пригодиться т.к считаю она должна быть библиотечной функцией и почему ее до сих пор нет ?

Ты кажется не понимаешь природу Autolisp, когда функции могут генерироваться на лету, вообще без использования файлов.

[gomer]

А весь сырбор из-за того, чтоб менюшку подгрузить...

[alex-63]

Мне иногда надо загрузить autoLisp и иметь доступ к ресурсам(например файлу конфигурации) .
Если проект не указан в пути доступа в AUTOCAD то поиск при помощи функции findfile не возможен.
Бывает что несколько файлов с одинаковым именем расположены по разным директориям и какой файл загружен так же
удобно использовать выше написанную функцию на C++ используя ObjectArx.
Функция (getloadedlispapp) котороя возвращает то же самое что показано в диалоговом окне и команда appload
->("C:\\Program Files\\Autodesk\\AutoCAD 2012 - English\\Express\\acetutil.fas"
2012 - English\\R18.2\\enu\\support\\acad.mnl" "G:\\AutoLisp\\LIB\\ak_lib0.lsp"
"G:\\AutoLisp\\LIB\\ak_max_min.lsp" "G:\\AutoLisp\\LIB\\ak_util.lsp"
"G:\\AutoLisp\\EXCEL\\ak_EXCEL.lsp" "G:\\AutoLisp\\ak_tools.mnl" "C:\\Documents
and Settings\\Пользователь\\Application Data\\Autodesk\\AutoCAD 2012 -
English\\R18.2\\enu\\support\\acetmain.mnl"
"G:\\AutoLisp\\AK_STAIR\\AK_STAIR.VLX")
etc
Например загруженное приложение AK_STAIR.VLX не указано в пути Support File Search и доступ к файлу конфигурации AK_STAIR.ini
получить проблематично не имея function (getLoadedLispApp).

Возможно кто-то и использует autoLISP в ИИ и генерирует функции которые сами пишут функций, но для этого удобнее использовать Common Lisp
используя например defmacro и если вы используете эти библиотеки поделитесь, мне будет интересно.

[Александр Ривилис]

Сообщение от alex-63 Бывает что несколько файлов с одинаковым именем расположены по разным директориям и какой файл загружен так же удобно использовать выше написанную функцию на C++ используя ObjectArx.

А если загружены > 1 файла с одинаковым именем?
P.S.: Аналогичную функцию я написал 6 лет назад (здесь), но она оказалась невостребованной именно по причине "возможных вариантов", когда однозначно нельзя сказать какой это файл.

[Дима_]

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

[Александр Ривилис]

Сообщение от Дима_ но это получается большой гемор - непонятно из-за чего.

Точнее не понятно ради чего. И потом не забывай, что .NET можно грузить только командой (_NETLOAD), что уже само по себе не хорошо.

[hwd]

Нужно изначально писать код так, чтобы не пришлось под каждую лиспину добавлять очередную запись в каталоги поиска.
Для этого в каталогах поиска задаёшь всего один путь, например C:\AutoCAD\Addons\LISP.
Теперь каждого пакета лиспов создаёшь в этот каталоге свой подкаталог и кидаешь лиспы в него, а в коде этих лиспов поиск ресурсов задаёшь с учётом имени подкаталога в котором они находится.
Т.е. если твой пакет лежит в C:\AutoCAD\Addons\LISP\Sample, то в коде поиск всяких там dcl-файлов, иконок и т.п. нужно прописывать в виде "Sample\\ИмяФайла", а не просто "ИмяФайла", как зачастую пишут некоторые говнокодеры (по другому язык не поворачивается сказать).

Имея общий знаменатель в виде C:\AutoCAD\Addons\LISP (или др. путь - на твоё усмотрение) и обозначая поиск ресурсов с учётом родительского каталога, ты сразу же снимаешь с себя проблему необходимости добавлять под каждый каталог с лиспами свой путь в список поиска, зашлаковывая тем самым профиль автокада и снижая скорость его работы).

А если ещё и имена функциям будешь давать согласованные (начиная со своего префикса), а не такие как dt, pb, cmd1, www и т.п. - то сможешь ещё избежать и конфликтов имён.

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

Имхо

Сообщение от Александр Ривилис Точнее не понятно ради чего. И потом не забывай, что .NET можно грузить только командой (_NETLOAD), что уже само по себе не хорошо.

Здесь посмотрите код класса загрузчика (класс AcadPlaginsLoader, строки кода 287-299) - как видите, не только _NETLOAD...

[alex-63]

Не плохо бы иметь библиотеку OpenLibForAutolisp с исходными текстами на C++ C#Net VBNet VBA типа OpenDCL для AutoLispa
Господин Александр Ривилис написал 6 лет функцию скомпилировал, а исходников не выложил.
Пришлось тратить время. А время деньги ...
Например с подшивками AutoLIsp не дружит и неплохо бы иметь функции доступа к этому объекту ...

[hwd]

Сообщение от alex-63 Не плохо бы иметь библиотеку OpenLibForAutolisp с исходными текстами на C++ C#Net VBNet VBA типа OpenDCL для AutoLispa Господин Александр Ривилис написал 6 лет функцию скомпилировал, а исходников не выложил. Пришлось тратить время. А время деньги ... Например с подшивками AutoLIsp не дружит и неплохо бы иметь функции доступа к этому объекту ...

Писать одни и те же исходники отдельно на C#, отдельно на VB.NET - это полное извращение (одного языка достаточно). OpenLibForAutolisp (ещё и не понятно, какой функционал в него предполагает вгонять автор) - во первых писать никто не будет (а если и найдётся энтузиаст - надолго его не хватит); во вторых - зачем изобретать лыжи для лиспа, если это можно сделать на др. языке? Только для того, чтобы облегчить жизнь тем, кто окромя автолиспа др. языков не знает? Ну так это их проблемы, и решать тогда должны они же - пусть изучают языки и пишут на них доп. функционал для лиспа. Однако по факту, если они выучат др. язык, то под лисп писать уже не станут (это логично и верно), ибо смысл коню приделывать коньки, когда можно сразу уже писать на этом выученном языке... Можно конечно написать на дотнете команду, которая из автолиспа, к примеру, позволит создать образ DVD-диска, но только возникает вопрос: "а нахрена?"... Подход "всё_на_свете_делать_с_помощью_автолиспа" - это плохо, у автолиспа должна быть своя песочница, и эта песочница - автокад.

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

имхо

[Александр Ривилис]

Сообщение от hwd Здесь посмотрите код класса загрузчика (класс AcadPlaginsLoader, строки кода 287-299) - как видите, не только _NETLOAD...

Я про загрузку при помощи lisp.

Сообщение от alex-63 Господин Александр Ривилис написал 6 лет функцию скомпилировал, а исходников не выложил.

Не куда и некому было выкладывать. Вот так это выглядело тогда:

Код:

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

//-----------------------------------------------------------------------------
//----- acrxEntryPoint.h
//-----------------------------------------------------------------------------
#include "StdAfx.h"
#include "resource.h"

//-----------------------------------------------------------------------------
#define szRDS _RXST("")

//-----------------------------------------------------------------------------
//----- ObjectARX EntryPoint
class CGetLispInfoApp : public AcRxArxApp {

public:
  CGetLispInfoApp () : AcRxArxApp () {}

  virtual AcRx::AppRetCode On_kInitAppMsg (void *pkt) {
    // TODO: Load dependencies here

    // You *must* call On_kInitAppMsg here
    AcRx::AppRetCode retCode =AcRxArxApp::On_kInitAppMsg (pkt) ;
    
    // TODO: Add your initialization code here

    return (retCode) ;
  }

  virtual AcRx::AppRetCode On_kUnloadAppMsg (void *pkt) {
    // TODO: Add your code here

    // You *must* call On_kUnloadAppMsg here
    AcRx::AppRetCode retCode =AcRxArxApp::On_kUnloadAppMsg (pkt) ;

    // TODO: Unload dependencies here

    return (retCode) ;
  }

  virtual void RegisterServerComponents () {
  }


  // ----- ads_getlispfilepath symbol (do not rename)
  static int ads_getlispfilepath(void)
  {
    //----- Remove the following line if you do not expect any argument for this ADS function
    struct resbuf *pArgs =acedGetArgs () ;
    // TODO: Replace the following line by your returned value if any
    acedRetNil();
    // TODO: add your code here
    AcApDocument *pDoc = acDocManagerPtr()->curDocument();
    if (pArgs && pArgs->restype == RTSTR) {
      // Считаем, что передали имя lsp-файла
      int nLisp = pDoc->GetCountOfLispList();
      AcLispAppInfo *pLispInfo = NULL;
      for (int i=0; i < nLisp; i++) {
        if (pLispInfo = pDoc->GetItemOfLispList(i)) {
          char path_buffer[_MAX_PATH], drive[_MAX_DRIVE], dir[_MAX_DIR];
          char fname[_MAX_FNAME], ext[_MAX_EXT];
          _splitpath(pLispInfo->appFileName,drive,dir,fname,ext);
          strcpy(path_buffer,fname); strcat(path_buffer,ext);
          if (!stricmp(path_buffer,pArgs->resval.rstring)) {
            acedRetStr(pLispInfo->appFileName);
            break;
          }
        }
      }

    } else {
      // Нужно вернуть список путей ко всем загруженным lsp-файлам
      int nLisp = pDoc->GetCountOfLispList();
      AcLispAppInfo *pLispInfo = NULL;
      resbuf *rbb = acutBuildList(RTLB,RTNONE), *rb = rbb;
      for (int i=0; i < nLisp; i++) {
        if (pLispInfo = pDoc->GetItemOfLispList(i)) {
          char path_buffer[_MAX_PATH], drive[_MAX_DRIVE], dir[_MAX_DIR];
          char fname[_MAX_FNAME], ext[_MAX_EXT];
          _splitpath(pLispInfo->appFileName,drive,dir,fname,ext);
          strcpy(path_buffer,fname); strcat(path_buffer,ext);
          while (rb->rbnext) rb = rb->rbnext;
          rb->rbnext = acutBuildList(RTLB,RTSTR,path_buffer,RTSTR,pLispInfo->appFileName,RTLE,RTNONE);
        }
      }
      while (rb->rbnext) rb = rb->rbnext;
      rb->rbnext = acutBuildList(RTLE,RTNONE);
      acedRetList(rbb); acutRelRb(rbb);
    }

    return (RSRSLT) ;
  }

  // ----- ads_getarxfilepath symbol (do not rename)
  static int ads_getarxfilepath(void)
  {
    //----- Remove the following line if you do not expect any argument for this ADS function
    struct resbuf *pArgs =acedGetArgs () ;

    acedRetNil();
    if (pArgs && pArgs->restype == RTSTR) {
      HMODULE h = GetModuleHandle(pArgs->resval.rstring);
      if (h) {
        char buf[_MAX_PATH+1];
        if (GetModuleFileName(h,buf,sizeof(buf)-1)) {
          acedRetStr(buf);
        }
      }
    } else {
      AcDbVoidPtrArray* pApps = reinterpret_cast<AcDbVoidPtrArray*>(acrxLoadedApps());
      if (pApps==NULL) return RSRSLT;
      resbuf *rbb = acutBuildList(RTLB,RTNONE), *rb = rbb;
      for (int i=0;i<pApps->length();i++) {
        const char *arxname = reinterpret_cast<const char*>(pApps->at(i));
        HMODULE h = GetModuleHandle(arxname);
        char buf[_MAX_PATH+1];
        if (h && GetModuleFileName(h,buf,sizeof(buf)-1)) {
          while (rb->rbnext) rb = rb->rbnext;
          rb->rbnext = acutBuildList(RTLB,RTSTR,arxname,RTSTR,buf,RTLE,RTNONE);
        }
      }
      while (rb->rbnext) rb = rb->rbnext;
      rb->rbnext = acutBuildList(RTLE,RTNONE);
      acedRetList(rbb); acutRelRb(rbb);
      for (;pApps->length()>0;) {
        delete reinterpret_cast<char*>(pApps->at(0));
        pApps->removeAt(0);
      }
      delete pApps;
    }
    return (RSRSLT) ;
  }
} ;

//-----------------------------------------------------------------------------
IMPLEMENT_ARX_ENTRYPOINT(CGetLispInfoApp)

ACED_ADSSYMBOL_ENTRY_AUTO(CGetLispInfoApp, getlispfilepath, true)
ACED_ADSSYMBOL_ENTRY_AUTO(CGetLispInfoApp, getarxfilepath, true)

[Дима_]

В дополнение сказанному hwd - я вижу только одно "разумное" дополнение автолиспа - которое сделать сможет только автодекс - т.к. ни какой встроенный функционал такого не может - сделать интерфейс с Net (наподобие как в свое время добавили возможность работать с com объектами), вот это "реально" будет интересно - а всякие библиотеки примочки реализующие отдельные API это дело бессмысленное и бесконечное. Ну а если они еще и сам лисп "облагородят" (замыкания, макросы, отложенные вычисления, классы (хотя если сделать предыдущие вещи они (классы) будут нужны только для "приходящих" из ООП) и прочие "современные" фишки (хотя разрабатывались они 50-30 лет назад)) - то это вобще будет настоящий праздник (по крайней мере лично для меня).

[Pastor]

...я вижу только одно "разумное" дополнение автолиспа - которое сделать сможет только автодекс - т.к. ни какой встроенный функционал такого не может - сделать интерфейс с Net (наподобие как в свое время добавили возможность работать с com объектами),..

Совершенно реально написать .NET приложение к AutoCAD (назовем его NetCoupler.dll), экспортирующее в документ следующие лисп-функции:
1. (nc-get-object "путь_к_сборке" "полное_имя_класса") - создает объект указанного класса и возвращает дескриптор (например целочисленный).
2. (nc-invoke-method дескриптор "имя_метода" список_аргументов)
3. (nc-get-property дескриптор "свойство") - возвращает атомарное значение.
4. (nc-set-property дескриптор "свойство" значение) - устанавливает атомарное значение.
5. (nc-release-object дескриптор) - уничтожает объект.
Ограничения будут касаться только типов передаваемых и возвращаемых параметров - строки, целые числа, действительные числа и логические T и nil.

[Дима_]

Offtop: Да простит меня автор топика
То Пастор - все верно но есть одно существенное НО - которое перечеркивает всю красоту Вашего предложения (которое действительно вполне возможно написать + "конверторы" типов) - загрузите Вы, например System.Windows.Forms - "нарисуете" что угодно - а как на "кнопочку" действие повесите? лямбду (функцию) передать текущая модель не позволяет - только в виде строки - то есть надо парсинг лиспа СВОЙ писать (ну или тупо отправить его как есть в командную строку), но здесь велика вероятность что автокад просто в "удачный" момент вылетит (т.к. не поддерживает многопоточности), в vl придумали чудо называемое "реакторами" - которые работают ТОЛЬКО сами с собой - ни с какими "внешними" объектами - то есть по сути придеться целиком новый лисп писать - а в чем тогда смысл - проще готовый взять. Без помощи автодеска (своими силами) возможно только запуск функции без аргументов (ну или с фиксированными - что одно и тоже) - чтобы она сама "внешние" данные читала и исходя из них что-то делала - мне "такой хокей не нужен" - я быстрей на C# (никому не в обиду - это мои личные тараканы и предпочтения - язык хороший - с каждым годом все "человечней" становится и дальше от С уходит) буду писать чем на таком "недолиспе".

[alex-63]

Интересное решение предлагает господин из manusoft
Автоматический загрузчик AutoLisp
http://www.manusoft.com/resources/ar...ndloadvlx.html
LspLoad.arx переименовываем в наш проект .vlx
и тогда функция
(GetPathOfXXXXX) ГДЕ XXXXX - базовое имя модуля.

и вызвав ::GetModuleFileName( _hdllInstance, szPath, MAX_PATH );
Мы получаем что хотели.
Все гениальное просто.

[Pastor]

Не понимаю всех этих сложностей, если можно просто в файл acaddoc.lsp поместить набор инструкций для загрузки требуемых VLX-файлов.
Файл acaddoc.lsp кладется в некоторую директорию - общий корень для всех подгружаемых приложений. Корневой каталог любого приложения является непосредственным подкаталогом общего корневого каталога. Путь к общему корневому каталогу регистрируется в качестве пути поддержки AutoCAD (один единственный; то, о чем писал hwd в посте №17).
Тогда каждая инструкция загрузки vlx-модуля будет выглядеть следующим образом:

Код:

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

;;; Файл acaddoc.lsp
;;; Инструкции загрузки файлов приложений:
(load (strcat (vl-filename-directory (findfile "acaddoc.lsp")) "\\" "Корневой_каталог_приложения\\путь\\имя_файла.vlx")))

Тогда из кода vlx-файла узнать его собственное местоположение можно так:

Код:

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

(setq loadedfrom (findfile "Корневой_каталог_приложения\\путь\\имя_файла.vlx"))

Данный подход требует определенной дисциплины. А именно, не грузить что попало откуда попало, а организовать все подгружаемые приложения в систему каталогов: общий корневой каталог во главе и корневые каталоги приложений на следующем (нижележащем) уровне. Кстати файлы не обязательно должны быть vlx. Можно и lsp, и fas.

Offtop:
Для Дима_.
Речь не идет о использовании объектов любых классов из любых сборок.
Речь идет об использовании объектов классов, спроектированных для нужд лисп-приложений под AutoCAD и находящихся с соответствующих (самодельных ) сборках. Например, это может быть класс, реализующий нечто напоминающее AJAX и доставляющее с удаленных серверов lisp-код в виде текста (взгляд на AutoCAD, как на специализированный браузер, умеющий интерпретировать LISP-"разметку", имеет право на жизнь. Ему [автокаду] только надо помочь делать http-запросы GET и POST...) Или класс, реализующий некое модальное диалоговое окно (похожее на XML-меню от ShaggyDoc).
Эти сборки могут не использовать библиотеки AcMgd.dll и AcDbMgd.dll, т.е. гарантированно быть пригодными для любых современных и будущих версий AutoCAD. А могут и ссылаться на указанные библиотеки, и тем самым, ничем не отличаться от "штатных" .NET приложений для AutoCAD за исключением механизма их загрузки/использования.

[alex-63]

Для того чтобы использовать findfile необходимо добавить папку с AutoLisp ом в Support File Search Path
это хорошо когда у вас небольшой один проект где Lisp файлы в одном месте.

Но когда количество увеличивается возникают проблемы. Наверное даже есть ограничение на Support File Search Patch
Замечал что добавляешь пути к <Support File ... > а в следующий сеанс часть путей пропало.
Решение предложенное господином Mansur Mamkin ым очень красивое и изящное :
1. При установки своего приложения Autolisp имея заглушку arx можно создать автоматический загрузчик не вмешиваясь в acaddoc.lsp или acad.lsp
причем загружаются не только файлы в текущей директории а все вложенные файлы.
2. имеем доступ к файлам и ресурсам программы не используя findfile тк имеет некоторое неудобство выше указанное.

Кстати Мансур Мамкин припоминается написал функция для autoLisp вызов функции из любой DLL с произвольным количеством и произвольными типами данных. Достойная библиотечная функция увеличивающая возможности AutoLIspa.

[hwd]

Сообщение от alex-63 Для того чтобы использовать findfile необходимо добавить папку с AutoLisp ом в Support File Search Path это хорошо когда у вас небольшой один проект где Lisp файлы в одном месте. Но когда количество увеличивается возникают проблемы. Наверное даже есть ограничение на Support File Search Patch Замечал что добавляешь пути к <Support File ... > а в следующий сеанс часть путей пропало.

Я так понял - ты "на своей волне" и не читаешь то, что тебе пишут... Если ты нас всё-таки "почитываешь" - ещё раз вдумчиво прочти #17...

[alex-63]

И при установке прикладывать Вашу инструкции кому и куда устанавливать программу.

[hwd]

Сообщение от alex-63 И при установке прикладывать Вашу инструкции кому и куда устанавливать программу.

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

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

[Дима_]

Сообщение от hwd Я у своих пользователей убиваю такой шлак, даже не берусь его изучать/править, т.к. проще самому решение написать, чем за кем-то подчищать его хвосты (ещё и не факт, что написанные без ошибок).

Offtop: Боюсь это не только Ваша "проблемма" ИХМО 90% лисптописателей считают "свои" стандарты самыми правильными - и старательно изобретают велосипеды - по моему порядка здесь никогда не будет по причине "мультипрагмидности" (причем каждая в отдельности реализованна серединка-на-половинку) языка и как следствие - огромному диапазону уровней программирования (начиная с командных методов и до...)

[Vov.Ka]

какого уровня и объема вы (все) пишете приложения, что бы реально заморачиваться такой фигней?

[hwd]

Сообщение от Vov.Ka какого уровня и объема вы (все) пишете приложения, что бы реально заморачиваться такой фигней?

кто "вы" и какой "фигней"?