Hello All, I have fixed my problem and I just wanted to put some resources here that helped me a lot.
This turned out to be a missing dll problem, not a CTK plugin search path or database problem as I was thinking. https://doc.qt.io/qt-5/deployment-plugins.html - Setting the QT_DEBUG_PLUGINS environment variable to a nonzero value makes Qt print out much more detailed and useful information; with this variable set my program printed out a lot of information when plugins were loaded. - One thing that I was confused about, the "metadata" part of the dlls happens *before* the dll is loaded using LoadLibrary, I was getting messages like this: Found metadata in lib <path-to>\myview.dll, metadata= { "IID": "myview", "MetaData": { }, "className": "myview_Activator", "debug": false, "version": 329473 } However, the very next line would be Cannot load library <path-to>\myview.dll : The specified module could not be found. QLibraryPrivate::loadPlugin failed on " <path-to>\myview.dll " : "Cannot load library <path-to>\myview.dll : *The specified module could not be found."* "The specified module could not be found"? But clearly it just found the dll... it listed metadata from it. It turns out that that "specified module could not be found" message was not coming from Qt, it was just echoed from the Winapi function LoadLibrary. https://docs.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-loadlibrarya What it was really saying was, *"A dependency of this dll is missing"*. To investigate dependencies I recommend using Sysinternal's ProcessMonitor tool https://docs.microsoft.com/en-us/sysinternals/downloads/procmon - Remember to run the right version of procmon for your OS's architecture. - Since my program was quite large, I decided to make a small test program in C that just attempts to load whatever dll path is provided as a path (using LoadLibrary) and trace that instead with ProcessMonitor. I filtered so that it would just show entries from my test program with an operation of QueryOpen. I looked for cases where the OS went through every single directory in the PATH and still failed to find it (saving the filtered results to CSV and then searching for all instances of the plugin dll name helps out with this). Using this method I was able to identify which dlls were missing in the plugin. Hope that helps, - Alex On Tue, Mar 10, 2020 at 10:25 AM Alex Melville <amelv...@umich.edu> wrote: > Hi Stefan, > > After looking at it a bit more after I sent the e-mail, you're right that > I was mixing up plugins and modules. Thanks, I understand this setup > better now. > > The VIEW_ID is set properly, and as far as I can tell, my project is doing > everything the project template is doing. > > Can anyone give me more information on how the plugins are discovered, > e.g., > > - Are there any hard coded paths, or anything that needs to be added to > PATH to allow MITK to discover plugins? > - Does MITK actually iterate over every dll in a directory looking for > plugins? > - I notice a .provisioning file was generated, it looks like it contains a > list of dlls relative to some variable "@EXECUTABLE_DIR" -- I am wondering > if EXECUTABLE_DIR is set correctly. > - It looks like the plugins list is just internally a map of strings to > types in the plugin dll itself, I am not quite sure how our main program > (also a plugin) knows about other plugins. Does MITK inspect the symbols of > other dlls and try and literally find the VIEW_ID? > > Thanks, > > - Alex > > > > > On Mon, Mar 9, 2020 at 4:49 AM Dinkelacker, Stefan < > s.dinkelac...@dkfz-heidelberg.de> wrote: > >> Hi Alex, >> >> >> >> I think you mixed up two different things here. While MITK plugins do >> come with CppMicroServices support, it has nothing to do with the plugin >> registration. MITK is using the CTK plugin framework for this [1]. BTW you >> can always look into the MITK/CMake directory to find the code behind MITK >> CMake functions/macros like mitkFunctionCreatePlugin.cmake that basically >> wraps ctkMacroBuildPlugin. >> >> >> >> There are many things that can go wrong, so it’s impossible to tell you >> exactly what’s going on in your case but when searching for source files >> containing PartInitException and “Could not create view” I end up with >> three candidates in org.blueberry.ui.qt where I would recommend to place >> break points to debug the issue. >> >> >> >> General plugin-related hints that are not the most obvious ones: >> >> >> >> - Start your application with the /BlueBerry.clean (Windows) or >> –BlueBerry.clean (Linux, macOS) argument to force a clean start (takes >> longer but it is a better base for debugging these kinds of plugin issues). >> Sometimes that’s already all that’s necessary (to do It once). >> >> - Did you declare AND define a VIEW_ID in your View class, if your >> plugin contains any? >> >> >> >> Although tailored for 2018.04, the exampleplugin is a good minimum >> example with comments to carefully look through and compare everything to a >> working plugin [2]. >> >> >> >> Best, >> >> Stefan >> >> >> >> [1] http://www.commontk.org/index.php/Documentation/Plugin_Framework >> >> [2] >> https://github.com/MITK/MITK-ProjectTemplate/tree/master/Plugins/org.mitk.gui.qt.exampleplugin >> >> >> >> >> >> *From:* Alex Melville [mailto:amelv...@umich.edu] >> *Sent:* Friday, March 6, 2020 9:44 PM >> *To:* mitk-users@lists.sourceforge.net >> *Subject:* [mitk-users] mitk_create_plugin and C++ Microservices >> >> >> >> Hello, >> >> >> >> Background: >> >> >> >> - I have a plugin that I'm maintaining that calls mitk_create_plugin, but >> it doesn't seem like its views are getting registered. We're getting errors >> of the form "Could not create view: <viewName>", "Caused by: Part >> initialization error: Could not create view: <viewName>" even though the >> dll containing the view seems to be in the right directory. >> >> >> >> - Based on that, I have to conclude that the code for the C++ >> microservices (documented here: >> http://docs.mitk.org/nightly/MicroServices_TheModuleContext.html ) is >> not getting added to our code. I tried grepping the build directory for >> functions related to registering modules, but nothing came back. >> ModuleRegistry showed only GetModule(). >> >> >> >> - Looking at MITK-ProjectTemplate (v2016.11), it looks like the sample >> plugins don't need to call anything other than mitk_create_plugin. So based >> on that, I'd guess that the microservices pre-processing should happen >> automatically for plugins, but I wanted to make sure. >> >> >> >> Questions: >> >> - Does mitk_create_plugin automatically preprocess the files to add the >> Register / etc. functions? >> >> - If it should, any advice on what else can cause views of plugins to not >> be found would be appreciated >> >> >> >> Are there any more details on how the micro services system works? >> >> - Is there one registry for the entire system (like e.g., COM/DCOM) or >> one per application? >> >> - Where is this microservices registry stored? Or is it not stored >> anywhere and instead it's re-populated every time the application starts? >> >> >> >> Thanks, >> >> >> >> - Alex >> >> >> >> >> >> >> >
_______________________________________________ mitk-users mailing list mitk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mitk-users
