I have a problem with QDialog which is not displayed centered on the parent window.
The following snippet explains it:
void MyWidget::showDialog() {
QObject* p = parent();
while (p!=0) {
qDebug() << p;
p = p->parent();
}
qDebug() << QApplication::activeWindow();
MyClassDerivedFromQDialog dlg( this );
if ( dlg.exec() != dlg.Accepted ) {
return;
}
... do something
}
The output on qDebug is the following
QSplitter(0x2d89930, name = "splitter")
MyWidget(0x2d89670, name = "widget")
MainWindow(0x27ef20, name = "application")
MainWindow(0x27ef20, name = "application")
Executing my example opens the dialog somewhere on the screen. Passing QApplication::activeWindow() as a parent to the dialogs constructor results in a dialog centered on the main window. So why is that and how to track down the problem?
I found that this behavior is related to the timing of the dialog creation.
If you create a QDialog (or a derived class) before the dialog parent is shown (e.g., in the parent constructor), the dialog is displayed at a non-predictable location (or at least, not where you'd expect it to show).
However, if the dialog is created after the parent is displayed, then you get the expected behavior.
For example, if you have a button invoking your dialog. Both the button and the dialog are children of the same widget, so the dialog parent is the same as the button parent. In this case, it is advised to delay the dialog creation until the button is clicked, not before that.
This way, you ensure the dialog is created only after the parent is shown.
I am not sure if understand your problem.
QDialogs are always centered on the widget you pass as parent. This is by design. So if you pass "activeWindow()" as parent it is centered on the active window. If you pass "this" as a parent the dialog is centered above MyWidget.
In which way does your dialog not respect these rules?
The Dialog class is instantiated via
MyClassDerivedFromQDialog::MyClassDerivedFromQDialog(QWidget *parent)
: QDialog(parent),
ui(new Ui::MyClassDerivedFromQDialog)
{
ui->setupUi(this);
//remove the ? button in titlebar
Qt::WindowFlags flags = windowFlags();
Qt::WindowFlags helpFlag = Qt::WindowContextHelpButtonHint;
flags = flags & (~helpFlag);
setWindowFlags(flags);
}
And i always use it as in the showDialog function in the initial post. sometimes it works... And no, i do not have two MyWigets which are parents of each other.
Related
I try to create a custom widget like this:
device.h
class Device : public QWidget
{
Q_OBJECT
public:
explicit Device(QWidget *parent = 0);
};
device.cpp
Device::Device(QWidget *parent) :
QWidget(parent)
{
setGeometry(QRect(0, 0, 100, 100));
setStyleSheet(QString::fromUtf8("background: black;"));
raise();
setVisible(true);
qDebug() << "is visible: " << isVisible();
}
The constructor tries to create the square widget with black background. But I see nothing on my MainWindow and have output like:
is visible: false
It seems I create the device object correctly (ui->centralWidget is parent):
// MainWindow constructor
// device and button pointers defined in mainwindow.h
device = new Device(ui->centralWidget);
button = new QPushButton("Push me!", ui->centralWidget);
I think I could see black square with button or only black square overlaped the button. But I see only the button without any square.
It is not clear for me even because I call setVisible(true) and get isVisible() as false in the next line. But the button (the same child of QWidget) is visible. Where is difference?
The parent widget is likely invisible. Order of events matter, if the parent becomes visible after the constructor of Device, then the isVisible will work as intended when called from a different function after it is displayed. Otherwise, if the parent widget is hidden, all of it's children widgets are also hidden (even if you explicitly state otherwise for the children widgets). When do you call show() on the parent widget? Without a Minimal, Complete, and Verifiable Example
we can only speculate.
I hope this has not been asked before, but I have not found any thread that answers my specific question.
I have created my own QDialog class(TagPopup), which accurately displays the layout I have specified in its Constructor. The QDialog is created in the center of the parent - as expected - but when I move the parent the Dialog stays at its original position. I want it to always stay at the center of the parent widget regardless of where it moves.
The parent is a custom class derived from QMainWindow (PlayerWindow).
WindowFlags of the parent class have not been altered, but the child has to be modal, has to have Qt::WA_TranslucentBackground as an attribute and the Qt::FramelessWindowHint has to be set.
Is this only solvable by overriding the parents move event and then have the child move with it or is there a more elegant solution?
void PlayerWindow::open_tag_dialog(int id) {
TagPopup *dialog = new QDialog(this, GameTag::int_to_tag_type(id), (int) 1000000 * elapsed_seconds(), {this->clip->game->home_team, this->clip->game->away_team});
dialog->show();}
This is the method on the parent Widget which creates and shows the Dialog.
explicit TagPopup(QWidget *parent = 0, TagType tag_type = TagType::CUSTOM, int time = 0, vector<Team*> teams = {}, int min_height = 360) : QDialog(parent, Qt::FramelessWindowHint), BasePlayer(min_height, this){
setModal(true);
setAttribute(Qt::WA_TranslucentBackground);
Qt::WindowFlags flags = windowFlags();
setWindowFlags(flags | Qt::WindowStaysOnTopHint);
These are the first lines of the child constructor, which deal with setting the flags and attributes.
I have definitely tried removing all flags, but that also does not help.
Is QDialog for creating something like a popup? It seemed like the obvious pick. Adding the Qt::Popup flag didn't change the behaviour. It instead broke the whole layout when I passed it to the constructor and didn't add any other flags. Therefore didn't meddle with that idea for too long.
I want to open a Widget from my MainWindow. I thought this was easy to do, and all the tutorials I read do it like this:
void MainWindow::on_pushButton_Types_clicked()
{
m_typesWin = new TypesWindow(m_db, this);
m_typesWin->show();
this->hide();
}
However, this only works for me if I don't pass "this" into the constructor. When I add "this" to the constructor, I don't see the widget, the program just stops. If I don't hide "this", then I can see that parts of my widget are actually in my main window. I have no idea why.
EDIT: The classes are automatically created by QtCreator, so they should be alright.
If you want a QWidget to be displayed as a window, a parent widget should not be specified to that widget. Here, because you specify main window as the parent of TypesWindow, TypesWindow becomes embedded in main window. So when you hide main window, TypesWindow embedded in main window also gets hidden.
Since you want TypesWindow to be a separate window, don't pass parent widget to the QWidget constructor in TypesWindow constructor. If you want to access main window from TypesWindow, you can store main window pointer in a pointer field in TypesWindow.
To open a Mainwindows from the new Qwidget:
1)in the NEWWIDGET.CPP:
QWidget *w;
NEWWIDGET::NEWWIDGET(QWidget *parent,QWidget *win) :
QWidget(parent),
ui(new Ui::NEWWIDGET)
{
ui->setupUi(this);
w=win;
}
..
void NEWWIDGET::on_pushButton_clicked()
{
this->hide();
w->show();
}
2)In the NEWWIDGET.H
public:
explicit NEWWIDGET(QWidget *parent=nullptr,QWidget *win=nullptr);
~NEWWIDGET();
In my SDI application i need to get this behawiour. After I click on a button on the FormView, a CDialog opens. When I press the OK button on the CDialog, I call a function of the FormView. I don't want to close the CDialog. I try to do it with modeless dialog, but when i call formview function from dialog, i can't access to formview's control, like it's lost hwnd; the error is can't read memory of m_hwnd, the hwnd is ???.
This is my code:
Open modeless dialog:
CCampiDlg *m_pDialog = NULL;
HWND hCampi = NULL;
// Invoking the Dialog
m_pDialog = new CCampiDlg;
if (m_pDialog != NULL)
{
BOOL ret = m_pDialog->Create(m_pDialog->IDD, this);
if (!ret) //Create failed.
{
AfxMessageBox(_T("Error creating Dialog"));
}
m_pDialog->ShowWindow(SW_SHOW);
}
when i press the ok button in the dialog i do:
CEditorTxView pView;
box2 = (CEdit*)(GetDlgItem(IDC_CAMPI_BOX2));
box2->GetWindowTextW(campo);
pView.inserisciCampo(1, campo);
In inserisciCampo function in CEditorTxView (CFormView) i have to do operation with my control txtCtrl, but it's lost hwnd. The declaration of txtCtrl is in the CEditorTxView.h
CTx1 txtCtrl;
And initialize it in DoDataExchange function:
void CEditorTxView::DoDataExchange(CDataExchange* pDX)
{
CFormView::DoDataExchange(pDX);
DDX_Control(pDX, IDC_TX1, txtCtrl);
}
Someone can help me plz?
I can give you two answers here:
How to do what you are asking (get access to a control of the CFormView from a modeless dialog)
How to solve your underlying problem (communicate changes in a modeless dialog to the owner view)
For the first one, you have to declare a pointer to the view in the dialog class and initialize it in the constructor of the view:
class CCampiDlg : public CDialog
{
public:
CCampiDlg(CEditorTxView* pView, CWnd*pParent = NULL) // Change declaration to add pointer to view
: m_pView(pView)
{
}
// ... Whatever
private:
CEditorTxView* m_pView;
}
Now in your button handler:
CEdit* box2 = (CEdit*)(GetDlgItem(IDC_CAMPI_BOX2)); // Why not use a control variable?
box2->GetWindowTextW(campo);
m_pView->inserisciCampo(1, campo);
This should do what you are asking for. However, it is the wrong way to do it.
The problem with this approach is that the dialog knows way too much about its parent. It knows it is of type CEditorTxView and that it has a member called inserisciCampo, that takes a number and some text.
It shouldn't know that much. In fact, knowing anything about it, other than it is of type CView or even CWnd, is too much.
If the dialog knows about the view, you can't reuse the dialog with other views, and anytime the view changes its representation (what now is a textbox may be a combobox in the future, for example) the dialog must change accordingly.
The solution would be to send a message to the parent, explaining what's happened. Then the parent (the view) should know haw to handle that event. For example:
class CCampiDlg : public CDialog
{
public:
CCampiDlg(CWnd*pParent = NULL) {}
protected:
OnOk()
{
CString campo;
c_CampiBox2.GetWindowText(campo);
GetParent()->SendMessage(UWM_CAMPO2_SET, 0, (LPARAM)&campo);
}
}
In the view:
// It can be ON_REGISTERED_MESSAGE:
ON_MESSAGE(UWM_CAMPO2_SET, OnCampo2Set)
//...
LRESULT CEditorTxView::OnCampo2Set(WPARAM, LPARAM lParam)
{
CString* s = (CString*) lParam;
inserisciCampo(1, *campo);
return 0;
}
Now, you have decoupled the view and the dialog. The dialog knows nothing about the view. You can change its type, change the representation, even make it a dialog, and you don't have to change anything in the dialog. And if you need that same modeless dialog somewhere else, you just drop it there, create a message handler in the parent, and voilà!
For further explanations and better examples, check these articles:
Dialog and control design (Your case is explained in the section "Notifications to the environment")
Message management
On Ok button click the below code is running:
CEditorTxView pView;
box2 = (CEdit*)(GetDlgItem(IDC_CAMPI_BOX2));
box2->GetWindowTextW(campo);
pView.inserisciCampo(1, campo);
Note that, you are creating the new pView in stack and it does't attach with any window. You are not actually referring the view that already created and launched your dialog acting a parent. Revisit the above code and try the get the view:
Try the below code, if it is not working (Google it)
CFrameWnd * pFrame = (CFrameWnd *)(AfxGetApp()->m_pMainWnd);
CView * pView = pFrame->GetActiveView();
I created a little widget on my own, including a QProgressBar and a QLabel in a QVBoxLayout. It has also a function which returns the text of the label (self-created).
Now in my MainWindow I have two other QHBoxLayouts and I want to drag and drop my widget from one to another. It also works when I click on the little free space between the QLabel and the QProgressBar. But when I click on one of them directly, the application crashed and burned painfully.
I also know where it fails. My mousePressEvent looks like this:
void DragDrop::mousePressEvent(QMouseEvent *event) {
// !!!!---- make sure ONLY MyWidgets are here, else: CRASH ----!!!!
MyWidget *child = static_cast<MyWidget*>(childAt(event->pos()));
if (!child)
return;
qDebug() << child->returnLabelText();
...
}
So when I click on the ProgressBar, it will cast the ProgressBar, not my own widget. And because the QProgressBar doesn't have a function like returnLabelText() (but my widget does) it fails.
What is a better method to get my widget?
QWidget::childAt(int,int) returns the child widget, not the parent widget. In your case, it returns the QProgressBar. You then try to cast into a MyWidget, which it is not. What you are looking for is for the parent of the QProgressBar (or QLabel).
static_cast does not verify the type of the object you are trying to cast, and will always yield a non-null pointer even if the cast is invalid. What you are looking for here is dynamic_cast, which will return NULL if the object is not of the type you are looking for. Since you are looking for the parent (or an ancestor) of the widget being clicked, you could use a loop to iterate through the clicked widget's ancestry to find the instance of MyWidget you are looking for.
void DragDrop::mousePressEvent(QMouseEvent *event) {
QWidget *widget = childAt(event->pos());
do {
MyWidget *myWidget = dynamic_cast<MyWidget*>(widget);
widget = widget->parentWidget();
} while (myWidget == NULL && widget != NULL)
if (myWidget == NULL)
return;
qDebug() << myWidget->returnLabelText();
// ...
}