moc.html

qtopiaphone英文帮助,用于初学者和开发人员,初学者可以用来学习,开发人员可以用来资料查询.

    class Right : public QObject, virtual public OtherClass {
    [...]
    };
</pre>
<p>
<h4>Virtual functions cannot be slots when using multiple inheritance</h4>
<p>
This problem occurs if you are using multiple inheritance. If you
reimplement a virtual function as a slot <strong>and</strong> that
function was originally declared in a class that does not inherit
QObject, your program may crash when a signal triggers the slot.
(This only happens with some compilers.)
<p>
The following example shows one wrong and two correct slot definitions.
<pre>    class BaseClass {
    [...]
        virtual void setValue( int );
    };

    class SubClass : public QObject, public BaseClass {
    [...]
    public slots:
        void setValue( int ); //virtual from BaseClass, error.
        void slotSetValue( int i ) { setValue(i); } //new function, ok.
        void setName( const char* ); // virtual from QObject, ok.
    };
</pre>
<p>
(For those interested in C++ internals: The cause of this problem is
that a slot is internally represented as a function pointer, and
invoked on a QObject pointer. )
<p>
<h4>Function pointers can not be arguments to signals or slots</h4>
<p>
In most cases where you would consider that, we think inheritance is a
better alternative.  Here is an example of illegal syntax:
<p>
<pre>    class someClass : public QObject {
        Q_OBJECT
    [...]
    public slots:
        void apply(void (*applyFunction)(<a href="qlist.html">QList</a>*, void*), char*); // illegal
    };
</pre>
<p>
You can work around this restriction like this:
<pre>    typedef void (*ApplyFunctionType)(<a href="qlist.html">QList</a>*, void*);

    class someClass : public QObject {
        Q_OBJECT
    [...]
    public slots:
        void apply( ApplyFunctionType, char *);
    };
</pre>
<p>
<p>
(It may sometimes be even better to replace the function pointer with
inheritance and virtual functions, signals or slots.)
<p>
<h4>Friend declarations can not be placed in signals or slots sections</h4>
<p>
Sometimes it will work, but in general, friend declarations can
not be placed in signals or slots sections.  Put them in the good old
private, protected or public sections instead.  Here is an example of
the illegal syntax:
<p>
<pre>    class someClass : public QObject {
        Q_OBJECT
    [...]
    signals:
        friend class ClassTemplate&lt;char&gt;; // illegal
    };
</pre>
<p>
<h4>Signals and slots cannot be upgraded</h4>
<p>
The C++ feature of upgrading an inherited member function to
public status is not extended to cover signals and slots.  Here is an
illegal example:
<p>
<pre>    class Whatever : public QButtonGroup {
    [...]
    public slots:
        void QButtonGroup::buttonPressed; // illegal
    [...]
    };
</pre>
<p>
The QButtonGroup::buttonPressed() slot is protected.
<p>
C++ quiz: What happens if you try to upgrade a protected member
function which is overloaded?
<ol>
<li> All the functions are overloaded.
<li> That is not legal C++.
<!-- C++ ARM, section r.11.3 -->
</ol>
<p>
<h4>Type macros can not be used for signal and slot arguments</h4>
<p>
Since the moc does not expand #define, type macros that take an argument
will not work in signals and slots. Here is an illegal example:
<p>
<pre>    #ifdef ultrix
    #define SIGNEDNESS(a) unsigned a
    #else
    #define SIGNEDNESS(a) a
    #endif

    class Whatever : public QObject {
    [...]
    signals:
        void someSignal( SIGNEDNESS(a) );
    [...]
    };
</pre>
<p>
A #define without arguments will work as expected.
<p>
<h4>Nested classes cannot be in the signals or slots sections nor have
signals or slots</h4>
<p>
Here's an example:
<p>
<pre>    class A {
        Q_OBJECT
    public:
        class B {
        public slots:   // illegal
            void b();
        [....]
        };
    signals:
        class B {       // illegal
            void b();

        [....]
        }:
    };
