Re: VBA vs LISP

> bender
Не, может я отупел от Лиспа :))) с его скобками :))), но всё же повторю:
At module level, you can use only comments and declarative statements. ИМХО, это значит, что я должен внутри каждой процедуры, где используется этот массив, каждый раз проверять его (функцией isEmpty, если не ошибаюсь), и при необходимости - инициализировать {этой вашей Sub qqq(), кстати, спасибо за код, по VBA нет хороших книг, а писать на нём приходится}. Быстродействие, повторю ещё раз, пострадает, и совершенно зазря - ведь массив надо проинициализировать только один раз ! И это не случайность, а закономерность, так как в Бейсике At module level, you can use only comments and declarative statements.. Впрочем, я заповторялся :)))
Оффтоп: Знатоки Бейсика, подскажите пожалуйста, где разжиться исходниками высокого качества и уровня с комментариями, чтобы изучать приёмы программирования на этом ..., ......., ..., но очень любимом в Редмонде языке. Может, книгу подскажете. (интересуют именно образцы ПРАВИЛЬНОГО кодирования на VBA). Со своей стороны, могу подсказать, где взять исходники на Лиспе - Express Tools, идут вместе с Автокадом, но устанавливаются отдельно.

Re: VBA vs LISP

Maxim T пишет:

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

Для тех кто в танке. Вы пробовали сделать так, как я написал? И что не работает?
Чтобы было понятнее - пункт д).

Dim myArrNew As Variant
myArrNew = ThisDrawing.GetMyArr

PS
Проверка переменной на массив - IsArray.

Re: VBA vs LISP

> bender
Из пункта г) вашего постинга > bender (2004-07-17 14:03:34)
следует, что функция qqq, инициализирующая массив, вызывается из Лиспа, а не из Бейсика. Поэтому я и написал повтор своего вопроса > Maxim T (2004-07-17 19:35:06). Извиняюсь, что приходится повторяться в третий раз, но танкисты, к которым вы меня причислили, - народ упрямый:). Итак, чтобы не множить пустословие, резюмирую:
Бейсик в принципе не может сделать то, о чём я писал в первом постинге > Maxim T (2004-07-16 19:33:23) (повторять лень).
Ну да ладно, это замяли (какой спрос с Бейсика, это ж не Лисп;))).

Re: VBA vs LISP

> Maxim T
Из п. г моего постинга ни хрена не следует.

^C^C_.-vbarun;myProect.dvb!ThisDrawing.qqq;

Вот за что люблю всяческих фанатов (в том числе LISPа) так это за непробиваемую упертость. Резумирую: в VBA, в рамках ОДНОГО ПРОЕКТА, можно ОДИН РАЗ инициализировать какую-нибудь переменную и потом использовать ее в любой момент сеанса работы АКАДа, в любой процедуре или функции ДАННОГО ПРОЕКТА.
А VBA действительно не может многого из того, что может LISP. Но как написал > ShaggyDoc (2004-06-30 10:03:28)

Давайте корректней - если есть достоинства, то их не замалчивать.

Добавлю: а в предмете, о котором говорите, надо разбираться.

Re: VBA vs LISP

> bender
Можно, можно. Только не из самого VBA, а из Лиспа или из меню. Можно ещё из ObjectARX (наверное), можно ещё из внешней проги-клиента, написанного на чём угодно. Для обсуждаемой темы важно то, что из самого VBA - низя. Ну никак низя вызвать вашу qqq один раз именно из VBA, без внешней "помощи". А эмоции - не аргумент.

Re: VBA vs LISP

Для Maxim T:
1) "Не, может я отупел от Лиспа" - не может, а точно.
Прежде, разберись с языком VB (или VBA), а затем задавай вопросы.
2) Ответ на твой вопрос: объяви переменную как Public и используй ее в любом месте и в любое время (только по назначению).

Re: VBA vs LISP

Maxim T пишет:

Можно, можно. Только не из самого VBA, а из Лиспа или из меню.

Вы прикалываетесь или издеваетесь? Какие на хрен эмоции? Стандартная команда АКАДа vbarun, это что "внешняя помощь"?

Re: VBA vs LISP

bender пишет:

Стандартная команда АКАДа vbarun, это что "внешняя помощь"?

