[FireNativeDLL] Создание полноценных DLL на Visual Basic

[SLIM]

Ну получается так.
Не работает в VS2010, VS2008
Без разницы на какой студии, но в Win7 не работает.
Почему такое может быть?

[Хакер]

Откуда я знаю, что в этой чудо-ОС придумали. Может быть там библиотеки должны быть специальным образом подписаны, или может быть там из DllEntryPoint нельзя использовать COM. Последнее, скорее всего.

Тогда вызов CoInitialize до LoadLibrary может исправить ситуацию, но не обязательно.

[SLIM]

Спасибо огромное!!!!!
Заработало!!!!!

[SLIM]

Но ведь исправлено?

Я просто не сразу понял. Правку нажимаешь, но не показывает "я идиот...", просто восклицательные знаки
Ладно, не так важно.
Хакер, спасибо еще раз!!!

[mshak]

а кто нибудь пробовал создавать апплеты панели управления?
у меня рушится при вызове функции CPlApplet.
Я конечно не исключаю что у меня руки не совсем из нужного места растут , но рушится в странном месте

Код: Выделить всё

Public Function CPlApplet(hwndCPL&, uMsg&, lParam1&, lParam2&) As Long
OutputDebugString "call CPLApplet"
OutputDebugString "Msg = " & Str(uMsg) '! рушится в этом месте !

    Select Case uMsg
...


[Хакер]

Ну ещё бы оно не рушилось. У тебя все параметры — ByRef. То есть твоя функция ожидает, что передадут ссылки на нужные значения. А вызывающая сторона передаёт не указатели на значения, а сами значения. И твоя функция эти значения интерпретирует не как значения, а как указатели на значения. И обращается по заведомо некорректным адресам памяти.

[mshak]

все таки не оттуда растут. совсем забыл что VB6 по умолчанию параметры - byRef. Спасибо. тест заработал.

[ger_kar]

Понадобилось срочно изготовить DLL ку. Хотель скачать FireNativeDLL 1.0
но ссылка оказалась нерабочая http://www.fire-lines.ru/content/fndll/1/0/install.exe,
сам сайт видимо не рабочий. Кто скачивал последний раз и когда?
Стоит ли ждать пока сайт заработает, кто знает подскажите.

[Хакер]

Где-то выше кто-то выкладывал копию инсталлятора.

[SLIM]

У меня есть. Шли мыло в личку

[ger_kar]

Нашел, сслыку на копию инсталлятора FireNativeDLL, которую выложил SLIM
http://narod.ru/disk/25703520000/Native ... L.exe.html
Спасибо.
Скачал, установил, опробовал в тестовом режиме, с вызовами из VBA и передаваемыми параметрами
простых типов вроде работает нормально.
Возник вопрос - это самая последняя версия инсталятора?
И еще вопрос можно ли в такую DLL передать в качестве параметра Объект, ну например
Worksheet из VBA Excel, для обработки и заполнения? И как это правильно сделать?

[Хакер]

Возник вопрос - это самая последняя версия инсталятора?

Публиковалась только одна версия, и она содержит известные проблемы.

И еще вопрос можно ли в такую DLL передать в качестве параметра Объект, ну например
Worksheet из VBA Excel, для обработки и заполнения? И как это правильно сделать?

Можно.

[SLIM]

Нашел, сслыку на копию инсталлятора FireNativeDLL, которую выложил SLIM

Я этого не выкладывал

[ger_kar]

Засада. Сделал тестовую DLL с передачей в качестве параметра объекта Excel.Worksheet
Все работает но только один раз. Точнее в первый раз в цикле вызвается процедура, из которой
в свою очередь вызывается процедура из недр DLL, лист Excel обрабатывается и заполняется.
Все отрабатывает без единой ошибки. Но если повторно запустить этот же цикл, то возникает
ошибка:

Run-time error '2147417848 (80010108)'
Automation error
Вызванный объект был отключен от клиентов.

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

Код: Выделить всё

Public Sub SetData(ByRef objSheet As Excel.Worksheet, ByRef strStroka As String, _
                   ByRef strName As String, Optional ByVal intMaxIndex As Integer = 0)
    Dim intIndex As Integer
    On Error GoTo err1
    If intMaxIndex = 0 Then
        objSheet.Range(strName) = strStroka
    Else
        For intIndex = 1 To intMaxIndex
            objSheet.Range(strName & intIndex) = Mid$(strStroka, intIndex, 1)
        Next
    End If
Exit Sub
err1:
    MsgBox Err.Number, vbOKOnly, "Ошибочка вышла"
End Sub

Если в тело процедуры банально вставить
строку MsgBox "Привет", vbInformation, "Сообщение" то все работает,
с выдачей веселых сообщений

