Pytanie jest dość mocno specyficzme dla QT, nie wiem w sumie czy to jeszcze jest C++. Ad rem:
piszę plugin-widget dla QT designera, w formie DLLki. Założenie jest takie, że on nie będzie w ogóle dostępny w compile-timie, jedynie przez dynamiczne wczytywanie pliku UI.
DLLka kompiluje się ok, dodaje się do designera, layout się wczytuje.
No i teraz tak: chciałbym wykesponować sobie "na zewnątrz" libki sygnały. Bez nich, interfejs wygląda tak:
class DLL_EXPORT Interface : public QAbstractButton
{
public:
using QAbstractButton::QAbstractButton;
virtual ~Interface() = default;
public slots:
virtual void mySlot(bool x) = 0;
};
Q_DECLARE_INTERFACE(Interface, "alagner.if.test/1.0")
To wszystko działa, mogę podłączać sygnały z QAbstractButton
, sielanka.
Ale teraz chciałbym dopisać sobie coś w stylu:
signals:
mySignal(bool x);
i tu zaczyna się jazda. Muszę dołożyć makro Q_OBJECT
. Wtedy odpala się MOC, marudzi o brak implementacji. Zrozumiałe.
No to wyrzucam Q_OBJECT
, a pomny tego, że signal to w sumie generowana metoda, robię tak
class DLL_EXPORT Interface : public QAbstractButton
{
Q_OBJECT
// CIACH
signals:
virtual void mySignal(bool x) = 0;
To się kompiluje ...tak długo jak nie próbuję podpiąć mySignal
, wtedy się wywala.
No i pytanie: czy da się kompilatorowi powiedzieć: "ten signal jest w DLL"? Próbowałem connect zarówno ze składnią "makrową/tekstową" jak i wskaźnikową.
Workaround to zawrapować connect wewnątrz publicznej metody, typu QMetaObject::Connection connectToMySignal(QObject receiver, const char* slot);
. Mało to eleganckie, ale działa. Pytanie, czy da się lepiej.
@MarekR22 może Ty będziesz wiedzieć?