ИМХО, по отношению к VBA-коду - именно ВНЕШНЯЯ. И хватит эмоций. Я в самом начале > Maxim T (2004-07-16 19:33:23) написал объясните, пожалуйста, мне - лисперу, весьма плохо знающему VBA. Раскрою страшную тайну - я вообще только начал изучать VBA. И все мои "находки" - это взгляд новичка, а не "приколы и издевательства". На VBA я перехожу потому, что в Автолиспе реакторы глючат при работе в многодокументном режиме (ещё одна страшная тайна).
Сейчас поставлю свою задачу более абстрактно. Надо исполнить код один раз, при ПЕРВОЙ загрузке DVB-файла, не важно, из какого документа. Код должен инициализировать в цикле глобальную (т.е. Public) переменную-массив.
На лиспе я пишу декларации "процедур" и код вперемешку, допускаются также вложенные декларации, допускается даже декларирование новых "процедур" во время исполнения.
На VBA, насколько я понял, At module level, you can use only comments and declarative statements. То есть, сначала определяем переменные, потом - декларации процедур (под ними понимаются Sub и Function). Есть ещё Event handlers и Form procedures (последние хранятся в .FRM файлах). Все процедуры хранятся в памяти и "ждут своего часа", то есть события или вызова ИЗВНЕ (меню, комстрока, клиент activeX, ...). Вот в этом и отличие от Лиспа, где при загрузке файла СРАЗУ ПРОИСХОДИТ его интерпретация. Не длинно написал ?
Теперь код:

Const bn = 5
Public a(bn) As Integer
For i = 0 To bn
  a(i) = i
Next i

слева вверху написано General, справа вверху - Declarations.
Жмём Debug > Compile acad project, получаем окошко "Compile error: invalid outside procedure" на третьей строке кода. Значит, код For надо запрятывать в процедуру, которая может быть вызвана на исполнение только извне. НЕ из Бейсика. Это просто факт, нельзя танк заставить летать, я не издеваюсь. Просто после Лиспа непривычно.

Re: VBA vs LISP

1) Внутри процедур и функций Public не объявляется.
Const bn = 5
dim a(bn) As Integer
For i = 0 To bn
  a(i) = i
Next i
2) Если хочешь, чтобы переменная была видна в любом месте модуля, то достаточно в самом верху (до первого объявления Sub или Function) её прописать: dim
3) Ну, а если хочешь, чтобы вообще везде была видна, то через Public (но опять таки выше всего).
Но, внимание: в твоем случае - ничего не выйдет, т.к. тебе, судя по задаче, хочется создать динамический массив, а он создается и объявляется не так. :)

Re: VBA vs LISP

1) А мой код не "внутри процедур и функций". Я же написал под кодом пояснение:

слева вверху написано General, справа вверху - Declarations

То есть это уровень модуля, а не процедуры.
2) см. первый пункт
3) то же самое, у меня в примере она Public, и "выше всего".
То есть я просто открыл VBA-редактор в пустом чертеже, ткнул мышкой ThisDrawing на диаграмме Project (она слева вверху экрана), и набрал этот свой пример. Никакой функции или процедуры там (и вокруг) и близко нет, чистый Module-level.
Кстати, динамический массив мне не нужен, меня устроит:

Const bn = 5
Public a(bn) As Integer

Re: VBA vs LISP

Const bn = 5
Public a() As Integer
[b]Sub beginArr()[/b]
Dim i As Integer
For i = 0 To bn
  ReDim Preserve a(0 To i) As Integer
  a(i) = i
Next
End Sub

Ответить постараюсь завтра.

Re: VBA vs LISP

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

какой спрос с Бейсика

А басик - он как был 20 лет назад примитивным так и остается

Хотя это и очень по нашенски:

Пастернака я не читал, но гневно осуждаю.

У людей, мало-мальски понимающих о чем идет речь, ничего кроме раздражения такой подход к дискуссии вызвать не может. Повторюсь: в предмете надо разбираться, а критиковать аргументированно.
По сути. Так дело у Вас не пойдет. Метод научного тыка конечно самый лучший метод, но вначале разберитесь с основными понятиями языка: переменные и константы, их типы, "время жизни" и "область видимости", процедуры, функции, события уровня приложения, документа и т. п. Лучше всего почитать что-нибудь из разряда "VBA для чайников".
Далее небольшой ликбез, коротенько. В модуле есть область описания (Declarations) в которой и объявляются константы, переменные и функции, и определенные разработчиком процедуры (функции), в которых эти самые константы, переменные, функции используются. После того как Вы объявили (инициализировали) переменную ей присваивается значение "по умолчанию": String - пустая строка, Boolean - False, Long - 0, Variant - Empty и т. д. "Свое" значение им присваивается в определенной Вами процедуре (функции). После чего в зависимости от "времени жизни" и "области видимости" ("локальная" или "глобальная" переменная) она и используется в других процедурах (функциях). Лично я предпочитаю не использовать "глобальных" переменных, а получать их значения так, как и описал в > bender (2004-07-17 14:03:34). Но это дело вкуса и привычек. Public конечно проще. Ну а Вы пытаетесь присвоить ей в цикле значения в области описания. Естественно будет ошибка. Ну а Ваш код будет приблизительно такой.

