Usually when this happens you need to re-run qmake and make sure you've implemented all the slots for your class.
Usually when this happens you need to re-run qmake and make sure you've implemented all the slots for your class.
Where is StelModule defined, and where implemented?undefined reference to 'vtable for StelModule'
Can we see the code for that?
Does StelModule derive from QObject - does is call Q_OBJECT macro?
==========================signature=============== ==================
S.O.L.I.D principles (use them!):
https://en.wikipedia.org/wiki/SOLID_...iented_design)
Do you write clean code? - if you are TDD'ing then maybe, if not, your not writing clean code.
Is it OK to post someone else's code?
high_flyer, the StelModule class is defined in StelModule.hpp. This is not one of my classes but part of an open source project that is licencsed under GNU. Since its accessible to all anyway so I'm sure there should be not problem in at least providing this snippet of the class definition:
Qt Code:
{ // Do not add Q_OBJECT here!! // This make this class compiled by the Qt moc compiler and for some unknown reasons makes it impossible to dynamically // load plugins on windows. public: StelModule() {;} virtual ~StelModule() {;} //! Initialize itself. //! If the initialization takes significant time, the progress should be displayed on the loading bar. virtual void init() = 0; //! Called before the module will be delete, and before the openGL context is suppressed. //! Deinitialize all openGL texture in this method. virtual void deinit() {;} etc...To copy to clipboard, switch view to plain text mode
It appears to be derived from the QObject class but it does not have the Q_OBJECT macro. I would point out though that the code for other plugins to this project, including the provided examples, have a Q_OBJECT macro in their class definition.
Also, the presence of the Q_OBJECT macro in the GpsLocatorStelPluginInterface class does not seem to generate an error. I tested this by commenting out the GpsLocator class and its corresponding implementation in the CPP file. The remaining code compiled without errors.
The comment after the class header is interesting and may be relevant, but I'm not sure what it means, except that evidently someone was having trouble with moc...
Last edited by stargazer; 12th January 2011 at 10:41.
Code snippets, specially of a class decleration will not be of much interest to anyone.
At any rate, you can answer my last question, and check it in your code, with out posting any code.
==========================signature=============== ==================
S.O.L.I.D principles (use them!):
https://en.wikipedia.org/wiki/SOLID_...iented_design)
Do you write clean code? - if you are TDD'ing then maybe, if not, your not writing clean code.
Ok, noted for future reference!
vpicaver, [I]'ve tried adding slots and signals but that made no difference.
According to the information in the QT reference documentation, the QT_OBJECT macro is mandatory, but slots and signals are not.
However this seems to indicate that I need to run the Meta Object Compiler, however the information I found in the linked page suggests seems to state that this is already done automatically:Notice that the Q_OBJECT macro is mandatory for any object that implements signals, slots or properties. You also need to run the Meta Object Compiler on the source file. We strongly recommend the use of this macro in all subclasses of QObject regardless of whether or not they actually use signals, slots and properties, since failure to do so may lead certain functions to exhibit strange behavior.
Isn't qmake run every time you compile?We recommend using the qmake makefile generation tool for building your makefiles. This tool generates a makefile that does all the necessary moc handling.
Lets make some things clear:It appears to be derived from the QObject class but it does not have the Q_OBJECT macro. I would point out though that the code for other plugins to this project, including the provided examples, have a Q_OBJECT macro in their class definition.
the Q_OBJECT macro is only needed (and moc'ing), if you are using signals and slots.
If you are not using signal/slots, you don't have to use Q_OBJECT and you don't have to moc that class.
Therefore I would not put Q_OBJECT macro in the interface since this will force all implementing class to use it- which is not always what you want.
==========================signature=============== ==================
S.O.L.I.D principles (use them!):
https://en.wikipedia.org/wiki/SOLID_...iented_design)
Do you write clean code? - if you are TDD'ing then maybe, if not, your not writing clean code.
Bookmarks