I am trying to implement a series of layered widgets in Qt but having trouble with clicking "through" a top-level widget to one that is below
I have a standard main window that has a centralwidget, within this centralwidget I have a "button overlay" widget which contains a series of buttons around the side of the screen. The central widget then also contains a "display" widget within which I have a number of other widgets (In effect a way to display a center view with a series of buttons around the side)
However, I can only click on the buttons within the overlay, any buttons within the view don't receive the mouse click. I am assuming this is because although you can see the buttons in the layer below, it's the widget at the top layer that receives the mouse clicks which seems to be true as if I raise() the view to the top, the buttons can receive clicks
So, I there a way to click buttons through another widget or is my entire approach wrong?
Related
I want to create a QDialog with Qt that looks somewhat like this:
The desired properties here are:
I can add a text to the dialog explaining the question behind it
I can add several buttons that are in a vertical layout
I can retrieve the value of the clicked button, i.e. I know if the user cancelled or clicked 1, 2 or 3 - ideally I can emit a signal with the corresponding value as parameter.
The dialog has a certain minimum height and width.
I have used a QMessageBox before for this purpose, but I can't get it to use a vertical layout. I have experimented with a QDialogButtonBox and a QDialog, but I can't really figure out how to get my desired return value easily.
A piece of code creating this dialog with code how to retrieve the clicked value would be great!
Did you try a QDialog widget? you can add QDialog without buttons to your project. In UI designer, add Vertical layout, label, and buttons.
In your class define your signals and emit it when the user clicked on buttons.
I am programming in C++ in QT and trying to make a UI with dynamic tabs having tables inside each of them. For doing the same, I had my TabWidget in the main window, and another widget with just the tableView. As the tabs are dynamically being added to the main window by a button click, I make a new object of my widget and put it in that.
I also have another version of the application in which there are no tabs, just a tableView in the main window.
I am unable to open the context menu in the former case, while it works perfectly for the latter.
I am using the signal "customContextMenuRequested" in both the cases. Don't understand what I need to add for it to work when the tableView is in a child widget.
Some help please?
Thanks already!
Did you check that nothing is involving QAbstractScrollArea, it's possible that in this case it would signal/slot as expected.
This signal is emitted when the widget's contextMenuPolicy is Qt::CustomContextMenu, and the user has requested a context menu on the widget. The position pos is the position of the context menu event that the widget receives. Normally this is in widget coordinates. The exception to this rule is QAbstractScrollArea and its subclasses that map the context menu event to coordinates of the viewport() .
I am working on a Touchscreen application.
For this I Need to Change the current window if user clicks on the Screen (Position doesn't matter).
For this I Need a to make my button (which is currently the same size as the current window) invisble, so user can see the Labels etc.
Any idea how to make Buttons invisible in PyQt4?
I recommend you not use a button to do this. Instead, either put an event filter on the QApplication instance, so any widgets in your window get events only if you determine they should; OR put a transparent panel widget over the touch area, with a mouse click event handler for that panel. Either method supports arbitrary complexity of widgets inside your touch area (labels and tables to display information etc). Main disadvantage with event filter approach is that all application events (from all threads) will be filtered. This could affect performance (you'd have to test, may not be any noticeable differenc), but it is simpler to implement than the transparent panel.
I would like to build an embedded Qt application. This application shall have a couple of windows which are invoked by button click. I don't know if I understood the concept of using qmainwindow in the right way:
Do I create one QMainWindow class and each other window that should be displayed is a widget placed as central widget or is any new window I call a new QMainWindow?
I do not use qmainwindow's tool, menu or status bar just the dock widgets which surround the central widget, like a header on top and a button bar at the bottom or a widget to the reight like a keyboard. Since the header's label stays the same (only the title and the icon changes) and the bottom bar always holds some button (which should call another central widget or return to the previous one), changing the central widget should be sufficient right?
Have a look at QT Layouts
http://qt-project.org/doc/qt-5.1/qtwidgets/layout.html
Remember you can nest layouts, so you probbaly want a VBoxLayout, and the second entry in that layout will be a HBoxLayout.
I have a Qt application in which certain QLabel's display a tooltip if a certain internal condition occurs.
Since the tooltip has a timeout and is hidden by Qt automatically, the tooltip is kept alive by the application by showing the tooltip every 3 seconds (I did not find any mechanism to tell Qt to show a tooltip indefinitely).
The tooltip is displayed until the user clicks on the QLabel itself: the tooltip is not refreshed any more and disappears.
I now have a new requirement that the tooltip should also disappear if the user clicks on the tooltip itself. Is there a signal that is sent when the user clicks on a visible tooltip? Or is it necessary to use some more sophisticated technique?
EDIT
I have checked my code again, here is some extra information.
Qt does detect a mouse click on a tooltip and hides it, but the application immediately shows the tooltip again.
What I would like to do is that Qt informs my code of the mouse-clicked event, so that it stops showing the tooltip again and again. I have two possible solutions in mind, but I do not know if either of them is technically feasible:
Remove tooltip timeout: when a tooltip is shown, it remains visible as long as the user does not click on it. How can I display a tooltip without a timeout in Qt?
Keep the tooltip visible by repeatedly showing it; detect a mouse clicked on the tooltip in order to stop the keep-alive loop. How do I receive a signal when the user clicks on a tooltip?
Under the hood, the actual class that implements the tooltip is a private QLabel-derived class called QTipLabel:
http://qt.gitorious.org/qt/qt/blobs/4.7/src/gui/kernel/qtooltip.cpp#line119
There's nothing published in the interface to get at an instance of that class from QToolTip, so intercepting clicks would only be done with some sort of ill-advised hack.
That said: among the events that should "hideTipImmediately" is QEvent::mouseButtonPress...in fact, there's an event filter installed so that any click in the app will hide it:
http://qt.gitorious.org/qt/qt/blobs/4.7/src/gui/kernel/qtooltip.cpp#line325
So if you're not seeing the tooltip disappear when it's being clicked on, there's a bug. (Clicking on tooltips hides them for me in Qt-based apps under Kubuntu.)
Note the definition of QToolTip::showText:
void QToolTip::showText ( const QPoint & pos, const QString & text,
QWidget * w, const QRect & rect ) [static] Shows text as a tool tip,
with the global position pos as the point of interest. The tool tip
will be shown with a platform specific offset from this point of
interest.
If you specify a non-empty rect the tip will be hidden as soon as you
move your cursor out of this area.
The rect is in the coordinates of the widget you specify with w. If
the rect is not empty you must specify a widget. Otherwise this
argument can be 0 but it is used to determine the appropriate screen
on multi-head systems.
If text is empty the tool tip is hidden. If the text is the same as
the currently shown tooltip, the tip will not move. You can force
moving by first hiding the tip with an empty text, and then showing
the new tip at the new position.
Thus, you can supply the rectangle in which the QToolTip is to be presented. Then, if what you want to do is close the QToolTip only when the user clicks on it, you can capture mouseButtonPress events as #HostileFork pointed out and then close the tooltip only when the coordinates of the event fall within it.