Hi Benjamin,
please always post to mitk-users, so others can benefit from our discussion.
If you don't export any symbols in your bundle, you will not get a .lib
file. Why do you want to link to a bundle which does not export any symbols?
Note that all bundles which do not explicitly export symbols but which
hook into the extension point mechanism with an executable extension (a
class name) or provide an Activator class will export C functions
through the use of the POCO_EXPORT_CLASS macro in their manifest.cpp
file. Hence they have .lib file.
Best,
Sascha
On 12/09/2010 10:40 AM, Benjamin Knecht wrote:
Hi,
Yes, I develop outside of the MITK source tree in my own directory. So
this might be the problem. The default path for the .lib file is where
the BuildLog.htm ends up as well as the .obj files and the manifest
files for the dll.
I tried it now with a plugin/bundle, but also there is no .lib file
that is generated, instead there is also just a dll that is generated.
This may be, because the bundle doesn't have a view (I unchecked the
'GUI_SUPPORT' option), but I'm not sure. Other plugins that I created
(with gui support) work well and create a .lib file. At least the
directory is the correct one.
Regards,
Benjamin
On Tue, Dec 7, 2010 at 09:22, Sascha Zelzer
<[email protected] <mailto:[email protected]>> wrote:
Hi,
Are you developing your code inside the MITK source tree, or in an
"external" directory? In the latter case, I'm not sure if modules
are supposed to work. What is the unmodified output path for your
.lib file in the Visual Studio project settings? It worked for me
under Linux, but I don't know about Windows.
Bundles (aka Plugins) work well in external projects, so if the
module approach is not working, you could convert your module into
a bundle.
Best,
Sascha
On 12/06/2010 08:07 PM, Benjamin Knecht wrote:
Hi Sasha,
thanks a lot. I already tried the approach with the module, but
my module failed to create a .lib file to link to the bundles
that require the module. I changed the configuration in Visual
Studio, but I also had to change the output directory. Can't this
be achieved automatically with the CMake setup?
Best, Benjamin
On Sat, Dec 4, 2010 at 16:03, Sascha Zelzer
<[email protected]
<mailto:[email protected]>> wrote:
Hi Benjamin,
there is no generic messaging component in MITK (yet). But
depending on
your requirements, you have quite a few options.
If you don't want to introduce dependencies between your
plugins, you
could do one of the following:
- Use QEvent objects as you suggested. You could create one
plugin
which declares a QEvent subclass (or multiple) which can be
used by all
other plugins to send/receive your custom events.
- Use a similar approach as above, but with mitk::Message.
Create a
separate plugin containing a "message broker", which manages
one or more
mitk::Message instances to which consumers can subscribe.
This avoids
the direct coupling between your plugins.
The key in both scenarios for a generic messaging system (in
my opinion)
is to use a map (std::map, QHash, etc) containing the message
parameters. Don't try to use a lot of QEvent subclasses or many
mitk::Message[1|2|3|4] instances with different template
parameters
(unless your set of events don't need to be extendible by
plugins).
To make the classes from your "messaging plugin" available,
just add the
following line to the META-INF/MANIFEST.MF file of your plugins:
Require-Bundle: <your-messaging-plugin-symbolic-name>
You could also use MITK_CREATE_MODULE, to create a "normal"
shared
library. Then add the dependency to it in your plugins
CMakeLists.txt
file by adding the module name as an argument to the
MACRO_CREATE_MITK_PLUGIN() macro call (see any of the
existing MITK
bundles).
Of course you can always introduce direct dependencies (by
using the
"Require-Bundle" header in the MANIFEST.MF file) between your
plugins
and call methods on their public API. Just cast the result of
this->GetSite()->GetPage()->FindView("name.of.the.plugin")
to the correct type, or use other methods (for example use
services and
the service registry) to access instances from other plugins.
Best,
Sascha
On 12/02/2010 05:38 PM, Benjamin Knecht wrote:
> Dear all,
>
> I work on a project where we use MITK and write our own
plugins. Now
> the plugins work pretty well independently, but to improve our
> workflow we want to communicate between the plugins. We
managed to get
> a reference to another plugin using
>
> this->GetSite()->GetPage()->FindView("name.of.the.plugin");
>
> Now we want to send messages. Using the message framework
from MITK
> seems to require the sender to know the class of the
receiver, which
> is not possible or useful with plugins. Another idea was to
use our
> own events inheriting from QEvent, but we have no idea how
to include
> them as a dependencies in CMake for our plugins. Could we
use the
> MITK_CREATE_MODULE macro or is there a better way to make
certain
> classes available to all plugins?
>
> cheers, Benjamin
------------------------------------------------------------------------------
What happens now with your Lotus Notes apps - do you make
another costly
upgrade, or settle for being marooned without product
support? Time to move
off Lotus Notes and onto the cloud with Force.com, apps are
easier to build,
use, and manage than apps on traditional platforms. Sign up
for the Lotus
Notes Migration Kit to learn more.
http://p.sf.net/sfu/salesforce-d2d
_______________________________________________
mitk-users mailing list
[email protected]
<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/mitk-users
------------------------------------------------------------------------------
This SF Dev2Dev email is sponsored by:
WikiLeaks The End of the Free Internet
http://p.sf.net/sfu/therealnews-com
_______________________________________________
mitk-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mitk-users