In PyQt, I have a dialog that spawns another dialog (when you click a button to do so in the first dialog). I want to maintain a strong parent-child relationship, for garbage collection purposes, and to make the .findChild and .findChildren functions usable.
The root of the question may be: how do you use .setParent() but still have the object in question be shown as a separate window, rather than shown within the parent widget?
The 'parent' dialog (actually a container widget within a tab within a dialog) is 'newEntryWidget'. It spawns 'clueDialog' when a signal (not shown here) calls newEntryWidget.quickTextClueAction as a slot. Visually, clueDialog should be a "top level window" with its own banner, its own window attributes (I want to keep it on top of everything else), etc.
class newEntryWidget(QWidget,Ui_newEntryWidget):
def __init__(self,parent,sec=0,formattedLocString='',fleet='',dev='',origLocString='',amendFlag=False,amendRow=None):
QDialog.__init__(self)
self.parent=parent # just an attribute; not the same as setParent
...
...
def quickTextClueAction(self):
self.newClueDialog=clueDialog(self,self.ui.timeField.text(),self.ui.teamField.text(),self.ui.radioLocField.text(),lastClueNumber+1)
self.newClueDialog.show()
class clueDialog(QDialog,Ui_clueDialog):
def __init__(self,parent,t,callsign,radioLoc,newClueNumber):
QDialog.__init__(self)
self.parent=parent # just an attribute; not the same as setParent
...
...
Right now, since I am using self.parent=parent, which is just an attribute and not true "parent/child relationship" in Qt terms, clueDialog does display as a top level window, which is what I want:
But, if I add 'self.setParent(parent)' in the clueDialog init function, I get this:
How can I preserve the top-level-window behavior, and have the real-honest-parent-child-relationship so that .findChild(clueDialog) will work from within the newEntryWidget object?
Ultimately, I want to enforce that the newEntryWidget object should not be closed if it still has and 'child' clueDialogs open.
Instead of calling .setParent, call QDialog.__init__(self, parent) which constructs the clue dialog with a parent from the beginning. Setting it this way allows Qt establishes the parent-child relationship at the beginning of clueDialog's lifetime.
I believe this will fix both your issues: 1) the clue window frame, caption, etc. will be painted, 2) you will be able to iterate for proper children of newEntry.
Related
I inherited from QGraphicsItemGroup and made a class that keeps a pointer to its contained items so that I can later refer to them and change properties. It has an ellipse item and a line item and I want only the ellipse to be clickable. I need that press event of the ellipse to propagate to the QGraphicsView so that I can send a signal to some surrounding widgets.
So far I tried inheriting also from QGraphicsObject to have signals available but got stuck with ambigous base error when trying to use scene->addItem. I tried casting to QGraphicsItemGroup but I still get the error. I also tried inheriting from QObject with no success.
I'm new to QGraphics and I know the QGraphics framework has a lot of tools for user interaction and even interaction between GraphicsItems but this is really kicking my butt.
What would be the proper way to get this behavior?
Create a separate "emitter" class
To allow your subclass of QGraphicsItemGroup to emit signals, you can create a separate "emitter" class that inherits from QObject. Then, you can add an instance of this emitter class within your subclass of QGraphicsItemGroup. The emitter object can then emit signals for your subclass as needed.
QGraphicsItemGroup is treated as a single item
Unfortunately, an instance of QGraphicsItemGroup is treated as a single item, so each mousePressEvent will belong to the entire group rather than one of the members of that group (i.e., the ellipse item or the line item). If you want the mousePressEvent to behave differently depending on which item is clicked, they will need to be separate items, or you could try using line->setParentItem(ellipse) to link up the 2 items without using QGraphicsItemGroup.
Recently I would like to bring a dialog in front of it's father window(always do, no matter its father window gets focus or not) but not topmost. In other words, I only want it cover its father window but not other applications' window.
I've tried:
// this covers other windows
SetWindowPos(&wndTopMost, rectPos.left, rectPos.top, width, height, SWP_SHOWWINDOW);
// this doesn't work
SetWindowPos(&GetParentFrame()->wndTop, rectPos.left, rectPos.top, width, height, SWP_SHOWWINDOW);
Any ideas?
Xiangguan Zheng, in your original post you stated:
I only want it cover its father window but not other applications' window.
Later in your comment you mentioned:
I want do edit the father dialog by clicking the buttons on the child dialog.
These are two completely different requirements.
If you want a second dialog to be contained in the parent dialog area, you can achieve this by setting WS_CHILD style to the second dialog and calling Create. this will show the child dialog over the top of the parent and keep it within the parent area.
to fulfill the second requirement, you will have to pass the pointer to the parent dialog as the second parameter in Create call, or pass it when the child dialog is instantiated. Either way, you will have to save that pointer in the child dialog and use it to either call the public function exposed by the parent or use the pointer to send/post messaged to the parent.
I am designing a interface with QtDesigner and editing its functionalities with PyQt. One of the widgets that i created has several pushButtons and i want them all to have the property Checkable = True.
So currently what i am doing is:
class MyWidget(QWidget):
def __init__(self):
super(MyWidget, self).__init__()
uic.loadUi('./my_widget.ui', self)
self.pushButton_X.setCheckable(True)
self.pushButton_Y.setCheckable(True)
self.pushButton_Z.setCheckable(True)
self.pushButton_ETC.setCheckable(True)
self.show()
Is there any way i can do something like:
pushbuttons_list = self.get_all_pushbuttons()
for i in pushbuttons_list:
i.setCheckable(True)
?
Im trying the answers to this question but i keep getting
> File "./testing_class.py", line 12, in __init__
items = (self.layout.itemAt(i) for i in range(self.layout.count()))
AttributeError: 'builtin_function_or_method' object has no attribute 'count'
Your example failed because all Qt properties can be accessed by calling the attribute (see the parentheses used for self.layout()):
items = (self.layout().itemAt(i) for i in range(self.layout().count()))
Note that this will only get access to the layout items, not the widgets they might (or might not) contain. For this, using comprehensions will only complicate things unnecessarily, as one-liners should be used only as long as they keep the code readable; the comprehension above is already complex enough, and since you will need to cycle through all items anyway, there's little use in it. Just use a for loop, which is far more readable:
for i in range(self.layout().count()):
widget = self.layout().itemAt(i).widget()
if isinstance(widget, QPushButton):
widget.setCheckable(True)
Note that if you have several buttons that you want checkable and you are doing this only to avoid manually setting the checkable property for all of them, you can just use the extended selection mode that is common for all UI elements that allow selection by keeping pressed Ctrl when clicking multiple objects.
The property editor will automatically show all common properties for the selected widgets, and apply the changed property to all of them.
Another option is to use findChildren():
for button in self.findChildren(QPushButton, Qt.FindDirectChildrenOnly):
button.setCheckable(True)
The Qt.FindDirectChildrenOnly flag is required whenever you have complex layouts that have nested widgets containing other buttons, if you remove that you will find any push button that exists inside the window (or the widget referenced as self).
Finally, buttons can be part of a QButtonGroup, which can also be created in Designer. Just select all buttons (as explained above), right click on one of them and select "Assign to button group", and then:
for button in self.buttonGroup.buttons():
button.setCheckable(True)
Note that the self.buttonGroup above is the object name assigned by Designer, if you change it or you create more than one, ensure that the reference matches it.
I have a GUI based in Python 3 and tkinter that has a big ttk.Treeview. I have defined methods for row selection (one click) and opening an advanced info panel (double-click). I need to ensure that, after being double-clicked, for the next one or two seconds, the Treeview state won't be changed by another click. Is it possible to deactivate Treeview mouse bindings, like what we do with buttons?
Doing a little more research, I was able to come up with a solution for this. I just created an empty method that is called when the tree widget is supposed to be inactive. So, we can use something like this to "unbind" all the mouse events and re-bind them a few seconds later, as needed:
def nothing(self, *event):
""" # Hacking moment: A function that does nothing, for those times you need it...
"""
pass
def bind_tree(self):
""" # Bind mouse and keyboard events to their respective functions or methods...
"""
self.tree.bind('<<TreeviewSelect>>', self.selectItem_popup)
self.tree.bind('<Double-1>', self.show_details)
self.tree.bind("<Button-2>", self.popupMenu)
self.tree.bind("<Button-3>", self.popupMenu)
def unbind_tree(self):
""" # Unbind all mouse and keyboard events, by binding them to an empty method...
"""
self.tree.bind('<<TreeviewSelect>>', self.nothing)
self.tree.bind('<Double-1>', self.nothing)
self.tree.bind("<Button-2>", self.nothing)
self.tree.bind("<Button-3>", self.nothing)
Then, in the rest of the code, We only need to call bind_tree() and unbind_tree() as needed.
This worked for me:
tree.bind("<ButtonRelease-1>", my_select_function)
# Do some stuff
tree.unbind("<ButtonRelease-1>")
I am attempting to write my first program using Qt5. I found a tutorial (zetcode.com/gui/qt5) with a number of examples, which all used dynamic layout creation. I'm trying to create a nested layout configuration, but I'm having a problem with specifying the parent parameter of the layout constructor. When I use the main window as the parent for the main layout and its sub-layouts, I get an error message, apparently telling me that QWidget can have only one QLayout. The window looks OK, but I haven't implemented all my functionality yet (slots and other code), so I don't know what, if anything, is broken. If I omit the parent parameter from the sub-layouts, I get no error messages and the window looks OK as well, but again I'm wondering whether this would affect my subsequent code additions.
Can anyone explain to me the significance of a layout's parent? I've noted that specification of the parent window in the layout's constructor is apparently not sufficient, because all of the examples I've seen call setLayout() at the end of the window's constructor. In particular, will my omission of a parent ever cause problems?
The "rules" are that there can be at most one top level layout on a given widget, and that widgets can be only children of other widgets, not of layouts. So what happens is that:
when you set a layout on a widget, the widget will take ownership of that layout;
when you add widgets on a layout, these widgets will be reparented to the widget the layout is/gets installed upon;
when you add a layout inside another layout, the inner layout becomes a child of the outer layout.
What you're probably seeing is a side-effect of creating a layout with a widget as parent, as in
QLayout *layout = new SomeLayout(widget);
This will try to install the layout on widget, and fail in case there's already one. The good news is, you can pretty much ignore passing parents around and rely on the system to do "the right thing". For instance:
MyWidget::MyWidget(QWidget *parent)
: QWidget(parent)
{
QHBoxLayout *mainLayout = new QHBoxLayout; // top level layout
QVBoxLayout *subLayout1 = new QVBoxLayout; // sub layout 1 stuff
QPushButton *button = new QPushButton("button");
subLayout1->addWidget(button);
// create more widgets...
mainLayout->addLayout(subLayout1);
QVBoxLayout *subLayout2 = new QVBoxLayout; // sub layout 2 stuff
QLineEdit *edit = new QLineEdit;
subLayout2->addWidget(edit);
mainLayout->addLayout(subLayout2);
setLayout(mainLayout);
}
This will correctly create a layout hierarchy and a parent/child relation so that nothing will get leaked.