Hi,
does your executable contain "module initialization code" as mentioned?
Did you try the "MitkCore" sub-directory?
In your MITK (not superbuild) CMake cache, you can set the
US_ENABLE_DEBUG_OUTPUT variable to ON (needs to be manually added in the
CMake GUI or on the command line). After recompiling MITK, this will
give you debug messages including auto-load stuff.
The relevant code is here:
https://github.com/MITK/MITK/blob/master/Modules/CppMicroServices/core/src/util/usUtils.cpp#L109
Thanks,
Sascha
On 02/17/2015 09:34 PM, Ingmar Wegner wrote:
Hi Sascha,
I tried the following situation, but nothing worked out.
The application is in:
target_win64-vc12\_runtime\debug\my_application.exe
I tried
target_win64-vc12\_runtime\debug\main\my_module.dll
target_win64-vc12\_runtime\debug\main\debug\my_module.dll
target_win64-vc12\_runtime\main\my_module.dll
target_win64-vc12\_runtime\main\debug\my_module.dll
target_win64-vc12\main\my_module.dll
target_win64-vc12\main\debug\my_module.dll
Could you possibly point out where the auto-load plugin code is
situated? Then I can debug it more closely.
Besides, did anyone also experience the warning messages in the console?
It states 2x4 times at the end of startup:
void __cdecl QWindow::setTransientParent(class QWindow *)
QWidgetWindow(0x61f7fc0, name = "QWidgetClassWindow") must be a top
level window.
This is surely QT5 related.
Have an nice evening,
Ingmar
*Gesendet:* Dienstag, 17. Februar 2015 um 15:49 Uhr
*Von:* "Sascha Zelzer" <[email protected]>
*An:* "Ingmar Wegner" <[email protected]>
*Cc:* mitk-users <[email protected]>
*Betreff:* Re: Aw: Re: Re: Re: [mitk-users] Migration to MicroService
based IO
Hi,
as explained below, the auto-load module must be placed in a
subdirectory name "main" or "MitkCore" which is located at the same
level as your application's executable (not in the same directory as
your executable).
Best,
Sascha
On 02/17/2015 02:47 PM, Ingmar Wegner wrote:
Hi Sascha,
then the library is not loaded and the Load() method of my module
activator is never called.
The module lib is located in the same directory as my application
and my plugins. We don't consider having a dedicated plugins
folder for now.
Best,
Ingmar
*Gesendet:* Dienstag, 17. Februar 2015 um 14:22 Uhr
*Von:* "Sascha Zelzer" <[email protected]>
*An:* "Ingmar Wegner" <[email protected]>
*Cc:* mitk-users <[email protected]>
*Betreff:* Re: Aw: Re: Re: [mitk-users] Migration to MicroService
based IO
Hi Ingmar,
On 02/17/2015 12:09 PM, Ingmar Wegner wrote:
HI Sascha,
with your hint I was able to register the io service.
Still have to set the io lib as pre-load library parameter though.
What happens if you don't? For auto-load modules, this is
redundant (if the auto-loading works).
Best,
Sascha
But I will continue my work on this once I have everything
compiling and running.
As I recently updated my fork to the mitk master I now have
problems with the new directory structure.
I will write a seperate mail on this.
So thank you for your help,
;) Ingmar
*Gesendet:* Freitag, 13. Februar 2015 um 16:07 Uhr
*Von:* "Sascha Zelzer" <[email protected]>
*An:* "Ingmar Wegner" <[email protected]>, mitk-users
<[email protected]>
*Betreff:* Re: Aw: Re: [mitk-users] Migration to MicroService
based IO
Hi,
we essentially have the same set-up with our internal code base.
Please read [1] for information about auto-load paths. The
activator of the MitkCore module adds the path containing the
running executable to the list of auto-load paths, so putting
your module's shared library into <your-exec-path>/main (if
your executable contains CppMicroService initialization code)
or <your-exec-path>/MitkCore should work out of the box.
Best,
Sascha
[1] http://docs.mitk.org/2014.10/MicroServices_AutoLoading.html
On 02/13/2015 03:51 PM, Ingmar Wegner wrote:
Hi Sascha,
in general I build up linker dependencies to the modules
in my plugins. And before I had an awkward dependency from
the app plugin to the modules that provide IO
functionalites. In my WorkbenchWindowAdvisor I was
registering the ObjectFactory of each module, so to say.
This time, with the micro service, I hoped to have a loose
way of loading the services during startup and have them
automatically registered to the MITK IO service in case
they are there.
As I have an external project that links aginst MITK the
solution with copying the shared lib into MITK-build is
not possible. How does it work in the installed case by
the way?
Is it possible to add a directory that has to be parsed
for auto-loading?
Thanks for the quick response,
Ingmar
*Gesendet:* Freitag, 13. Februar 2015 um 15:14 Uhr
*Von:* "Sascha Zelzer" <[email protected]>
*An:* "Ingmar Wegner" <[email protected]>, "Mitk Users"
<[email protected]>
*Betreff:* Re: [mitk-users] Migration to MicroService based IO
Hi Ingmar,
how is your module supposed to be loaded? By a linker
dependency or as a "auto-load" module? In the latter case
you need to make sure that the shared library is created
in the proper sub-directory (e.g.
MITK-build/(bin|lib)/MitkCore)
Best,
Sascha
On 02/12/2015 11:03 AM, Ingmar Wegner wrote:
Hi all,
I am merging our readers and writers to the new micro
service based apporach but am probably missing something.
I basically stuck to Stefan K. approach for migrating
the simulation module (*Bug 18640*
<http://bugs.mitk.org/show_bug.cgi?id=18640>).
Before I was registering the ObjectFactory in my
WorkbenchWindowAdvisor but now the autoload feature of
my written micro service is supposed to do that.
Setup:
MSVC 2013 X64 QT 5.4 (!)
MITK checkout from 30 Jan 2015 but might stick close
to the trunk until the next release once I have it
working.
The easiest example of mine is my own vrml reader and
writer.
So for now I implemented an activator and one vrml_io
class that contains Read() and Write().
The Activator::Load() method though is never called!
(Object factory and serializer are neglected as long
as the module doesn't load.)
I am calling
US_EXPORT_MODULE_ACTIVATOR(MyActivator);
in the body of my activator.
I have to mention that I am manually setting
properties in my cmakelists.txt file as I am not using
the macros provided by mitk.
see following section:
#start CMakeLists.txt
# Registering as mitk module with MicroService
functionality
# set template file
project(mesh)
... # ...including file.cmake
set(module_name ${PROJECT_NAME})
set(US_MODULE_INIT_TEMPLATE
${MITK_SOURCE_DIR}/Core/CppMicroServices/CMake/usModuleInit.cpp)
... # ...calling add_library(...)
#Define US_MODULE_NAME needed for MITK MicroService
set_property(TARGET ${PROJECT_NAME} APPEND PROPERTY
COMPILE_DEFINITIONS US_MODULE_NAME=${module_name}) #
otherwise it complains about a not set module name
set_property(TARGET ${PROJECT_NAME} PROPERTY
US_MODULE_NAME ${module_name})
#end CMakeLists.txt
I tried to debug the other working loading modules but
didn't find a difference why my one shouldn't start.
Do I have to untangle some cmake magic done in the
MITK_CREATE_MODULE macro?
Which example is best for such a job?
The one in modules/core is written to also contain VTK
and ITK IO and doesn't seem to me as a good example
for an external project.
Best Regards,
Ingmar
P.S. Can't wait for the users meeting in April!
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
_______________________________________________
mitk-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mitk-users
