ResizeEvent propagation to children issue

Black Imp

I use a QMdiSubWidow to which I add a QCustomPlot. I derive QMdiSubWindow and override resizeEvent() as I want to modify my plot appearance depending on its height.

void MySubWindow::resizeEvent(QResizeEvent * resizeEvent)
{
QMdiSubWindow ::resizeEvent(resizeEvent);
qDebug() << FUNCTION << " plot size " << mPlot->size();
qDebug() << FUNCTION << " rect " << this->rect();
mPlot->replot();
}

Everytme I resize by mouse subwindow , I can read mPlot size has changed accordingly.

When I maximize subwindow by its button, mPlot size, in this function, is still the old one so it's not been updated at this point.

When I restore subwindow size by its button, mPlot size is now what should have been when subwindow was maximized - it means has still not been updated -.

If I resize by mouse subwindow, mPlot size is reported correctly again.

At some point the correct size is applied as I can see my plot fitting subwindow the way it should but not being able to get updated plot size inside resizeEvent() function prevents me from applying the needed modifies over my plot - for instance changing tick counter - when subwindow is maximized or restored.

Isn't it a qt bug? If not, how can I handle correctly size changes?

Thank you

SGaist

Hi,

Can you provide a minimal compilable example that shows that behavior ?

Black Imp

@SGaist
thank you for your reply: unfortunately no: it's extracted from a private application I'm developing for my company.
It would take me a day.
But if you simply build an application with QMdiArea and QMdiSubWindow, put any QWidget child inside subwindow layout and override that function, you'll be able to see that behaviour.

SGaist

That's the kind of example I was asking for, not a stripped down version of your application.

This will allow other to check your issue the same way as you have it.

Black Imp

What I feel totally frustrating about Qt is it presents inconsistencies and irrational mechanisms which other framworks don't present and when you have some important question about them no one seems able to answer. I'm using them just because I inherited the project I'm developing and that decision was already made but I'd never advise anyone to adopt them if they can go with native frameworks.
I find absurd no one still has answered: it's a very simple question if you have developed qt framework, you know how resize event is propagated when user resizes window AND when they simply maximize it. It's absurd I can't rely on this event when I develope my project.

Christian Ehrlicher

@Black-Imp said in ResizeEvent propagation to children issue:

when you have some important question about them no one seems able to answer.

This depends on your question and how you ask - you were asked to provide a simple, minimal example so we can try to reproduce the issue. But instead trying to create a reproducer you're just complaining about that noone wants to help you... that's stupid.

Black Imp

@Christian-Ehrlicher do you think i have to write here 4 classes for a CLEAR problem which should have an EASY answer from any qt developer?
don't know about you but I have a job. I can't spend 1 or 2 hour to create a dummy project with obvious code in order to have a simple answer to a simple question: how does resize event propagate. are you a qt developer? well check it!
pick qmdisubwindow class, or its ancestor and check if resize event is propagated consistently - in a correct order - when user resizes and when user maximizes subwindow to its children. it's very straighrforward.
I found other inconsitencies but I don't even think to put a question here for not wasting time. this aspects are conceptual and based on qt developers code which I can't see so if question is clear it's pretty useless writing code.

Christian Ehrlicher

Yes you should write this code to see if your problem can be reproduced or if there is something other which triggers your issue.
And yes you have to do this for every lib you want support for and even more if you pay for this support - I even don't need to write a bug report for a library we use when there is no simple, reproducible example attached so it can be reproduced by their developers.
So please stop crying around here and either provide a testcase or stay still.

jsulm

@Black-Imp said in ResizeEvent propagation to children issue:

if you have developed qt framework

I think you misunderstand here something: this is a forum for people USING Qt framework not for developers who develop Qt. If you want to ask Qt developers you need to go to the mailing list. And I find the way you complain here quite disrespectful - people in this forum are volunteers and are not paid for their help and are not obliged to answer your questions. If somebody knows the answer he/she will provide it. But, yeah, you don't even want to provide a sample application which shows the behaviour, so why should anybody be motivated to help you?

J.Hilk

@Black-Imp I agree with the others a but friendlyness gets you a long way.

Never the less I would suggest overwriting changeEvent(QEvent *event)

The resizeEvent will be in there as well and more importantly the QWindowStateChangedEvent as well.
That is triggered when you minimize and maximize your window.

I noticed some inconsistencies with the QResizeEvent in those edge cases as well. Mostly on windows iirc.

void changeEvent(QEvent *event)
{
    if(event->type() == QEvent::WindowStateChange){
          doStuff();
    } else if(event->type() == QEvent::Resize {
         doStuff();
   }

    event->ignore();
}

PabloArg

Hi J. Hilk,

It is definitely a problem with QMDIarea when the parent resizes and his children visually change, but in the size property it still keeps the old size.
I tried my form outside the QMDI and it works perfectly when the parent resizes, his children do the same.

I repeat, thank you very much. I had already gone mad.