Switch the order of the construction of objects. When the parent's destructor runs it'll try to free its children, but since you've created it after the child (hence its destructor will be called first), it will try to delete a stack object.
I would give MyMessageHandler only 1 slot. Inside this slot, query the QMpiMessage to discover its subclass, and then call the appropriate function to process it.
I was more interested in the meta-object magic I have to perform, to call the appropriate function, but I think I'd found how to do it.
That's a bit like asking "How to connect to QSlider::valueChanged(int), and invoke different slots depending on whether the value is odd or even?" The answer is: You can't. Slots are invoked based on the sender object ID and the signal ID, but not the signal parameter values.
In your description, you only have 1 signal. All slots connected to that signal will be invoked each time the signal is emitted. Emitting a signal that carries a different subclass of QMpiMessage is just like emitting a signal that carries a different number. If you want to invoke different slots, then you need to emit different signals.
Fair enough. I admit I've used "connect" and "slot" a bit frivolously, so I probably need to put more effort in writing clearer questions. In any case, your comment I believe pointed me in the right direction, so I thank you for that!
@mrjj I believe you are correct. I found out that the problem is my use of Q_DECLARE_OPAQUE_POINTER. It apparently prevents the meta type from registering as being derived from a QObject, which makes sense since at that point there's no way for Qt to know what the class is.
I refactored my code so that MyClass_p is no longer private or forward declared, and it fixed the issue.
Let me tone down this discussion by saying that the original reason for my question has disappeared. I misunderstood how QPrinter worked. I thought I would need the string versions of the QPrintDialog enums to pass on to lp. Turns out QPrinter does what I need to do automatically and I don't need to call lp. Thanks for the lively discussion though.