A little desperate as no advice works... Paint Problems and method strangeness
-
I have a feeling something is out of whack here so I'll try to break my question into smaller parts. Here's #1:
I have a class B that derives from a "MyWidget" class, which is derived from QWidget.
Class B has a "setupUI" generated for it by QT-Designer. It's an elaborate dialog.
Class "MyWidget" implementsd some functionalities that are shared between all children such as class B, like Draggability (no caption).I would like class "MyWidget" to add some graphical widgets that'll draw ON TOP of what the child classes draw. I just can't that to occur. I overriden paintEvent, event (looking for paintEvent and drawing). Breakpoint is reached there, but nothing happens.
I think something more elemental is wrong. therefore my goal now is to SABOTAGE the code of class B such that it doesn't draw.
I tried overriding the virtual protected paintEvent in B, doing "nothing", but the damn dialog still draws itself beautifully. Why is that? It seems like drawing is done outside of the scope of my overriden methods.
My question is simple. What should I override in class B to STOP DRAWING IN ITS TRACKS?
-
Hi,
if you overwrite paintEvent in B and do nothing, you will never reach MyWidgets paint event. It's a virtual function, call the base class in B::paintEvent:
@
B::paintEvent(QPaintEvent* p)
{
MyWidget::paintEvent(p);
}
@But the child widgets, ctreated in the designer will always be painted (and be on top of the widget)
-
A clear problem statement is atleast 10% of the solution:)
-
I think, what you want is not possible.
ther are two things in the game:1.) parent child relations
2.) base class / derived class stuff.
For point 1, you have no influence without adding eventFilters. This iteration is done by the paint engin in the background, which updates the double buffer
For point 2 you have no chnace. the pmethod paintEvent is called by QWidget::event(...). If you override this, you can catch it, but...
This method calls a virtual method, which always reachesd the most derived class (in your case B).Which of the 2 cases relate to your problem?
-
My goal:
A single parent widget class in my application all dialogs (window widgets) derive from. Its descendant classes will implement their own drawing and functionality, but based on some kind of status in the application, the parent widget must be able to draw "something" (be it an overlaying image, lines, anything) on top of what the child class is drawing, without having to involve the cooperation of the child widget class.
PS: All child windows are based on a *.ui resource created with QT-Designer.
-
Would it be acceptable if you base widget would use another widget to do that?
I mean, your base widget could, if it needs to go into that state, create a child widget (overlay widget), and use QWidget::raise() to make it lay on top of any of its child widgets and because of the parent-child relationship, on top the parent itself too. You can put anything you want on top of that overlay widget.