Нельзя ли как-то обойти необходимость сразу жестко указать расположение dll в VBA программе? Чтобы макрос искал ее, например, там же, где находится вызывающий файл. Скажем в ..\Library\ ?
А то даже у Уокенбаха написано - поместить в системную директорию.
Формально вроде все просто, если правильно понял.
Делаем проект dll-библиотеки (делаю из-под Fortran PS4), после заголовка нужной функции, например testqp, ставим инструкцию !MS$ ATTRIBUTES DLLEXPORT::testqp.
Компилируем, бросаем dll-ку в ...system32 и прбуем вызвать из модуля МВА.
Там пишу
Private Declare Sub testqp Lib "testq" ()
(после некоторой суеты с реальной программой делаю тестовую программку без параметров)
и вызываю
Call testqp
Получаю сообщение, что невозможно найти entry point.
Чего, блин, не хватает?
Инструкции так лаконичны, что промахнуться негде, вроде бы.
В реальной программе можно делать исправления, исходник имеется, но переводить его на МВА импосибельно (более 3000 строк). Больше нигде такую прогу найти не могу, так что нужно работать с fortran"ом.
Может кто подскажет?
И еще.
06.06.04 22:33 Автор: vagrant Статус: Незарегистрированный пользователь
Нельзя ли как-то обойти необходимость сразу жестко указать расположение dll в VBA программе? Чтобы макрос искал ее, например, там же, где находится вызывающий файл. Скажем в ..\Library\ ?
А то даже у Уокенбаха написано - поместить в системную директорию.
> И еще. > > Нельзя ли как-то обойти необходимость сразу жестко указать > расположение dll в VBA программе? Чтобы макрос искал ее, > например, там же, где находится вызывающий файл. Скажем в > ..\Library\ ? regsvr32 Name_of_dll.dll
[Win32] хм07.06.04 12:07 Автор: paganoid Статус: Member
> > И еще. > > > > Нельзя ли как-то обойти необходимость сразу жестко > указать > > расположение dll в VBA программе? Чтобы макрос искал > ее, > > например, там же, где находится вызывающий файл. > Скажем в > > ..\Library\ ? > regsvr32 Name_of_dll.dll
Это он видимо про DLL, которые через Declare вызываюца, а не про COM компоненты. И регсвр на них -
как мёртвому припарки.
А про необходимость жёстко указывать путь - либо суй в System32, автоматом найдёца, либо в папку, где сам *.exe лежит.
Да, я все про ту же dll, из которой вызывается программа с...07.06.04 13:15 Автор: vagrant Статус: Незарегистрированный пользователь
Да, я все про ту же dll, из которой вызывается программа с "тяжелыми" вычислениями.
Но кто такой exe-шник, если dll-ка вызывается из надстройки Excel? Во всяком случае, если файл с dll лежит там же, где и надстройка*xla, при простом упоминании имени dll в DECLARE она не находится.
А так как директория самого офиса может быть разной на разных компах, то зашить жесткий путь C:\...\Library\***.dll нельзя. А в DECLARE можно поставить только константу в качестве имени. Т.е. простой путь, определитьpath и задать его в DECLARE не проходит.
не знаю :(07.06.04 13:54 Автор: paganoid Статус: Member
> А так как директория самого офиса может быть разной на > разных компах, то зашить жесткий путь > C:\...\Library\***.dll нельзя. А в DECLARE можно поставить > только константу в качестве имени. Т.е. простой путь, > определитьpath и задать его в DECLARE не проходит.
проблему понял, что посоветовать - не знаю :( Разве что какойнить стартер
написать => грузится XLA №1 => копирует лежащую рядом DLL в System32 => загружает вторую XLA.
Криво.
Но делать, видимо, нечего. Конечно, две XLA не нужны...11.06.04 22:30 Автор: vagrant Статус: Незарегистрированный пользователь
> проблему понял, что посоветовать - не знаю :( Разве что > какойнить стартер > написать => грузится XLA №1 => копирует лежащую рядом > DLL в System32 => загружает вторую XLA. > > Криво. Но делать, видимо, нечего. Конечно, две XLA не нужны. Достаточно в рабочей прописать в какой-нибудь функции типа before open() чтоб записала dll в директорию windows.
Просто как-то неаккуратненько, по виндузовому, оставляя мусор после сноса продукта.
Правда, если и сборщик добавить, чтоб в какой-нибудь before close() потиралась dll-ка из системной директории, выгрузив ее предварительно из памяти, то может и ничего?
Даже лучше это сделать при добавлении и удалении надстройки через меню Надстройки.
Попробуем.
функции надо stdcall в фортране делать24.05.04 10:29 Автор: paganoid Статус: Member
Да, я тоже нашел. Спасибо, что откликнулся.
Правда мой запрос небыл так блестящ и в ссылках пришлось долго копаться.
Все дело в декорировании имен, о чем я напроч забыл. Так что когда VBA декорирует имя функции, то в dll он ее, ясен перец не находит. Так что достаточно было воткнуть инструкцию типа
!MS$ ATTRIBUTES ALIAS:'DLL_fracdf' :: DLL_fracdf.
Блин.
Тяжко все же писать сразу на нескольких языках. Пока фортрановскую прогу правишь, забываешь как писать оператор цикла на С++.
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