</pre>
<p>
<h4>Constructors can not be used in signals or slots sections</h4>
<p>
It is a mystery to me why anyone would put a constructor on
either the signals or slots sections.  You can not, anyway (except
that it happens to work in some cases).  Put them in private,
protected or public sections, where they belong.  Here is an example
of the illegal syntax:
<p>
<pre>    class SomeClass : public QObject {
        Q_OBJECT
    public slots:
        SomeClass( <a href="qobject.html">QObject</a> *parent, const char *name )
            : <a href="qobject.html">QObject</a>( parent, name ) {}  // illegal
    [...]
    };
</pre>
<p>
<h4>Signals and slots may not have default arguments</h4>
<p>
Since signal->slot binding occurs at run-time, it is
conceptually difficult to use default parameters, which are a
compile-time phenomenon.  This will fail:
<p>
<pre>    class SomeClass : public QObject {
        Q_OBJECT
    public slots:
        void someSlot(int x=100); // illegal
    };
</pre>
<p>
<h4>Signals and slots may not have template arguments</h4>
<p>
Declaring signals and slots with template-type parameters will not
work as expected, even though the moc will not complain. Connecting the
signal to the slot in the following example, the slot will not get
executed when the signal is emitted:
<p>
<pre>   [...]
   public slots:
       void MyWidget::setLocation (pair&lt;int,int&gt; location);

   [...]
   public signals:
       void MyObject::moved (pair&lt;int,int&gt; location);
</pre>
<p>
However, you can work around this limitation by explicitly typedef'ing
the parameter types, like this:
<p>
<pre>   typedef pair&lt;int,int&gt; IntPair;       
   [...]
   public slots:
       void MyWidget::setLocation (IntPair location);

   [...]
   public signals:
       void MyObject::moved (IntPair location);
</pre>
<p>
This will work as expected.
<p>
<h4>Namespace of parent class must be specified even if it is the same as
that of the subclass</h4>
<p>
In the following example, classes x::A and x::B are defined:
<p>
<pre>    namespace x {
        class A : public QObject {
            Q_OBJECT

        public:
            ...
        };
    }

    namespace x {
        class B : public A {
            Q_OBJECT

        public:
            ...
        };
    }
</pre>
<p>
Unfortunately, moc will not understand the
<pre>        class B : public A {
</pre>
<p>
line. You have either to write
<pre>        class B : public x::A {
</pre>
<p>
or define classes A and B in the same namespace block.
<p>
This limitation will disappear with Qt 3.0.
<p>
<h4>Properties need to be declared before the public section that
contains the respective get and set functions</h4>
<p>
Declaring the first property within or after the public section that
contains the type definition and the respective get and set functions
does not work as expected. The moc will complain that it can neither
find the functions nor resolve the type. Here is an example of the
illegal syntax:
<p>
<pre>    class SomeClass : public QObject {
        Q_OBJECT
    public:
    [...]
        Q_PROPERTY( Priority priority READ priority WRITE setPriority ) // illegal
        Q_ENUMS( Priority ) // illegal
        enum Priority { High, Low, VeryHigh, VeryLow };
        void setPriority( Priority );
        Priority priority() const;
    [...]
    };
</pre>
<p>
Work around this limitation by declaring all properties at the
beginning of the class declaration, right after Q_OBJECT:
<p>
<pre>    class SomeClass : public QObject {
        Q_OBJECT
        Q_PROPERTY( Priority priority READ priority WRITE setPriority )
        Q_ENUMS( Priority )
    public:
    [...]
        enum Priority { High, Low, VeryHigh, VeryLow };
        void setPriority( Priority );
        Priority priority() const;
    [...]
    };
</pre>
<p>

<p><address><hr><div align="center">
<table width="100%" cellspacing="0" border="0"><tr>
<td>Copyright