[Хакер]

Зачем ByRef?

[ger_kar]

ByRef - Потому, что якобы VBA строковые параметры всегда передает по ссылке, даже если явно указать ByVal
Источник здесь: http://citforum.ru/programming/vb/vba_winapi/3.shtml
Может оно и не так, но я и до этого читал о том же, правда уже точно не помню где.
Но не суть важно, я и ByVal пробовал использовать эксперементируя - результат тот же.

[Хакер]

ByRef - Потому, что якобы VBA строковые параметры всегда передает по ссылке, даже если явно указать ByVal

Ересь.

Но не суть важно, я и ByVal пробовал использовать эксперементируя - результат тот же.

Если сможешь VBA-сторону заменить VB-шным тестором-заглушкой, шли проекты, я потестирую. Офиса у меня нет просто.

Вставка весёлого сообщения в какого места помогает? В какое-то особенное или в любое?

Как объявлена функция в Declare?

[ger_kar]

Ну насчет ересь или нет можно будет опытным путем выяснить, у меня тоже насчет этого большие сомнения.
А что касается сообщения то его можно вставить в любом месте и сразу все начинает работать. Видимо причина
в вызове этого сообщения. Прийдется в отладчике посмотреть что делается со стеком в случае если сообщение
имеется или без оного. Так как последние опыты показали, что даже если убрать объект оставив остальные
параметры, а тело процедуры банально закомментировать т.е. Сделать процедуру пустой, то все работает точно
также, но стоит вставить сообщение и все ОК.
Декларация после последнего эксперимента:

Код: Выделить всё

Public Declare Sub SetDataA Lib "D:\VB_Proekt\Отчеты\DLL1.dll" Alias "SetData" _
                                 (ByRef objSheet As Excel.Worksheet, ByVal strStroka As String, _
                                  ByVal strName As String, ByVal intMaxIndex As Integer)

Вызов:

Код: Выделить всё

SetDataA ActiveSheet, StrConv(strStroka, vbUnicode), StrConv(strName, vbUnicode), intMaxIndex

Заглушку буду делать уже завтра, самому интересно стало как это на VB сработает.

[Хакер]

Есть ещё вариант, что это проявление врождённой проблемы FNDLL. Вышли мне DLL, я её подправлю и посмотрим, будет ли ошибка проявляться затем.

[VBTerminator]

Нашел, сслыку на копию инсталлятора FireNativeDLL, которую выложил SLIM

Я этого не выкладывал

ger_kar, какой невнимательный! Достаточно было глянуть на предыдущую страницу, чтобы узнать, что это я выложил "сслыку" на кусочек моих закромов.

[ger_kar]

При использовании библиотек созданных в VB из среды VBA, при возникновении ошибки

Run-time error '2147417848 (80010108)' Automation error Вызванный объект был отключен от клиентов.

которая появляется если макрос (скрипт) запустить повторно, нужно использовать команду END в конце скрипта,
и все будет работать без ошибок. У меня по крайней мере заработало.
Хакеру огромный респект.

[Хакер]

Придётся ставить Офис, чтобы разобраться с этими сообщениями о совершенно не свойственной для ситуации ошибке.

[mshak]

Доброй ночи.
У меня при использовании FNDll возникла след ситуация:
Есть два проекта, один Dll (будущий апплет панели управления) и standart exe, который состоит из тех же файлов что и проект dll, кроме модуля с описанием функции точки-входа для dll (модуль не корректировался) и модуля класса. В качестве Sturtup object для exe проекта задано formName. Собственно ситуация: проект dll работает без нареканий, но отлаживать не удобно. Проект exe созданный в целях отладки прекрасно работает только в ide, а если его скомпилировать и запустить то он ругается на отсутсвие класса, хотя никакого класса в проекте нет, а на другом компьютере просто не запускается без каких-либо сообщений об ошибках.

[Хакер]

Проект exe созданный в целях отладки прекрасно работает только в ide, а если его скомпилировать и запустить то он ругается на отсутсвие класса, хотя никакого класса в проекте нет, а на другом компьютере просто не запускается без каких-либо сообщений об ошибках.

Какого класса? Выкладывай проект.

Отлаживать FNDLL-ные проекты можно так. На время отладки вызывать функции не через экспорт-импорт, а через экземпляр публичного класса. Тогда в IDE проект с библиотекой просто запускаешь, а затем используешь со стороны. Брекпоинты и все остальные средства отладки будут работать.

[mshak]

Хакер, спасибо за подсказку. Понял как отлаживать без exe. Но он нужен и для других целей тоже. Проект выслал через ЛС.
==
А вот какая появляется ошибка во время запуска скомпилированного exe.

[Хакер]

