I'm using the Qt library to show a slideshow on the second monitor when the user isn't using the second monitor. An example is the user playing a game in the first monitor and showing the slideshow in the second monitor.
The problem is that when I open a new window in Qt, it automatically steals the focus from the previous application. Is there any way to prevent this from happening?
It took me a while to find it but I found it: setAttribute(Qt::WA_ShowWithoutActivating);
This forces the window not to activate. Even with the Qt::WindowStaysOnTopHint flag
If you want to make floating preview box/ any other widget just use below
thumbnail = new QLabel;
thumbnail->setAttribute(Qt::WA_ShowWithoutActivating);
thumbnail->setParent(0);
thumbnail->setWindowFlags(Qt::Tool | Qt::FramelessWindowHint|Qt::WindowStaysOnTopHint);
Qt::Tool is important flag to make it work. I mean not stealing focus.
Widgets don't accept focus by default but presumably you haven't created a plain widget? Which subclass was it? QMainWindow or something else?
It's possible the window subclasses default to accepting focus so try explicitly calling QWidget::setFocusPolicy with Qt::NoFocus before calling QWidget::show().
Also, make sure you're not calling QWidget::activateWindow() on the window or any of its widgets at any point.
Related
While answering a different StackOverflow question I realized that a 100% correct solution would need to know when the Qt application's window was being dragged or resized by the user's mouse, so that it would refrain from moving or resizing itself during that period, and thereby avoid "fighting with the user" for control of the window.
However, I don't know of any mechanism for a Qt app to be notified when the user pressed down the left-mouse button on the window's title bar, or when the user releases the left-mouse button afterwards... I assume that is because that functionality is handled by the OS's window-manager rather than by the Qt library. That said, is there any secret way to do it? Cross-platform would be best, but OS-specific solution are also of interest.
I am trying to make a dialog box like below in QT, the only problem is I have no idea what the widget is called. The bar on the left is like a tree-view widget, but when you click on it, it updates the text on the right. Does anybody happen to know what the widget is called or what widget(s) are required to perform this? I am using QT C++ on Windows.
There is an example with Qt showing you how to do this.
https://doc-snapshots.qt.io/4.8/dialogs-configdialog.html
If you're using Qt Creator as IDE, you can find it under the "Demos and Examples" tab in the Welcome Screen too.
It uses a QListWidget for the selector, and QStackedWidget to control the different pages. Connect the currentItemChanged signal of the list widget to change what page should be shown. Everything you'll need is in configdialog.cpp.
If you realy need to add QPushButton into QListWidget, use setItemWidget, or into ListView use QAbstractItemView::setIndexWidget
I'm using Qt 4.7 on Windows 7 Ultimate 32 bit.
The QMainWindow of my program has a QDockWidget. I've noticed that if I minimize the main window by the minimize button on the title bar, after restoring it the dock widget is closed. I didn't write any support for a feature like this!
How does this happen and how to prevent this?
Thanks.
I encountered this error when writing my own application. I have QDockWidget with options for my application. Using Qt Creator I created menu with QAction actionMenu which was checkable. Then I connected QDockWidget and QAction like this:
QObject::connect(ui->dockWidget, SIGNAL(visibilityChanged(bool)),
ui->actionMenu, SLOT(setChecked(bool)));
QObject::connect(ui->actionMenu, SIGNAL(toggled(bool)),
ui->dockWidget, SLOT(setVisible(bool)));
The order of connection is not important. And then when I minimized application with QDockWidget being visible, after I restored it QDockWidget was closed and actionMenu was unchecked.
In fact there are two solutions. First which works for me is to use SIGNAL(triggered(bool)) instead of SIGNAL(toggled(bool)):
QObject::connect(ui->dockWidget, SIGNAL(visibilityChanged(bool)),
ui->actionMenu, SLOT(setChecked(bool)));
QObject::connect(ui->actionMenu, SIGNAL(triggered(bool)),
ui->dockWidget, SLOT(setVisible(bool)));
The second solution uses action which you can obtain from QDockWidget:
// Retrieve action from QDockWidget.
QAction *action = ui->dockWidget->toggleViewAction();
// Adjust any parameter you want.
action->setText(QString("&Menu"));
action->setShortcut(QKeySequence(Qt::CTRL + Qt::Key_M));
action->setStatusTip(QString("Press to show/hide menu widget."));
action->setChecked(true);
// Install action in the menu.
ui->menuOptions->addAction(action);
I know for sure that SIGNAL(toggled(bool)) was causing in my application closure of QDockWidget.
I faced the same problem... I managed to get rid of it by using a method called StoreWindowsLayout and RestoreWindowsLayout.
StoreWindowsLayout will save the content of the ByteArray returned by the Method QMainwindow::saveState().
RestoreWindowsLayout will restore that bytearray, and therefore your windows layout, the qdockwidget visibility state and so on...
I call StoreWindowsLayout on ApplicationMainFrm::changeEvent, on ApplicationMainFrm::closeEvent (it's likely this one you'll need) and in ApplicationMainFrm::hide().
Then I use restoreWindowsLayout in ApplicationMainFrm::showEvent.
Exemple of use of restoreWindowsLayout in my MainForm :
void ApplicationMainFrm::showEvent(QShowEvent* pEvent)
{
QMainWindow::showEvent(pEvent);
restoreWindowsLayout();
}
Hope it helps !
I'm trying to set something up so my main dialog has one or more child dialogs, and these are glued/docked to the outside of the main dialog - when the main dialog is minimised, the children are too, when main dialog moves, children move with it.
I'd tried setting child dialogs as having main dialog CWnd as parent, with CHILD style. But then they get clipped by the parent's boundary. If I set them as POPUP, they can be outside but then don't move with the parent.
I'm looking at putting an OnMove handler on the parent dialog, but is there something built-in? And, should child dialogs still be children of the main dialog... I assume they should?
This is VS2005 (I think VS2008 has some related functionality so I mention this).
You need to implement the movement manually when they are popups, and yes they should be popups otherwise they will be clipped out.
I'm new to SO. Not sure if I can refer to an external article.
I guess this is what you are looking for.
I started to write this class because
I'm often in need to popup additional
dialogs around the main one. Often
these dialogs can give some trouble to
the user; for example, he must
move/close them one by one... A
solution that could give the
application a more solid aspect and
that could make the management of the
various windows easier could be, to
dock all dialogs side by side (like
Winamp does, for example).
As Roel says, your extra dialogs will need to be popups. I'm interested: what kind of UI is this? Is it WinAmp-style, where the windows snap to eachother?
Or are you doing some kind of expanding dialog? If it's an expanding dialog (with a More>> button on it, e.g.), then you can put all of the controls on the same dialog and play with the window rect when showing/hiding the extras.
I've run into an issue using a wxDialog object on Linux In the construtor for the object I pass the relevant style flags (wxCAPTION|wxMINIMIZE_BOX|wxMAXIMIZE_BOX|wxCLOSE_BOX|wx_RESIZE_BORDER) but the buttons don't show up. When I was designing the class in wxformbuilder they would appear on the displayed design but don't show up in my running application.
I'm using wxWidgets 2.8.7 at the moment and running on Scientific Linux 5 (RHEL 5). Any suggestions or ideas on how to work around this?
EDIT: BTW, This is related to this question
If you create a dialog on wxGTK then during construction
gtk_window_set_type_hint(GTK_WINDOW(m_widget), GDK_WINDOW_TYPE_HINT_DIALOG);
is called, which leaves it up to the window manager what decoration is shown for this window. So if you give it the style but no buttons are shown, then there's nothing you can do. In any case, I think showing a wxFrame while the parent frame is disabled should work just as well.
Can you use a wxWindow instead of a wxDialog? Maybe it doesn't make sense to minimize a dialog but those are usual operations for application windows.