Этот подключаемый модуль не может быть запущен с dll подключаемого модуля в отстойнике

Обновлено: 08.07.2024

Если файл FARO загружен вместе с вашим подключаемым модулем, вы сможете загрузить файл с помощью статического метода FileIOFilter::LoadFromFile (по умолчанию все подключаемые модули должны иметь доступ к FileIOFilter.h).< /p>

В зависимости от расширения метод «LoadFromFile» должен использовать фильтр ввода-вывода FARO для загрузки файла. Однако я не уверен, что подключаемый модуль (DLL) будет использовать тот же контекст, что и приложение. Поэтому нам может понадобиться добавить метод доступа к файловому фильтру ввода/вывода в ccMainAppInterface (член плагина 'm_app'). Я позволю вам протестировать первое решение и дождаться ваших отзывов.

Всем привет!
Я хочу открывать файлы .txt в своем плагине, я пытаюсь написать эти коды:

AsciiFilter* loadf = new AsciiFilter();
AsciiFilter::LoadParameters loadp;
AsciiFilter::SaveParameters savep;
loadp.alwaysDisplayLoadDialog = true;
loadp.shiftHandlingMode = ccGlobalShiftManager::NO_DIALOG_AUTO_SHIFT;
loadp.autoComputeNormals = false;
loadp.parentWidget = это;
loadp.sessionStart = true;
savep.alwaysDisplaySaveDialog = false;
CC_FILE_ERROR ошибка = CC_FERR_NO_ERROR;
QString txtfile="D:\HJ\test\airplane_0001.txt";
QString txt ="";
ccHObject* ent = loadf->LoadFromFile(txtfile, loadp, err, txt);

Плагин работает корректно, но при запуске кода "ccHObject* ent = loadf->LoadFromFile(txtfile, loadp, err, txt);" , плагин переходит в состояние отсутствия ответа.
И все приложение Cloudcompare прекратило работу.

Я думаю, что в loadParameters или CC_FILE_ERROR есть ошибка, но я не смог ее найти.
Что мне делать?
Спасибо!

На самом деле вам не нужно динамически размещать фильтр (вы можете оставить его в стеке). И вы не должны вызывать статический метод «LoadFile» (который на самом деле является методом «FileIOFilter», основанным на зарегистрированных фильтрах). Вы должны вызвать AsciiFilter::loadFile напрямую.

Ошибка все еще существует.
Это скриншот:
это плагин:

Затем я нажимаю на него. Он загрузит файл .txt напрямую.

Нажмите «Применить»:

Затем я отлаживаю его через VS2017:

Отладка показывает, что ошибка произошла в CCCorelib.dll (возможно, где функция loadFile() находится в).
Я думаю, что при выполнении функции loadFile() произошла утечка памяти.

Мой код представляет собой подключаемый модуль для конкретного приложения, написанный на C++ с использованием Visual Studio 8. Он использует две библиотеки DLL от внешнего поставщика. К сожалению, мой плагин не запускается, потому что DLL не найдены (я поместил их в тот же каталог, что и сам плагин).

Когда я вручную перемещаю или копирую библиотеки DLL в каталог основного приложения, подключаемый модуль загружается нормально. Это перемещение было сочтено неприемлемо громоздким для конечного пользователя, и я ищу способ для моего плагина прозрачно загружать свои библиотеки DLL. Что я могу сделать?

Подключаемые модули хост-приложения расположены в каталоге, указанном хост-приложением. Этот каталог не находится в пути поиска DLL, и я не контролирую его.
Плагин сам упакован как подкаталог каталога плагинов, содержащий сам код плагина, а также любые ресурсы, связанные с плагином (например, изображения, файлы конфигурации…). Я управляю тем, что находится внутри этого подкаталога, называемого "пакетом", но не тем, где он находится.
обычная идиома установки подключаемого модуля для этого приложения заключается в том, что конечный пользователь копирует пакет подключаемого модуля в каталог подключаемого модуля.

Этот подключаемый модуль является портом из версии подключаемого модуля для Macintosh. На Mac проблем нет, потому что каждый двоичный файл содержит свой собственный путь поиска динамической библиотеки, который я установил так, как мне было нужно для моего двоичного файла плагина. Чтобы установить это на Mac, просто нужно настроить проект в Xcode IDE. Вот почему я надеялся на что-то подобное в Visual Studio, но не смог найти ничего подходящего. Более того, помощь Visual Studio была совсем не такой, как и помощь Google.

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