А вот какая появляется ошибка во время запуска скомпилированного exe.

А. Это вообще похоже на ошибку с Common Controls 6 (активируемых манифестом). Ты их используешь?

[mshak]

Хакер, спасибо. Да, в проекте используется Common Controls 6. Убрал манифест и заработало.
Как выяснилось моя проблема не имела значения к FNDLL, сорри что написал не в ту тему.

[Хакер]

Да, в проекте используется Common Controls 6. Убрал манифест и заработало.

Нужно обязательно делать InitCommonControls.

Да, FNDLL тут не причём.

[ger_kar]

Опять возвращяюсь к теме FNDLL и VBA.

Есть ещё вариант, что это проявление врождённой проблемы FNDLL

А, что за врожденная проблема? В чем она заключается?
Мне все-таки кажется, что здесь дело именно в VBA. Если VB это компилятор и интерпретатор (режим IDE), то VBA это только интерпретатор. И как в этом случае он работает, если юзается библиотека FNDLL? Т.е. если использовать END, то при повторном запуске скрипта, как я понимаю, интерпретация происходит заново и таким образом создается новый апартамент? Или я заблуждаюсь? В VB если даже явно не использовать END, то это ничего не меняет и таким образом режим IDE работает так же как и VBA с использованием END. Но если END в VBA не использовать, то что происходит в этом случае? Я так понимаю повторной интерпретации в этом случае не происходит. Но почему рушиться апартамент? И почему он не рушиться если создать экземпляр класса? Я чет так и не догнал, и этот вопрос меня по прежнему мучает.

[Хакер]

А, что за врожденная проблема? В чем она заключается?

Она в том, что COM/ActiveX-основанность просто зашкаливает. В COM ведётся подсчёт ссылок на интерфейс, интерфейсы на которые не осталось ссылок уничтожаются. В объектах введётся подсчёт живых интерфейсов, если их нет, объект уничтожается (хотя на деле всё реализуется по несколько более упрощённой схеме). А в библиотеке введётся подсчёт живых объектов. Если объектов не осталось, библиотека деинициализируется. В деинициализацию входит обнуление/освобождение внутренних структур, но и не ограничивается этим. Например, в деинициализацию входит зануление модульных (ака глобальных) переменных библиотеки.

Это означает, что чтобы вызываемые из библиотеки функции нормально работали, библиотека должна находится в инициализированном состоянии. В FNDLL-1 для этого использовался следующий метод: в DllEntryPoint при входе с DLL_ATTACH_PROCESS создавался объект (экземпляр класса CStdDllInfo, просто потому, что он уже есть, и не надо придумывать ещё одного ради только этой цели), и тут же уничтожался.

Создание экземпляра приводило к тому, что появлялся один живой объект. Это приводило к инициализации библиотеки. Часть изменений, которые входят в понятия «инициализация», неустранимы (не исчезают после деинициализации), часть же исчезает после деинициализации, но с одним но.

Хотя деинициализация библиотеки происходила сразу же после инициализации, так получалось, что библиотека всё равно могла работать засчёт оставшегося после деинициализации мусора. Но здесь уже никто не может гарантировать стабильность работы, основанной на мусоре. Поэтому FNDLL-библиотеки иногда падали, как только мусор по случайным причинам становился невалидным.

Хотя это намеренно привнесённая мною ошибка: в самой первой выложенной версии уничтожение только что созданного объекта в DllEntryPoint не совершалось, и библиотека была стабильна всегда. Но была другая проблема: поскольку объект не уничтожался вообще, возникала угроза возникновения утечки памяти. Хотя рядовые библиотеки подгружаются в АП процесса только единожды, возможен всё-таки случай, когда библиотека будет периодически загружаться/выгружать из в/из АП процесса с помощью LoadLibrary/FreeLibrary. Если будет выполнена тысяча таких выгрузок-загрузок, в памяти будет висеть тысяча неуничтоженных объектов.

Тогда я через некоторое время после выкладывания самой первой версии обновил её, тем, что внёс изменение: объект (инициатор инициализации) уничтожался сразу же. Утечка была устранена, но возникла другая проблема: деинициализация, после которой вызов экспортируемых функций работает «на авось». Тогда был сделан ошибочный вывод, что деинициализация не делает библиотеку не стабильной, потому что она (по предположению) ограничивается сбросом модульных переменных апартаментов. Ошибочным вывод стал потому, что библиотека действительно была работоспособна после деинициализации, некоторые ведь как-то пользуются FNDLL.

Глобальная проблема всего замысла состоит в том, что я просто не могу найти удобного места, чтобы прицепить к ним инициализацию/деинициализацию.

