Hello, In the current implementation, the template shouldn't be instantiated directly. For an example, see the basic_ec plugin:
< http://ktechlab.git.sourceforge.net/git/gitweb.cgi?p=ktechlab/ktl-zoltan_p;a=commitdiff;h=f4e1cb13333cbcd0f802183fe44a52df970c9a75 > The DECLARE_ELEMENT_FACTORY_MEMBER macro can be used to declare a variable of the template type, usually in a class. REGISTER_ELEMENT_FACTORY creates an instance of the above declared member and registers it in the simulation manager. UNREGISTER_ELEMENT_FACTORY unregisters the instance. All 3 macros take as parameter only the type of the new element. The template class has the parameter <class ElementType> the new element type, and its constructor takes as argument the ID of the element type. It's not necessary to instantiate the template manually. In the current form, support for a new element can be added as follows: In the plugin body: DECLARE_ELEMENT_FACTORY_MEMBER( NewElement ); In the plugin constructor / on load: REGISTER_ELEMENT_FACTORY( NewElement ) at unload: UNREGISTER_ELEMENT_FACTORY( NewElement ); where NewElement is the class of the new element type. For any new elements, all 3 macros have to be called again. This implementation could be used from any plugin, so it should be moved somewhere else, I guess in the interfaces folder. Other implementation, that would scale even better, could be used as following: outside of any class: DECLARE_ELEMENT_FACTORY( FactoryName, SUPPORT_ELEMENT( Element1 ) SUPPORT_ELEMENT( Element2 ) // and so on... ); And the plugin can look like: class MyPlugin : public IPlugin { FactoryName *m_factory; MyPlugin() { m_factory = new FactoryName(); ISimulationManager::self()->registerElementFactory(m_factory); } void unload(){ ISimulationManager::self()->unregisterElementFactory(m_factory); } }; This way, adding 1 new component takes 2 new lines in the source: one for including its header, and the other to call a macro. The implementation of the macros could be done by using many if-s internally, but that shouldn't be visible to the programmer. Opinions about this? Zoltan 2010/7/27, Julian Bäume <jul...@svg4all.de>: > moin Zoltan, > could you provide some more information for the use of > GenericElementFactory? Are the macros you defined supposed to be used from > other plugins as well? Then this code shouldn't be inside a plugin. At least > to me, this looks quite generic. Then the plugins would only be used to > define specific instances of components. This could look like: > > // my cool > resistor > implementation > DECLARE_ELEMENT_FACTORY(KTechLab::Element::Resistor); > > REGIST > ER_ELEMENT_FACTORY(ElementFactory<KTechLab::Element::Resistor>); > > class > KTechLab::Element::Resistor: public IElement { > //implementation > }; > > It > would be cool to be able to just provide support for new components like > this. (Okay, one still needs to create visual representation, but this is > easy, too.) > > bye then > julian > ------------------------------------------------------------------------------ The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://ad.doubleclick.net/clk;226879339;13503038;l? http://clk.atdmt.com/CRS/go/247765532/direct/01/ _______________________________________________ Ktechlab-devel mailing list Ktechlab-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ktechlab-devel