Как разработчик Mac, я понимаю, что могу попросить что-то очень элементарное. Если это так, приношу свои извинения, но у меня кончились волосы, чтобы их рвать.

4 ответа 4

Вы не просите чего-то очень элементарного. Windows просто не поддерживает то, что вы хотите.

У вас есть несколько вариантов решения этой проблемы:

Создайте две библиотеки DLL. dll реализации вашего плагина, которая статически связывается с любыми другими dll, которые вам нужны. И простая «фасадная» dll, которая загружается хостинговым приложением.Фасадная dll вызывает SetDllDirectory, а затем LoadLibrary для загрузки вашей реализации dll с требуемым путем поиска, а затем для каждой экспортируемой плагином функции она реализует функцию-заглушку, которая использует GetProcAddress, чтобы просто передать вызов прямо в вашу реализацию dll.

Если интерфейс плагина сложен, а используемый вами интерфейс dll — нет, то:

Откажитесь и просто используйте LoadLibrary (с явным путем) и GetProcAddress, чтобы получить доступ к функциям вашей вспомогательной библиотеки DLL. Боль.

Последний вариант наименее документирован и плохо понятен программистам Windows. В основном мы используем версию технологии для Windows, созданную для поддержки .NET: параллельных сборок. Не пугайтесь. Сборка «бок о бок» — это очень просто обычная старая dll, но с сопроводительным файлом .manifest, в котором содержится дополнительная информация о ней.

Причина, по которой мы хотим сделать это, заключается в том, что порядок поиска dll, связанных с помощью технологии SxS, отличается от обычного порядка поиска dll, а именно: после поиска c:\windows\WinSxS окна будут искать то же самое. папка как dll, которая ссылается на dll, а НЕ на папку исполняемого файла.

Начните с инвентаризации всех вспомогательных dll, с которыми должна быть связана ваша подключаемая dll, и создайте из них «сборку». Это означает: создайте файл .manifest с кучей узлов file=. Вам нужно дать сборке имя. Назовем его "MyAssembly".

Создайте файл "MyAssembly.manifest" в папке вашей dll с содержимым, подобным следующему: (перечислите все dll, которые вам нужно включить)

Теперь это ваш манифест сборки. Мы наполовину закончили.

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

Очевидно, манифестам приложений (что может сбивать с толку при внедрении в dll) также разрешено использовать узел, поэтому можно пропустить создание сборки и просто использовать

как манифест dll. Я еще не играл с этой итерацией, поэтому я не уверен, как это меняет обычный путь поиска dll (если вообще).

Не зная среды разработки, трудно посоветовать, как добавить манифест в dll. Если вы редактируете файл .rc и вводите манифест вручную, знайте, что в библиотеках DLL используется идентификатор ресурса 2, а не 1, который обычно используется в примерах exe.

Сообщите нам результат :)

С уважением,
musikBear

Не думаю, что работаю на Linux
Новый компьютер, поэтому еще не уверен во всех его системах

Я также настроил каталог. Но возникает ошибка, когда я пытаюсь открыть любой.

Я отправлю ss, когда вернусь домой

У меня нет Linux, так как это Windows, было толсто

Когда я пытаюсь загрузить любую .dll, мне пишет, что файл не может быть загружен. И если он работает с любым другим программным обеспечением vst, обратитесь к разработчику

Ваш путь правильный?

С уважением,
musikBear

Нужно ли им всем, чтобы они находились в этой конкретной папке для загрузки подключаемых модулей VST DLL?
Или просто считается, что их проще хранить в одном месте?

Я использую Debian Linux и заметил, что могу просто перетаскивать. Я перехожу к местоположению DLL из корневого каталога/диска или из дома. Затем я могу выбрать DLL. В данном случае это плагин Tone2FireBird с именем файла FireBird.dll в папке плагина,

Затем я могу просто перетащить его из этой папки в редактор песен и получить доступ к инструменту VST.

Здесь полноразмерное изображение из LMMS 1.1.3, работающего на Debian 9.6

Затем я могу просто перетащить его из этой папки в редактор песен и получить доступ к инструменту VST.

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

Что не работает? В микшер добавлены плагины эффектов. Они не могут находиться ни в какой другой папке, файл .dll должен находиться в указанной папке. (путь)
( Windows/Linux не имеет значения. )

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

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

Начинающему тему следует пока просто игнорировать это сообщение и слушать musicbear.

Читайте также: