How to Get Addressability of MainWindow
In a custom widget MyCanvas promoted from Widget in Qt Creator, I need the addressability of MainWindow to execute a function, setMatrix(). The code:
finds the centralWidget and then "MainWindow", but it does not find the setMatrix() function. The message is "class QWidget’ has no member named ‘setMatrix".
What I need is the ui pointer reference to use in MyCanvas, how do I get it?
First of all.
is very bad style.
It would be far better design that MyCanvas defined a new signal
and simply emitted that when it wants setMatrix run
In mainwin, you just have a slot that does it. and in mainwindow (ctor)
you connect new signal to that slot.
However, the reason your his->parentWidget()->parentWidget()-> thing do not work is that
its all base classes, meaning that parentWidget returns a QWidget.
You can then use qobject_cast to get the real mainwindow. ( so it knows it has that function)
But it would be advised to use signal and slot.
I noted in the signal not connecting to slot message, that I was trying this because the signal was not connecting to the slot. That issue is now resolved--totally my mistake. However, it does bring up the issues of addressibility between the MainWindow and it children, in both directions. If I were coding using only classes, then I would have no problem, it is Qt Creator that causes the problem. It does the UI work under the covers and I have not found the correct hooks. In my case I have my custom widget, MyCanvas, and I have a QTableWidget. In mainwindow.cpp I have addressibility to both objects using ui->. But in mycanvas.cpp I have no way to reference the QTableWidget. I need a variable in MyCanvas that is a pointer to MainWindow. My question is how to assign that pointer?
First of all, its by design that UI is private.
For better code and encapsulations, a design using signals and slot will be
less likely to break later as you minimized how much each class knows about its other.
So its not to be in the way, Creator does this. It is to help make better design.
Anyway, you can disable that it generate UI as private. ( or simply move it to public )
And then you can use pointers even it will bring spaghetti code and pain.
"mycanvas.cpp I have no way to reference the QTableWidget"
Well if you really dont want to use signals, then you could add a new function
to give it the pointer to
QTableWidget it should talk to. ( from mainwindow )
But again. Why does it need to know its table. ? if u change it to a TableView, then mycanvas would not work anymore and need change too.
If you use a signal, then mycanvas dont know who uses the signal and it will also work if u add new widgets or change mainwindow.
It will by a long shot be much better than pointers to the inner details of a class. :)
I agree, you are preaching to the choir. In developing Smalltalk applications I enforced a rule that objects should know as little about the objects they communicate with as possible, hopefully nothing. However, when the signals and slots mechanism failed me, I looked for another way. Now that I know it was my fault, I can use signals and slots the way I had originally planned.
Ah i see. Super then.
I failed to realized that you ask this as the signal would not work.
Sorry for preaching then :)