Going up the learning curve and everything has been making sense so far except for this one:
I have a main window from where I call one or more dialog like this:
d->setWindowFlags(Qt::CustomizeWindowHint | Qt::Window | Qt::FramelessWindowHint);
d->setGeometry(etc...
d->show();
The dialogs are not bound to the main window, and they are actually set to be displayed right beside the main window looking like an extension.
To close the dialogs I use a mouse 'enterEvent' on the mainwindow to send a close signal to the dialog(s) which will use hide().
void MainWidget::enterEvent(QEvent *event)
{
emit signal_related_close();
}
This works but randomly this causes a very annoying issue. When the signal is sent to close the dialogs, the main window would loose focus and go in the background (behind whatever application that is on the screen). Note that it does not minimize but only goes in the background and like I said it is random (about one out of 3 times I do it). I can't seem to get a pattern.
I initially thought the signal was messed up and instead used a dialog::leaveEvent() but that didn't help. I also tried using dialog::mouseMoveEvent and using that to hide the dialog but that would still randomly loose focus on the application.
The only method that doesn't loose focus is using a push button on each dialog that will initiate the same hide commands but that's not great for my UI. So it would seem that using the mouse enterEvent/leaveEvent,mouseMoveEvent will cause that random issue.
Anyone experienced this issue before? Any idea what could be wrong? Thx.
I can't explain why but this problem occurred when using QEvent or any mouse related event together with recursive children widgets. For example take this code in the parent widget constructor:
ChildWidget c1 = new ChildWidget (this);
ChildWidget c2 = new ChildWidget (c1);
Childwidget c3 = new ChildWidget (c2);
Using QEvent in the parent widget will randomly make the window go to the background and loose focus.
Setting all the ChildWidget to the same parent stopped the problem.
Related
I have a application in Qt, and a MainWindow. Now, I also added a helping QDialog which can be hooked up. This QDialog does not influence the programmflow, it just displays information.
But, it always starts on top of the MainWindow :/
SO I would like to start it on the side of the main window, so that it does not hinder the view to the main window?? How?
In my opinion , You should try this,
Use the overload of the QWidget::setParent() function to change the ownership of a QDialog widget, using set as NULL(but It will not share the parent's taskbar entry).
QDialog::show() returns control to the caller immediately, So it will not interfere in mainwindow flow.
Let's say, your application is in the full screen mode. Where then the QDialog should appear? It will be shown on the top and you won't be satisfied again.
If it doesn't influence the flow of the app then you are using it to communicate some sort of message. Can you use different ways? For instance, QStatusBar?
If not, why not to split the mainWindow with QSplitter or similar classes and provide an area where you can post all the info messages?
It sounds you want modaless dialog. In main window, use a slot to create the dialog.
void MainWindow::show_dialog()
{
if ( pDialog== NULL )
pDialog= new XYZ_Dialog(this);
QPoint p = pos();
QSize s = frameSize();
pDialog->setGeometry(p.x()+s.width(), p.y(), s.width()*1/2, s.height());
pDialog->show();
}
What I try to say is if the position of the new dialog bothers you, you set the position and size of it, before showing it.
My application has non-rectangular popup widgets.
their class defines the following to achieve that transparency:
setAttribute(Qt::WA_NoSystemBackground, true);
setAttribute(Qt::WA_TranslucentBackground, true);
I also use:
this->setWindowFlags(Qt::Popup| Qt::FramelessWindowHint);
The problem is that on windows 7, an automatic "shadow" is being drawn on the bottom and right sides of my window. This is highly undesirable.
So, I tried using Qt::Tool instead of Qt::Popup
this->setWindowFlags(Qt::Tool | Qt::FramelessWindowHint);
This works visually. No shadow, but now a mouse click outside my widget window will not automatically close/hide it as it would have done with a Qt::Popup.
So, I need one of these two solutions:
A way to have Qt::Popup and get rid of that automatic windows shadow decoration
A way to let the Qt::Tool window a mouse click occurred outside of it.
One note: My application is built for Windows XP and up. I cannot use a Vista/Win7 only runtime DLLs, nor can i have a "Windows XP" and "Vista and up" separate builds.
Any advice will be welcome.
You could manually watch for when the focus changes from your Qt::Tool window. So basically you watch for when the focus goes onto another window of your process or when your application loses focus.
How to detect that my application lost focus in Qt?
Hope that helps.
Finally after realizing that no amount of "SetFocusPolicy" calls will allow me to receive those events for a Qt::Tool window, I've resorted to something else to fix my problem:
I kept the Qt:tool as Qt::Popup caused an undesired shadowing effect, tarnishing my owner draw frame. Removing this style cannot be done in Qt and I didn't want to mess with platform specific conditional code.
I installed an event filter with my Qt::tool window and I began receiving events that assisted me in understanding when other parts of my application were clicked, or if the application itself lost focus to another application. This was what I needed, functionality wise. I could also get an event when users click the non-client areas of the application's main window, such as the windows caption so that I can close it when dragging begins etc.
My solution for Windows 7:
QDialog *d = new QDialog;
d->setStyleSheet("background:transparent;");
d->setAttribute(Qt::WA_DeleteOnClose, true);
d->setAttribute(Qt::WA_TranslucentBackground, true);
#ifdef Q_OS_WIN
d->createWinId();
#endif
d->setWindowFlags(Qt::Popup | Qt::FramelessWindowHint);
d->show();
I set my QListView
d->setWindowFlags(Qt::Popup | Qt::FramelessWindowHint);
Install eventfilter and used MousePressEvent to hide qlistview widget.
MousePressEvent on list never comes to filter they produce other events which I didn't debug.
So if you want to design auto completer this will be perfect. Tested in Qt5.3.1.
I have 2 column. One of the columns is filled with lots of QWidgets.
When I drop a widget in a column I call this method:
void MainWindow::scrollToItem(Product_View *item) {
QPoint point = item->mapToParent(QPoint());
ui->scrollArea->ensureVisible(point.x(), point.y());
}
When I am at the bottom of the first column and I drag a widget in the next one. The scrollarea scrolls properly to the bottom so that I can see where I dropped it.
But when I drop the widget back in the first column, it scrolls but not entirely to the bottom. Its of about 150px (EDIT: 150px is not true. I only see about 5px of the Widget)
Can anybody help me?
EDIT:
maybe good to know my layout.
I have a mainwindow with a QScrollArea.
The scrollArea has a QWidget called scrollAreaWidgetContents and it has a QHBoxLayout.
The widget has 5 columns. And these have QVBoxLayout for my drag and drop widgets.
JEEZ ANOTHER EDIT:
I notice it only goes wrong with the last item.
I JUST KEEP ON EDITING
It is now clear to me that the scrollbar just isn't going all the way down.
QScrollBar *bar = ui->scrollArea->verticalScrollBar();
bar->setValue(bar->maximum());
This code also shows the same behaviour. What should I do with this thread? And should I create a new one?
The ensureVisible function only takes a point, so using it will only guarantee that one corner of your widget is visible (the top left, I believe?). Try using ensureWidgetVisible instead - this should make sure the entire widget makes it on-screen.
Hope that helps!
Although this is an older post I encountered the same problem and it gave me a lot of trouble finding a solution.
My problem:
Had to add a new line to a widget and then make sure the scroll bar scrolls down to it in order for people to view it. OP describes the issue well in his answer.
The things I tried are:
1. (Best way) To call processEvents() on the app object. I tried it after I saw this post and ratzian's answer.
2. Implement your custom ScrollArea,that extends QScrollArea and override the resize handler to be able to call ensureWidgetVisible on the added widget. Of course it somehow needs to know about that widget object.
3. Add a QTimer and start the timer upon adding a new widget. The method that the timer calls will need to call ensureWidgetVisible() on the new widget object and afterwards stop the timer.
I am aware that 3 is a bit hacky since it doesnt know when the resize event took place and so the timer will need to be set to a suboptimal value. (e.g resize is called in 33 ms and you set timer to 500 ms, you get the idea).
I hope this manages to help people who struggle with the same problem.
I found my problem. Not the solution.
If I drag the widget back to the first column, my code calls ensureWidgetVisible.
After that, my scrollArea resizes because of the new item. So thats why my widget isn't entirely visible.
I have a problem:
I'm creating a widget which displays current date's day number. It's like a button, but it's not derived from QPushButton class. Just from QWidget. So I've reimplemented enterEvent(), leaveEvent(), mousePressEvent(), mouseReleaseEvent(). I do call update() inside these methods and widget has realistic button behavior (paintEvent() is reimplemented also).
But when I change system date and hover that widget with other window, my widget doesn't get paintEvent() and the old date is displayed. Only when I place mouse over it, widget repaints it's contents.
I guess there is a feature (like buffering) which paints old contents on hovering with other window to avoid unnecessary recalculations. But I need to disable it. Tried to set many attributes (the Qt::WidgetAttribute enum). But it doesn't work.
I think you should find a way to detect that the system time has changed and call update() when that happens. Any other method (like detecting the "hovering" of a window or waiting for a mouse event) will cause the update to occur too late.
Is there any way to attach two Qt windows together? For example, if window A is the main window and window B is another widget I want to be able to show window B to the side of A and have both windows move together if the windows are dragged.
Not that I am aware of, but you can try following the trail of QMoveEvent. When a given widget is moved void QWidget::moveEvent ( QMoveEvent * event ) is called, and the QMoveEvent contains both old and new pos. Using this information, you can inject a move event in the other widget as well, and make it follow.
Of course, I am speaking of two independent widgets, each one in its own window. If they are contained, you don't need anything but a Layout management (see QLayout and related classes).
I don't work with Qt since a long time, so there could be a better method, but if I had to do it right now, this is the strategy I would use.
Also, I have the feeling that the QMoveEvent will be invoked only at start and end, unless you enable mouse tracking. If the former is the case, you will obtain that the other widget will "teleport" at the end of the move, instead of following smoothly.
You might be after something like this:
http://doc.qt.io/archives/4.6/qt4-mainwindow.html
Window A would be a QMainWindow and window B would be a QDockWidget.