Option Explicit
Option Base 0
Option Compare Text
'Объявляем глобальную переменную
Public myArr As Variant
'Записываем данные в объявленную переменную
Public Sub createMyArr()
Const myPrompt = "Введите верхнюю границу массива"
Dim upperBound As Integer, i As Integer, tempArr() As Integer
'Получаем верхнюю границу массива
upperBound = ThisDrawing.Utility.GetInteger(vbCr & myPrompt & " - ")
If IsNumeric(upperBound) = True Then
    For i = 0 To upperBound
        ReDim Preserve tempArr(0 To i) As Integer
        tempArr(i) = i
    Next
    myArr = tempArr
Else
    MsgBox "Очепятка, однако!", vbCritical, myPrompt
End If
End Sub
'Читаем данные. Эта процедура может быть в другом модуле.
Public Sub readMyArr()
Const myPrompt = "Чтение массива из глобальной переменной"
Dim i As Integer, tempStr As String
If IsArray(myArr) = True Then
    tempStr = "В массив записаны следующие значения:" & vbCr & vbTab
    For i = LBound(myArr, 1) To UBound(myArr, 1)
        tempStr = tempStr & myArr(i) & vbCr & vbTab
    Next
    MsgBox tempStr, vbInformation, myPrompt
Else
    MsgBox "Ошибка инициализации массива.", vbCritical, myPrompt
End If
End Sub

Еще пару слов. Опять же на мой вкус лучше не использовать динамические, а тем паче статические массивы. Возникают трудности с их проверкой. А лучше использовать переменные типа Variant (так, как в приведенном коде). Это первое. И второе. По поводу использования переменных "всегда и везде". Буду очень рад ошибиться, но по моему уважаемый 3dcad не прав. Повторю: переменную, объявленную как Public в каком-нибудь модуле проекта, можно использовать во всех других процедурах (функциях) этого самого проекта, но нельзя использовать в другом проекте. Поправьте меня, если я заблуждаюсь.
И последнее. Вы просили

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

http://www.cad.dp.ua/stats/a_vba/
Очень хорошие примеры, практически энциклопедия по программированию на VBA для АКАДа. Ну и справка, конечно.

Re: VBA vs LISP

Опровергаю сам себя.

переменную, объявленную как Public в каком-нибудь модуле проекта, можно использовать во всех других процедурах (функциях) этого самого проекта, но нельзя использовать в другом проекте

Можно. Для этого необходимо установить ссылку (Tools - Reference) на нужный проект. Имена проектов (свойство Name) не должны совпадать, есессно.
Но тут тщательнее надо.

Re: VBA vs LISP

Не хотел я ввязываться в эту абсолютно безидейную дискуссию, но прислушаемся к мнению Гуру.
Как уже неоднократно указывал глубокоуважаемый ShaggyDoc, преимуществом VBA перед VLisp (а тем паче перед просто Lisp) является возможность вызова функций из обычных библиотек. Несколько примеров:
1. Функция индикатора процесса из библиотеки acad.exe.
https://www.caduser.ru/forum/topic4358.html
2. Функция очистки журнала команд из библиотеки acad.exe.
http://www.cad.dp.ua/stats/a_vba/conten … #clear_com
3. Функция изменения цвета объектов с помощью стандартного диалогового окна АКАДа из библиотеки acad.exe. http://www.cad.dp.ua/stats/a_vba/conten … olorDialog
4. Функция вызова окна выбора цвета Windows из библиотеки comdlg32.dll.
http://www.cad.dp.ua/stats/a_vba/conten … olorChoice Dialog API
5. Функция вызова стандартных окон "Открыть файл" и "Сохранить файл" из библиотеки comdlg32.dll.
http://www.cad.dp.ua/stats/a_vba/acobject.html#API OPENFILENAME
6. Функция выбора папки в диалоговом режиме из библиотеки shell32.dll.
http://www.cad.dp.ua/stats/a_vba/acserv … eForFolder

Re: VBA vs LISP

> bender
Спасибо за библиотеку ссылок.

Re: VBA vs LISP

