Hey Sasha, Since I'm not used to development on Windows the missing exports didn't ring a bell at first. I was able to use the macro provided by the generated header file and now it seems to work well.
Thanks for helping out and sorry I missed out at replying to the list before. Best, Benjamin On Thu, Dec 9, 2010 at 14:22, Sascha Zelzer <[email protected]>wrote: > 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]>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]>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] >>> https://lists.sourceforge.net/lists/listinfo/mitk-users >>> >> >> >> > >
------------------------------------------------------------------------------
_______________________________________________ mitk-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mitk-users