DllEntryPoint с DLL_PROCESS_ATTACH и DllEntryPoint с DLL_PROCESS_DETACH не подходят — внутри этих функций вообще мало что можно делать, а уж дёргать COM и выполнять такие тяжелые действия, как инициализация рантайма — опасно. Как видно, в Висте (в ней же, вроде?) это вызвало облом. Но кроме этого, DllEntryPoint выполняется до WinMain. Тут есть гадкий момент: WinMain-функция EXE-файла, сделанного с помощью VB, вызывает msvbvmx0!ThunRTMain, чтобы оная инициализирована контекст EXE-проекта. Если она обнаружит, что рантайм уже инициализирован, VB-EXE-проект падает с ошибкой. Так что если DLL (сделанная с помощью FNDLL) импортируется EXE-шником (написанным на VB), и импорт осуществляется через TLB, то EXE не запустится. Поюзать такую же DLL из EXE написанного на чём-нибудь другом — запросто.

Из этого следует, что инициализация библиотеки/рантайма должна выполняться после того, как выполнение войдёт внутрь WinMain. А деинициализация должна выполняться до того, как кто-нибудь в рамках процесса выполнит CoUninitialize.

Простой выход: добавлять ко всем экспортам FNDLL-based библиотек две функции: Init, UnInit, которые пользователь библиотеки должен будет сам вручную вызывать. Очень качественно, но совершенно тупо и неудобно с точки зрения пользователя. Другой способ: использовать концепцию one-shoot — выполнять инициализацию при самом первом вызове любой экспортируемой функции. Но при этом остаётся совершенно непонятно: а когда тогда вызывать деинициализацию? Ведь самый первый вызов легко определить, а самый последний — невозможно.

В общем, таких открытых проблем просто масса, поэтому-то выпуск новой версии так долго откладывался.

Мне все-таки кажется, что здесь дело именно в VBA. Если VB это компилятор и интерпретатор (режим IDE), то VBA это только интерпретатор.

Строго говоря, никакого интерпретатора нет. Те, кто считают, что VB IDE интерпретирует код при отладке, глубоко заблуждаются. При отладке в IDE используется Just-In-Time компиляция. Именно компиляция, я не интерпретация. Компиляция совершается в P-Code и совершается единожды. Единожды — значит если функция недавно скомпилировалась, и с тех пор её не меняли, при последующем отладочном запуске она перекомпилироваться не будет.

Хотя, JIT-компиляция это всего лишь вкусная фишка; есть опция «Start With Full Compile», тогда никакой JIT-компиляции нет, есть компиляция всего и сразу, но всё в тот же P-код. При работе в режиме отладки в этом случае выполняется разом скомпилированный P-код.

Кстати, компиляция в P-код совершается не на основе исходного кода проекта, а на основе иерархической структуры данных, описывающей исходный код. Эта структура строится/модифицируется непосредственно в момент правки исходного кода в редакторе. Так что внутри процесса VB даже не хранится тот самый исходный код, который мы видим в редакторе. Тот код, что мы видим в редакторе, строится на основе того же дерева.

Это актуально и для VB, и для VBA. Вся эта функциональность выполняется одним и тем же движком (для продукта VB это библиотека vbaX.dll, со всеми её функциями с префиксами Eb, Tip, и кучей безымянных функций, экспортируемых по ординалу).

Именно возможность делать автономные файлы называют компиляцией, хотя компиляция имеет место и в режиме отладки (компиляция P-код), а интерпретирования нет вообще. Возможность делать автономные EXE реализована следующими способами:

• Тот же самый уже сгенерированный P-код (который выполняется в режиме отладки) тупо распихивается по obj-файлам, а потом они линкуются в один EXE/DLL-файл. Туда же прилинковывается крохотный переходничок, который передаёт на исполнение вшитый в EXE/DLL-файле P-код на исполнение движку, вшитому в MSVBVM.
• (Метод добавлен чуть позже) P-код скармливается утилите С2.EXE, которая из P-кода делает Native-код. Этот Native-код
  распихивается по obj-файлам и дальше они слинковываются вместе в один EXE/DLL.

Вот и всё. Разница получается примерно как между qBasic и QuickBasic.

Остальные различия между VB и VBA проистекают из разницы в подключенных (и недопустыных для отключения) TLB-шек, списком доступных типов модулей (модулей с точки зрения Eb-движка) и прочими тонкими настройками Eb-движка, который сам позволяет себя настраивать.


* * *

А дальше мне лень писать. Все твои фразы настолько противоречивы, что к каждой можно написать такую разъяснительную мини-статью. Мне кажется, ты специально провоцируешь меня на это .
Теперь чем же отличается VB от VBA. VB позволяет не просто запускать проект в режиме отладки (проект компилируется Eb-движком, а потом выполняется), но делать автономные EXE-файлы.