QMetaType usage

Hi,

I have a non-Qt type that I am trying to use in a signal/slot connection. I would like to do the following:

In Header

Code:

---

class MyClass
{
...
    signals:
        void negotiate( const unsigned int& timeout, const eos::ResourceSetRequest& request );
...
}

---

In CPP

Code:

---

void MyClass::someFunction()
{
    emit negotiate( timeout, request );
}

---

However, when I try this the connection isn't being made. From the documentation it looks like I need to register the type eos::ResourceSetRequest as a QMetaType before it can be sent as a signal argument.

Is this correct?

If so, then how do I register the non-Qt type as a new QMetaType?

It looks like I need to place the following in the CPP file:

Code:

---

Q_DECLARE_METATYPE(eos::ResourceSetRequest);
int reqID = qRegisterMetaType<eos::ResourceSetRequest>("eos::ResourceSetRequest");

---

However, when I do this I get the following compile error:
c:\Qt\4.1.4\include\QtCore\../../src\corelib\kernel\qmetatype.h(85) : error C2512: 'eos::ResourceSetRequest' : no appropriate default constructor available
c:\Qt\4.1.4\include\QtCore\../../src\corelib\kernel\qmetatype.h(97) : see reference to function template instantiation 'void *qMetaTypeConstructHelper<T>(const T *)' being compiled
with
[
T=eos::ResourceSetRequest
]
DeviceQResourceFrame.cpp(22) : see reference to function template instantiation 'int qRegisterMetaType<eos::ResourceSetRequest>(const char *,T *)' being compiled
with
[
T=eos::ResourceSetRequest
]

Is this a Qt problem or a problem with constructing the non-Qt class?

Any advice on this would be greatly appreciated.

As it says in the docs:

Quote:

---

Any class or struct that has a public constructor, a public copy constructor, and a public destructor can be registered.

---

Make sure that eos::ResourceSetRequest compliances with the requirements.

I have now sorted this out.

Declaring a pointer to the non-Qt class as a new Meta-Type and then passing the pointer through the signal/slot connection did the trick.

Who's responsible for freeing the memory? :)

A good point. I had to implement another signal/slot connection to free the memory that was being allocated just prior to the signal being emited. The main reason I went down this path was because the signal needed to be emitted from a callback function inside a .dll. Passing the pointer through the signal/slot connection was a little messy but it got the required information across the .dll boundary to my application which would then emit another signal to tell the .dll code to free up the memory.

Out of interest I attempted to pass a Boost shared pointer through the connection but that didn't seem to work. Has anyone else tried passing a Boost::shared_ptr through a signal/slot connection?