Интересная дискуссия. Но факт есть факт VBА - де-факто стандарт программирования приложений под Windows ---> если смотреть шире AutoCAd, то IMHO, безусловно, VBA (попробуйте, например, связать AutoCAD и Excel на LISP)

Re: VBA vs LISP

По поводу топика
Опыт работы
С,С++,ARX,Лисп,VisualLisp,VB,VBA
Казждый язык имеет свои +++ и ---
Графика - Лисп, VisualLisp
Филы, ДБ, Евенты(реакторы) - VB, VBA (ща добавилось посднее связывание :))))
Вычисления, сортировки, новые команды С,С++,Лисп
Если надо все вместе - строй проект
Например у меня был один проект, в котором было >50 лисп филов(~500 ф-ций),>10 ARX-ов, 20 DCL-ей, 5 MNS-ов i 5 MNL-ей, 10 VBA proectov + все ето работало с внешими VB и Си программами

Re: VBA vs LISP

Sigma пишет:

попробуйте, например, связать AutoCAD и Excel на LISP

Даже пробовать не буду, а сделаю это
http://www.cad.dp.ua/stats/content.php? … 2004g.html
Как сказал bender (2004-07-20 21:55:37)
а в предмете, о котором говорите, надо разбираться.

Re: VBA vs LISP

А еще можно и на Assemblere.

Re: VBA vs LISP

... да лучше прямо в кодах ...

Re: VBA vs LISP

> cadhelp (2004-09-02 00:50:52)
поддерживаю. для конкретной задачи свой язык. Что то проще и быстрее сделать в лиспе, что-то в VBA, что то приходится делать в ObARX.
Так что спор по поводу какой язык лучше не корректен. Важен не язык, а его знание и умение им пользоваться.
По поводу связи с Excel- это как раз тот вариант когда можно использовать lisp, но лучше использовать VB(Знакомый один на лиспе даже к базам foxpro обращался... просто лиспом вызывал внешнюю программу и через txt файл передавал ей параметры...) так что все можно... важно на каком языке это удобнее и быстрее реализовать.
а если вспомнить первый пост, то судя по нему человек не до конца определился что ему изучать... VB проще.не лучше, не хуже, ПРОЩЕ для понимания на начальном этапе.

Re: VBA vs LISP

> Но
факт есть факт VBА — де-факто стандарт >программирования приложений под Windows ---> >если смотреть шире AutoCAd, то IMHO, >безусловно, VBA (попробуйте, например, связать >AutoCAD и Excel на LISP)
Вот уж выдумки. Если смотреть шире, то лисперам VisualLisp или AutoLisp вообще нафиг не сдался. Если говорить о стандартном Лиспе, то это либо Common Lisp, либо Scheme. Любая приличная реализация Лиспа умеет работать с COM и вызывать любые функции из DLL, в чем проблема связать AutoCAD и Excel на Лиспе ?
По сути по сравнению с Лиспом, VB - это некий проблемно ориентированный язык (правда не понятно на какую именно задачу он ориентирован) с фиксированной семантикой, связывающий опытных пользователей и тем более программистов по рукам и ногам.
Если говорить, про скриптование, то в качестве встраимого языка сейчас чаще встречается Python, который имеет с Лиспом весьма много общего.

Re: VBA vs LISP

Вот недорогая коммерческая реализация (200$) Common Lisp: http://www.cormanlisp.com
Для нее где-то была сразу библиотечка под AutoCAD.
Вот подороже, но с неплохой IDE:
http://www.lispworks.com
тут поддержка COM лучше сделана
Правда это просто скриптующим пользователям скорее всего будет сложновато. Все равно, что с VB на С++ пересаживаться.

Re: VBA vs LISP

> Lisper
Если речь идет вообще о lisp'е, то Вы наверное правы, а вот в контексте программирования под AutoCAD (IMHO)следет пользоваться исключительно встроенным VisualLisp - в противном случае не избежать подводных камней. VBA я не рассматриваю как класс (пусть не обижаются на меня его поклонники) - если уж программировать на basic'е под AutoCAD, то использовать VB.NET (хотя я предпочел бы C#). В AutoCAD 2007 его возможности уже практически покрывают возможности VisualLisp, а в плане создания интерфейса он уже далеко впереди. Кроме того в этой версии его очень несложно "сшивать" с VisualLisp, т.е. можно создавать на VB.NET функции которые свободно вызываются из VisualLisp с возможностью передачи параметров и получением результата, что при использовании VBA<->VisualLisp сделать значительно сложнее и менее эффективно.