Hello,
Sorry for taking so long to reply but I wanted to get sure I was doing
things the right way. As I was working with my created projects and
moving things by hand to my folders I was afraid that something I missed
was motivating the issue.
I got the last MITK source code from the svn and compiled it again. The
MITK_BUILD_SHARED_CORE was set to ON and the MITK_SHARED_LIBS could not
be turned ON, as you suggested, with a warning stating that this is not
supported yet and to just set the SHARED_CORE to ON.
Everything went well and I then generated the project files form the
tool extension example available using CMake and compiled the DLL. The
same exception occured when loading the DLL. I then did the change you
suggested and then recompiled. A different exception happened, this time
at Windows DLLs level.
The best result I could get (although with the exception at program
closing) was by performing the code change I described earlier. Keeping
the code as is, the address of the returned factory is NULL.
It seems to me that a second call to itkLoad is performed before it
ends. When the factories are registered in the
mitkToolExtensionITKFactoryLoader() doesn't it involve (somewhere along
the way) going through the autoload folder and loading any existing DLL
(with the resulting invocation of itkLoad again for the tool's DLL). As
fas as I could tell when debugging, the flow was into the itkLoad
function, then into the mitkToolExtensionITKFactoryLoader() and right
after the first Register back to the itkLoad and then the exception
occurred.
Does this make any sense? Or am I just saying something senseless?
Thanks for any help you can give me,
Sam
Daniel Maleike wrote:
> On Mon, 2009-03-09 at 18:18 +0000, Samuel Silva wrote:
>
>> Hi!
>>
>> Just a message to tell you that I seem to have partially solved the
>> problem.
>>
>> After some debugging I found that the itkLoad function was not returning
>> a proper address to a factory. In fact, it was returning NULL, with the
>> inevitable disaster happening in
>>
>
> Hallo Samuel,
>
> I don't have a working Windows compile for testing right now, but I
> would like to check one thing.
>
> Could you please try to change a line in
>
> src/CMake/ToolExtensionITKFactoryLoader.cpp.in
>
> Just try to remove the static in line 67 where it says
>
> static mitkToolExtensionITKFactoryLoader::Pointer factory =
> mitkToolExtensionITKFactoryLoader::New();
>
> and then try generate the DLL again.
>
> And just to make sure, you have the CMake variables
>
> BUILD_SHARED_LIBS
> MITK_BUILD_SHARED_CORE
>
> set to ON, right?
>
> Regards,
> Daniel
>
> PS: please try to send mails to the mitk-users list if they are of
> general interest.
>
>
>> void ObjectFactoryBase::LoadLibrariesInPath (const char* path).
>>
>> Somehow it seemed to me (although not properly checked) that
>> registering
>> the factories inside the mitkToolExtensionITKFactoryLoader() would
>> result in a new call to itkLoad (due to loading libraries in the
>> autoload path maybe?).
>>
>> What I did was to register the factory for PlainExternalTool directly
>> inside itkLoad and returned its Pointer:
>>
>> itk::ObjectFactoryBase* itkLoad()
>> {
>> static mitk::PlainExternalToolFactory::Pointer factory =
>> mitk::PlainExternalToolFactory::New();
>> return factory;
>> }
>>
>> With this change a new button (External) now appears in the Tools
>> group.
>>
>> Probably I did something weird to provoke this behavior in the first
>> place, right? I say I solved it partially because an exception still
>> occurs on application exit.
>>
>> Sorry for filling your mailbox. :)
>>
>> Regards,
>> Samuel
>>
>>
>>
>> Samuel Silva wrote:
>>
>>> Hello Daniel,
>>>
>>> I hope that you have managed to successfully send your thesis for
>>> printing!
>>> My moment will only come in a couple of years :).
>>>
>>> Regarding registering external Tools in MITK applications I
>>>
>> followed
>>
>>> the instructions present in the link you provided and all went well:
>>>
>> I
>>
>>> managed to compile the tool and set the autoload mechanism working
>>> with no major problems. Unfortunately I ran into an issue during
>>>
>> the
>>
>>> loading process. When loading the new tool the following exception
>>> occurs:
>>>
>>> Unhandled exception at 0x04cba09c (mitkExternalTools.dll) in
>>> MyApp_d.exe: 0xC0000005: Access violation writing location
>>>
>> 0x00000034.
>>
>>> when executing the first factory registration line (or in the next
>>> lines if this one is commented) in
>>>
>>> mitkToolExtensionITKFactoryLoader()
>>> {
>>> itk::ObjectFactoryBase::RegisterFactory(
>>> mitk::PlainExternalToolFactory::New() );
>>> itk::ObjectFactoryBase::RegisterFactory(
>>> mitk::ComplexExternalToolFactory::New() );
>>> itk::ObjectFactoryBase::RegisterFactory(
>>> QmitkComplexExternalToolGUIFactory::New() );
>>> }
>>>
>>> I already tried to run the MainApp (inside the MITK solution) just
>>>
>> to
>>
>>> rule out some possible issue in MyApp and the same exception
>>>
>> occurs.
>>
>>> Well this is not a clear error but I was wondering if you ever run
>>> into such an issue and if you have an idea of its causes. I supposed
>>>
>> I
>>
>>> don't have to link MyApp with any additional library or add any
>>> additional code as the autoload mechanism should be "self
>>>
>> sufficient"
>>
>>> right?
>>>
>>> Sorry for bothering and many thanks for your time and attention,
>>> Samuel
>>>
>>>
>>>
>>>
------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
mitk-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mitk-users
