In this post, #cgmb mentioned that :
The parent of a `QWidget` must be a `QWidget`. `QLayout` is not a `QWidget`.
Layouts exist to move and resize the children of a `QWidget`.
Though you may add child widgets by making calls on the layout, ultimately,
their parent will be the `QWidget` that the layout resides on.
For example, using findChild() like this to find a QLayout will return a nullptr:
QVBoxLayout *keyLayout = inputFieldGroupBox->findChild<QVBoxLayout*>("keyBoxLayoutCea", Qt::FindChildrenRecursively);
As such, I've been forced to use itemAt() to manually search for the layout:
QVBoxLayout *keyLayout = dynamic_cast<QVBoxLayout*>(firstHoriField->itemAt(3)->layout());
(firstHoriField is a layout in which keyLayout locates in, and inputFieldGroupBox is a QGroupBox which firstHoriField locates in)
Is there any efficient/less prone to bug method which can be used to find a layout (knowing its name), because from the code above, it could be seen that the itemAt() method is rather bruteforce-y, and if for some reason I change the indexes (for instance from 3->2), the program wouldn't run.
Related
I have been reading though a couple of examples and post but I just cannot figure out how to add a shortcut to my custom context menu. My GUI has several elements. One of them is a treeView. For the elements in my treeView I would like to have a custom context menu.
My first approach was according to this tutorial here. The context menu itself worked but the shortcuts cannot work if you create the actin within the show function.
So my second approach was according to this tutorial. But still my shortcuts do not work and if I use the context menu all actions are called twice...
Since I did not find a tutorial or code example, which matches my case, I hope that someone here can explain to me how this is correctly done in theory. Adding a shortcut to an action for a custom context menu.
Where do I have to declare my action?
What needs to be the parent of the action?
On which widget do I need to call addAction?
Thanks for any hints.
Another way is to add your action also to the parent widget (or main window widget). As mentioned in this reply, adding the same action to multiple widgets is fine and it's the way QActions are supposed to be used.
Example with custom HtmlBrowser class deriving from QTextBrowser:
Ctrl+U shortcut works for this code:
HtmlBrowser::HtmlBrowser(QWidget * parent) : QTextBrowser(parent)
{
viewSourceAct = new QAction(tr("View/hide HTML so&urce"), this);
viewSourceAct->setShortcut(tr("Ctrl+U"));
viewSourceAct->setCheckable(true);
parent->addAction(viewSourceAct);
connect(viewSourceAct, &QAction::triggered, this, &HtmlBrowser::viewSourceToggle);
}
and Ctrl+U shortcut does not work with this code (same as above, but without parent->AddAction(...)):
HtmlBrowser::HtmlBrowser(QWidget * parent) : QTextBrowser(parent)
{
viewSourceAct = new QAction(tr("View/hide HTML so&urce"), this);
viewSourceAct->setShortcut(tr("Ctrl+U"));
viewSourceAct->setCheckable(true);
connect(viewSourceAct, &QAction::triggered, this, &HtmlBrowser::viewSourceToggle);
}
Curiously, parent in this case is another widget (tab widget), not MainWindow. Still, adding parent->addAction() helps. And, unlike your suggested answer, it works even when connecting action to simple methods, without slots. Works for me in Qt 5.15.0. Not quite sure why it works, though. Perhaps, the widget the action is added to must be permanent for shortcuts to work? Looks like a bug in Qt.
Thanks to Scheff's hint I got it working. I do not now if this is really the correct way but this works for me.
The action needs to be declared in the constructor of your GUI class (e.g. MainWindow):
actionDel = new QAction(tr("delete"), this);
actionDel->setShortcut(QKeySequence(Qt::Key_Delete));
connect(actionDel, SIGNAL(triggered()), this, SLOT(actionDel_triggered()));
The triggered signal needs to be connected to a slot. Hint: if you create the slot do not use on_ACTIONNAME_triggered, this will interfere with the designer and cause a connection error.
Next add the action to a custom menu
fileContextMenu = new QMenu(this);
fileContextMenu->addAction(actionDel);
And to the widget
ui->treeView->setContextMenuPolicy(Qt::CustomContextMenu);
connect(ui->treeView, SIGNAL(customContextMenuRequested(QPoint)), this, SLOT(showDirContextMenu(QPoint)));
ui->treeView->addAction(actionDel);
All in the constructor of your GUI class.
To show the context menu use the following code in slot used in the above connect:
QModelIndex index=ui->treeView->indexAt(pos);
// Here you can modify the menu e.g. disabling certain actions
QAction* selectedItem = fileContextMenu->exec(ui->treeView->viewport()->mapToGlobal(pos));
If you do not have a slot for an action, the action can be also handled in the context menu slot, but this does not work with shortcuts!
if(selectedItem == actionOpen){
on_treeView_doubleClicked(index);
}
I am learning to create minecraft mods.
I would like to know how to make an entity teleport upwards when hit by a certain item. I have already made the item.
Override either Item#onLeftClickEntity(ItemStack, EntityPlayer, Entity) or Item#hitEntity(ItemStack, EntityLivingBase, EntityLivingBase). In that method set the target's Y position to whatever you want.
I think you might be able to use onLeftClickEntity. in the item class for your item, make a
onLeftClickEntity method. inside that method, it should be as simple as using motionY. untested though, and for 1.12.2.
I am trying to teach myself design patterns. I was reading about the Decorator pattern, and there's one thing that I can't quite get. Here is an example found on wikipedia:
Let's say I want to implement a window that can scroll both horizontally and vertically, I would do this:
Window win=new Window();
win=new HorizontalScrollBarDecorator(win);
win=new VerticalScrollBarDecorator(win);
Since win is a reference of type Window, I can call neither drawHorizontalScrollBar() nor drawVerticalScrollBar() (apart from the code in the concrete decorator itself), and of course it would not make sense to change the reference type.
So, how can I "add new behaviour" (I.E. implement new methods) with decoration?
Nevermind, I think I got it:
Through decoration you can't "add new behaviour" as I had interpreted it (drawHorizontalScrollBar() is not visible from outside the HorizontalScrollBarDecorator class, which means it's probably called by its draw() method), BUT you can extend methods of the base class.
It's like extending the base class, overriding the draw() method and then calling super.draw();, with the difference that you can apply multiple decorators, but you can't inherit from multiple classes.
What's the fastest way to render dijit widgets?
I know that the programmatic way is faster than the declarative. (Some reference)
I have a custom widget that loads too slowly (it's a datagrid with combobox, buttons and other small dijit widgets used for adding filters, etc).
Looking at the source, I see that all the dijit widgets are created programmatically, but the DOM nodes where they are inserted into are created programmatically as well.
Is it the "right" way?
I'm trying to speed up the rendering of this widget, and currently my choice would be to combine a velocity template (my company uses struts2 + velocity) to create the DOM nodes, with programmatically created widgets (using placeAt and similar methods to insert the widgets into the already built DOM nodes).
It would work fine, but sadly all the css classes are overwritten by dijit, so I have to overwrite them again, which causes a sensible overhead.
In the template I write something like this:
<input id="idOfAnExistingDomNode" class="myCssClass" />
And to insert a FilteringSelect in that DOM node I have to write this:
var fieldSelect = new dijit.form.FilteringSelect({
store : jsonStore,
searchAttr : "caption",
labelAttr : "caption",
selectOnClick : true,
value : "Content"
}, "idOfAnExistingDomNode");
fieldSelect.domNode.className += " myCssClass";
The last line is necessary because myCssClass is overwritten during the creation of the FilteringSelect.
Is there any way to avoid this issue?
Or, perhaps, I'm trying to do this thing the wrong way? I'm not completely sure about that "velocity template" thing.
Note: Dojo version is 1.5 and no, sadly we can't upgrade it to newer versions.
Please forgive me for my TERRIBLE English.
Often one of the faster ways to instantiate widgets is to create them in a temporary div and then move that div onto the DOM. Have you tried profiling what exactly is slow in this instantiation? Part of me wonders if too much time is being spent waiting for data, as a few widgets + a grid with reasonable pagesize params shouldn't take long to load.
As for your class issue, it is strange that dojo is not mixing in the existing class. That said, you could do a lookup on the node first, get the class attribute, and then specify it as
the class attribute in your mixin object when creating the FilteringSelect. If you do so, be sure you wrap class in quotes or older IE's will reject it.
I have a QGraphicsLinearLayout with a series of QGraphicsWidgets within. I can hide the widgets just fine, but the layout spaces out all of the remaining widgets as if the hidden ones are still visible. How can I get the layout to use this space?
My code is something like this:
//scene is a QGraphicsScene*, myWidget# inherits QGraphicsWidget
scene->addItem(myWidget1);
layout->addItem(myWidget1);
scene->addItem(myWidget2);
layout->addItem(myWidget2)
scene->addItem(myWidget3);
layout->addItem(myWidget3)
//then later, I call
myWidget2->hide();
But although myWidget2 is now invisible, the layout is still spaced as though it were there. How can I change that?
Thanks.
Try calling QGraphicsLinearLayout::invalidate() to clear any cached geometry information after hiding the widget. If that doesn't help I would assume that removing the widget from the layout (if that is feasible for you) should do it.
I think you are loking for QWidget::findChild<T>(Qstring name)
name - an object name which can be set with QObject::setObjectName(Qstring name)
T - is a type of an object you are loking for.
so in your case code should look like:
MyWidget* myWidget1 = new MyWidget(this);
myWidget1->setObjectName("myWidget1");
........
MyWidget* requiredWidget=scene->findChild<MyWidget*>("myWidget1");