Results 1 to 13 of 13

Thread: QStatusBar wrong adjustSize()? When is it calculated?

  1. #1
    Join Date
    Aug 2020
    Posts
    13
    Thanks
    3
    Qt products
    Qt5
    Platforms
    Windows

    Default QStatusBar wrong adjustSize()? When is it calculated?

    Edit: forgot to add - I am using Qt 5.15 under Windows 10 MSYS2 MinGW

    I am trying to toggle a QStatusBar in my QMainWindow and resize the main window content accordingly. The content has a QLabel with a QPixmap inside a QScrollArea that may or may not be larger than the window, so I calculate the window size manually after each change to the pixmap. In order for the status bar to not overlap the pixmap when it should not be larger than the window, I need to get the status bar size on it's creation so that my resize function can access it. However I cannot figure out how to get the correct size. My status bar toggle looks like this

    Qt Code:
    1. void toggle_status_bar() { // member of QMainWindow subclass
    2. if (m_status_bar)
    3. m_status_bar = nullptr;
    4. else {
    5. m_status_bar = new QStatusBar { this };
    6. m_status_bar->showMessage("some status message");
    7. m_status_bar->adjustSize(); // * this gives the wrong size ...
    8. }
    9. setStatusBar(m_status_bar);
    10. }
    To copy to clipboard, switch view to plain text mode 

    But here the marked line (// *) calculates the wrong size: it resizes the status bar to height 18. Then my resize function, which is essentially
    Qt Code:
    1. void resize_content() { // member of QMainWindow subclass
    2. // calculate new_size ...
    3. resize(new_size);
    4. }
    To copy to clipboard, switch view to plain text mode 
    , makes scrollbars appear for the pixmap. If I now request another resize while the program is running, i.e. calling resize_content again, the status bar is resized to height 20 and the scrollbar disappears like it should.
    I tried different things at the end of toggle_status_bar(), all of which calculate the wrong height 18:
    • Call resize_content()
    • Call resize_content() multiple times
    • Call update()
    • Call m_status_bar->update()
    • All of the above
    • All of the above, multiple times


    The only thing that produces the corrent result is calling
    Qt Code:
    1. m_status_bar->resize(m_status_bar->width(), 20);
    To copy to clipboard, switch view to plain text mode 
    after creating the status bar, but this is obviously bad ..

    Otherwise, the correct height 20 is only calculated when I request a resize as user during runtime, which I do like this:
    Qt Code:
    1. void keyPressEvent(QKeyEvent* e) { // member of QLabel subclass that contains the pixmap
    2. switch(e-key()) {
    3. //cases ..
    4. resize_pixmap();
    5. }
    6. }
    7. void resize_pixmap() { // member of QLabel subclass that contains the pixmap
    8. // calculate new_size / resize pixmap ...
    9. emit pixmap_resized(new_size); // this signal is connected to a slot in the QMainWindow sublass that calls resize_content
    10. }
    To copy to clipboard, switch view to plain text mode 

    I don't know what is the difference between requesting the resize during runtime as opposed to calling resize_content in toggle_status_bar programatically, but I assume there is some interal Qt slot called after resize? Which one, and how to do it programatically? Also I am confused why adjustSize() calculates the wrong status bar size in the first place .. can anyone help?
    Last edited by Maryu; 4th September 2020 at 22:25. Reason: add platform/version info

  2. #2
    Join Date
    Jan 2008
    Location
    Alameda, CA, USA
    Posts
    4,695
    Thanks
    259
    Thanked 753 Times in 743 Posts
    Qt products
    Qt5
    Platforms
    Windows Android

    Default Re: QStatusBar wrong adjustSize()? When is it calculated?

    Otherwise, the correct height 20 is only calculated when I request a resize as user during runtime
    Widget geometry cannot be guaranteed to be correct until the parent widget's showEvent() is first called. Until the widget is actually visible on screen, everything could either be wrong or some intermediate value calculated while the layout manager is doing its work. So you cannot get accurate sizes in your widget's constructor or in the resizeEvent() (before isVisible() returns true). You can get accurate geometry in the showEvent() -if- the child widget is visible (which means your status bar must be visible when the widget is first shown) or in the resizeEvent() (if isVisible() for the entire widget returns true).

    If your status bar is not initially visible, then trying to retrieve its size might not work because the layout manager hasn't needed to do anything with it. Calling show() on the statusBar() will also not result in an immediately correct result until the event loop has had a chance to run and the layout manager has been able to do its work.

    If you want your app to start with the status bar hidden, then there is a trick you can do to get the correct size (in the showEvent()) and then immediately hide it. There might be a blink because the main window will first show with the status bar visible and then immediately redraw with it hidden, but it will probably not be noticeable.

    Qt Code:
    1. void MainWindow::showEvent( QShowEvent * pEvent )
    2. {
    3. QStatusBar * pBar = statusBar();
    4. QRect statusRect = pBar->rect();
    5.  
    6. // Cause the statusbar to hide immediately after this event
    7. QTimer::singleShot( 0, pBar, &QWidget::hide );
    8. }
    To copy to clipboard, switch view to plain text mode 

    Qt Code:
    1. void toggle_status_bar() { // member of QMainWindow subclass
    2. if (m_status_bar)
    3. m_status_bar = nullptr;
    4. else {
    5. m_status_bar = new QStatusBar { this };
    6. m_status_bar->showMessage("some status message");
    7. m_status_bar->adjustSize(); // * this gives the wrong size ...
    8. }
    9. setStatusBar(m_status_bar);
    10. }
    To copy to clipboard, switch view to plain text mode 

    Why are you creating a new status bar every time you want to show a new status message? Just access the QMainWindow's built-in status bar (QMainWindow::statusBar()) and hide or show it (with a new message) when you need to.

    Qt Code:
    1. void toggle_status_bar() { // member of QMainWindow subclass
    2. if ( statusBar()->isVisible() )
    3. statusBar()->hide();
    4. else {
    5. statusBar()->showMessage( "some status message" );
    6. statusBar()->show();
    7. }
    8. }
    To copy to clipboard, switch view to plain text mode 

    The only time you want to use QMainWindow::setStatusBar() is when you have derived a custom widget from QStatusBar and want the main window to use your custom widget instead of the built-in one. And even then, you create it once, install it, and then reuse the same one for each new message.
    <=== The Great Pumpkin says ===>
    Please use CODE tags when posting source code so it is more readable. Click "Go Advanced" and then the "#" icon to insert the tags. Paste your code between them.

  3. #3
    Join Date
    Aug 2020
    Posts
    13
    Thanks
    3
    Qt products
    Qt5
    Platforms
    Windows

    Default Re: QStatusBar wrong adjustSize()? When is it calculated?

    Thanks I think that will help. Somehow I did not think to look for isVisible(), so I created a new one to be able to check for null. But your way makes more sense. I currently redesigned to overlay the status message on top of the label instead, so I don't have to handle additional label resizes ..
    Not sure which version I like better, so I may go back and try status bar again with your answer after the commit. Anyway it will help me in the future, thanks for the answer!

  4. #4
    Join Date
    Jan 2008
    Location
    Alameda, CA, USA
    Posts
    4,695
    Thanks
    259
    Thanked 753 Times in 743 Posts
    Qt products
    Qt5
    Platforms
    Windows Android

    Default Re: QStatusBar wrong adjustSize()? When is it calculated?

    Is there some reason why the status bar must be hidden if it isn't showing a message? After all, it takes up very little space and saves you a whole lot of otherwise unnecessary repaints of your main window every time it is shown and hidden.
    <=== The Great Pumpkin says ===>
    Please use CODE tags when posting source code so it is more readable. Click "Go Advanced" and then the "#" icon to insert the tags. Paste your code between them.

  5. #5
    Join Date
    Aug 2020
    Posts
    13
    Thanks
    3
    Qt products
    Qt5
    Platforms
    Windows

    Default Re: QStatusBar wrong adjustSize()? When is it calculated?

    I really dislike UI that I almost never need take up extra space for no reason in almost every application. One main point of my app is to have absolute minimal UI. Most of the time, there is no UI at all, only the exact content I want to see, nothing else.
    I know a program that provides similar functionality (though it still always has a window border, which I find unnecessary as well ..), but I need some other tools that it doesn't provide, so I started writing this. The status (bar) should only be shown when the user (probably myself) explicitly requests some extra information, which most of the time I don't need so it would just be in the way most of the time. So special needs I guess

  6. #6
    Join Date
    Aug 2020
    Posts
    13
    Thanks
    3
    Qt products
    Qt5
    Platforms
    Windows

    Default Re: QStatusBar wrong adjustSize()? When is it calculated?

    Hmm, I tried the suggestion now and it also does not work.
    I removed all new/delete and hide() on the status bar for testing, but it still calculates the wrong size after the first construction of the widgets.

    In the constructor of my main window, I only set up the layout and central widget, but not the widgets inside the central widget, because they depend on user choice (only one option is ever called per main window). I have something like

    Qt Code:
    1. MainWindow::MainWindow() :
    2. QMainWindow { }, // .. init central widget & layout
    3. {
    4. // connect slots / configure layout ..
    5. // there is no show() here
    6. }
    7.  
    8. MainWindow::open(bool use_scroll) { // this is called from outside MainWindow
    9. // ..
    10. if(!m_initialized) use_scroll ? init_with_scroll() : init_without_scroll();
    11. // line A
    12. load_content(); // this loads e.g. the pixmap in the label in the with_scroll case
    13. // line B
    14. }
    15.  
    16. MainWindow::init_with_scroll() {
    17. // init widgets / add to layouts / connect slots
    18. // line C
    19. show();
    20. // line D
    21. }
    22.  
    23. MainWindow::showEvent(QShowEvent*) {
    24. std::cout << "height " << statusBar()->height() << std::endl;
    25. }
    26.  
    27. // same procedure for init_without_scroll() ...
    To copy to clipboard, switch view to plain text mode 

    I tried moving statusBar() between the lines A-D, but first thing I noticed is that in the init_without_scroll() case, the status bar size is always calculated correctly (nvm the grey text, I had a different output in the resize function - the output in showEvent does not differ in the two cases. Though somehow I get the correct value in my resize function in this case, not sure why ..). On the other hand, in the init_with_scroll() case, the status bar height gives different, but always wrong results:

    • above code unchanged (first statusBar() inside showEvent): "height 30"
    • statusBar() or statusBar()->show() on line C: "height 18"
    • statusBar() or statusBar()->show() on line A, B, D: "height 30"


    Getting different sizes before and after show() makes sense, but why is it always wrong? I tried to reduce the code to everything I think is relevant, but I guess it looks like there might be an issue somewhere else and I should try to compile a MWE. But for now I guess I will just set the size manually and hope it doesn't change ..
    Last edited by Maryu; 5th September 2020 at 09:37.

  7. #7
    Join Date
    Jan 2008
    Location
    Alameda, CA, USA
    Posts
    4,695
    Thanks
    259
    Thanked 753 Times in 743 Posts
    Qt products
    Qt5
    Platforms
    Windows Android

    Default Re: QStatusBar wrong adjustSize()? When is it calculated?

    Your code in init_with_scroll() will not provide the correct size no matter where you ask for it, because as I said in my previous post, you have to let the event loop run so that the layout manager can calculate the final geometry of the widget and its layout before it is made visible. This will not happen until after your init function exits and control returns to Qt and the event loop.

    So, to reiterate:

    - until your widget receives the first showEvent(), no geometry can be guaranteed to be correct.
    - geometry will not be correct in the widget constructor
    - geometry will not be correct in a resizeEvent() that occurs before the first showEvent()
    - any child widgets which are hidden (i.e. isVisible() returns false for them) will probably not have a correct size in the showEvent() either, because the layout manager can ignore them.

    If you want to be able to resize your main window to accommodate showing and hiding the status bar, the only time you can get reliable geometry for the status bar is when it and the rest of the widgets are visible. If the status bar is initially hidden, then you cannot get reliable geometry until after you show() it and wait for the event loop to process that so the layout manager can recalculate the whole layout.
    <=== The Great Pumpkin says ===>
    Please use CODE tags when posting source code so it is more readable. Click "Go Advanced" and then the "#" icon to insert the tags. Paste your code between them.

  8. #8
    Join Date
    Aug 2020
    Posts
    13
    Thanks
    3
    Qt products
    Qt5
    Platforms
    Windows

    Default Re: QStatusBar wrong adjustSize()? When is it calculated?

    I thought the showEvent provided the way to ensure that the event has been processed, say if I call "QMainWindow::showEvent(e);" first. So even then I have to

    ... wait for the event loop to process that ...
    But how can I do that programatically?

    * From your first reply
    Qt Code:
    1. void MainWindow::showEvent( QShowEvent * pEvent )
    2. {
    3. QStatusBar * pBar = statusBar();
    4. QRect statusRect = pBar->rect();
    5.  
    6. // Cause the statusbar to hide immediately after this event
    7. QTimer::singleShot( 0, pBar, &QWidget::hide );
    8. }
    To copy to clipboard, switch view to plain text mode 

    I don't understand what the difference here is to my showEvent(), when I do not hide the statusBar anywhere in my test-code. This constructs the statusBar and then gets its size .. but that is exactly what my print-message outputs?

  9. #9
    Join Date
    Jan 2008
    Location
    Alameda, CA, USA
    Posts
    4,695
    Thanks
    259
    Thanked 753 Times in 743 Posts
    Qt products
    Qt5
    Platforms
    Windows Android

    Default Re: QStatusBar wrong adjustSize()? When is it calculated?

    say if I call "QMainWindow::showEvent(e);" first.
    You don't call this. In your main() function in main.cpp, if you declare a MainWindow instance "mw", then the next line "mw.show()" sets up the chain of calls internal to Qt that eventually result in a QShowEvent being placed in the event loop and your MainWindow::showEvent() method being called from within the Qt event loop handler.

    You can't force this to happen. There is a reason why all of the Qt events are protected members of QObject or QWidget. Your application code is not supposed to call them. If you want to cause an event to happen there are sendEvent() and p[ostEvent() methods in QApplication to do that. But in general, you don't want to do that, because sometimes even simple method calls can lead to an entire cascade of Qt events

    If you want to make a widget visible on screen, you simply call its show() method and let Qt figure out all the steps needed to do that.

    The call to QWindow::statusBar() returns the pointer to the QMainWindow status bar. As a side effect, if the status bar instance does not already exist, it creates a standard QStausBar instance and returns it. If you have a MainWindow.ui file that is compiled by UIC and your MainWindow class contains a pointer to the class created by UIC, then calling ui->setupUi( this ) in your MainWindow constructor will create a status bar, since this is included by default in the boilerplate code that creates the ui file. So in fact, the code I put into showEvent() simply gets the pointer that already exists.

    The QTimer line is there so that you can create the MainWindow with a status bar already instantiated (and set to be visible), have the window shown so the status bar will have a proper size, and then immediately hide the status bar. That's what the single shot QTimer will do - because it has a zero timeout period, the slot connected to the timeout signal (hide()) will be called immediately, as soon as the showEvent exits and control returns to the event loop.
    <=== The Great Pumpkin says ===>
    Please use CODE tags when posting source code so it is more readable. Click "Go Advanced" and then the "#" icon to insert the tags. Paste your code between them.

  10. The following user says thank you to d_stranz for this useful post:

    Maryu (5th September 2020)

  11. #10
    Join Date
    Aug 2020
    Posts
    13
    Thanks
    3
    Qt products
    Qt5
    Platforms
    Windows

    Default Re: QStatusBar wrong adjustSize()? When is it calculated?

    I see, I am not using ui files for this right now as there is nothing to really "lay out" in my current design.

    But still, in this showEvent(), there is no guarantee that the whole window (including status bar) has actually been drawn completely when I call statusBar()->rect(); - or what am I missing? Once the main windows show() is called after construction, all I know is there is some ShowEvent queued that will draw the window and its children at some point in the future ..

    Maybe I do not understand the reason for the timer:
    First, it is called after pBar->rect();, so it does not help anything with making sure that the statusBar was actually drawn by then.
    Second, even if it is called immediately with the timer, does this not just dispatch some sort of internal hide event, that again gets completed whenever Qt has the time for it? What is the difference to just calling hide() directly? And what does it have to do with getting the correct statusBar size?

    As far as I understood, the hide was simply to fulfill my need to still have a hidden statusBar by default, even if it needs to be drawn first. But it helps nothing with making sure that it is drawn before I get the size.

    If there is no (preferred) way to explicitly wait for an event to finish, is there some signal that Qt emits to notify me when the main window and its children have finished drawing? Then I could connect to this and simply get the size & hide the status bar as soon as I receive this "finished drawing" signal .. ?

  12. #11
    Join Date
    Jan 2008
    Location
    Alameda, CA, USA
    Posts
    4,695
    Thanks
    259
    Thanked 753 Times in 743 Posts
    Qt products
    Qt5
    Platforms
    Windows Android

    Default Re: QStatusBar wrong adjustSize()? When is it calculated?

    But still, in this showEvent(), there is no guarantee that the whole window (including status bar) has actually been drawn completely when I call statusBar()->rect(); - or what am I missing? Once the main windows show() is called after construction, all I know is there is some ShowEvent queued that will draw the window and its children at some point in the future ..
    First, you are confusing the showEvent() and the paintEvent(). The showEvent() is called just before the widget is made visible (i.e. painted) on screen. The showEvent() does not draw anything. All geometry calculations and layout are done, nothing is left except to paint it. Painting uses the geometry calculated by the layout system, it does not calculate it on the fly while painting. So you don't "wait for painting to be finished" before getting geometry. It is already there in the showEvent() and resizeEvent() methods, assuming that the things you want geometry for have "true" for their isVisible() status at the time you ask for the geometry. These events are called after the widget geometry has been calculated / recalculated and just before the widget is physically drawn onscreen by the paintEvent().

    isVisible() for a child widget simply means that when the widget and its children are drawn onscreen during a paint event, it will be drawn also. It also means that when the layout system is calculating the sizes and positions of everything inside your widget, that child will be included in the calculations. It does not mean it is currently, physically visible on screen.

    At the time Qt has put a QShowEvent on the event loop and control reaches your MainWindow's showEvent() method, you can be certain that your widget and every visible child widget will have correct geometry that can be queried.

    So the code I wrote with the QTimer is meant to ensure that if the status bar was created earlier (in the MainWindow constructor, either manually or as part of setupUi()) and was set to be visible, then you could retrieve the correct geometry for it (and presumably save it somewhere in your main window class so you could use it when resizing your window to account for the status bar). The QTimer part is there simply to then turn off the status bar immediately so that you app would appear to start up with the status bar hidden.

    If there is a child widget which is not instantiated or not visible during the first showEvent() then it won't have valid geometry because the layout system will likely ignore it.

    I am not sure what the sequence of Qt events is if you add a new widget or make a hidden widget visible after the first showEvent(). Almost certainly there will be one or more resizeEvent() and paintEvent() calls, as the layout system calculates the new geometry. I doubt that there will be a second showEvent() because the MainWindow is already visible.

    If there is no (preferred) way to explicitly wait for an event to finish,
    I think you are asking this because of your confusion about what happens at what point in going from a logical description of a widget and its children (widgets, layouts, widget-relative coordinates) to a set of colored pixels in an absolute position on screen.

    To beat the dead horse once more, you do not need to wait for "painting" to get the geometry of your widget and its (visible) children. The showEvent() and resizeEvent() are what you wait for, and in those events if the widget you want geometry for returns "true" when asked isVisible(), then the geometry you get will be correct.

    If for some reason you need to "wait" for an event to finish, there is really only one practical way, and that is to use the QTimer trick with your own slot. Invoking the QTimer::singleShot() method with a zero timeout period puts the event on the loop and it will be called as soon as possible after the event that is currently being processed exits.

    Note that this is not the same as calling your function directly from within the event handler. Your event handler might be only one step in a chain of function calls made to process the event. Some of these might occur before your event handler is invoked, some might be called after it. If you make a direct function call in your event handler, then you are interrupting the normal handling process. If you instead schedule a QTimer event, it guarantees that the timeout slot will not be called until all processing of the current event has been completed (along with any possibly higher priority events in the queue), and then your slot will be invoked.
    <=== The Great Pumpkin says ===>
    Please use CODE tags when posting source code so it is more readable. Click "Go Advanced" and then the "#" icon to insert the tags. Paste your code between them.

  13. #12
    Join Date
    Aug 2020
    Posts
    13
    Thanks
    3
    Qt products
    Qt5
    Platforms
    Windows

    Default Re: QStatusBar wrong adjustSize()? When is it calculated?

    Sorry if I am making you repeat things. I think I understand the general flow of Qt, but the details are hard to understand with the documentation alone to me, I wish there was more information on many functions. Some events, like key...Event, say you should call the parent class event, other events have no mention of whether I should or should not.

    I did not know the exact work show and paint events do when they are called, so this makes it clearer. But there are still details I'm not sure of.
    Is it something like

    Call constructor of my QMainWindow subclass "MainWindow" > QMainWindow gets constructed > MainWindow gets constructed >
    call MainWindow::show() -> Layout system "showEvent" (?) is queued to calculate geometries > some time later: geometries are done calculating, MainWindow showEvent is called > I should get the calculated size here >.. something? queues paintEvent > ...


    If this is how it works then I guess there must be something else wrong in my code, since even if I use your showEvent, I get a too-large height of 30. How do I know it is too large? Manually refreshing by hitting a button that calls my resize_content function, which recalculates only the full top-level window size (may or may not be different, same behavior in both cases) and ends in "resize(..." changes the height of status bar to 20.

    But I'm repeating my earlier posts now. My resize_content function does need a refactor so maybe it is something in there .. though the only Qt functions I touch in here are statusBar()->isVisible() to determine whether my top level window needs to account for status bar size, and resize(.. at the end. Or it is some entirely different bug. Will have to go back when I decide the priority is high enough to remove this magic number 20 for the status bar from my code.
    Last edited by Maryu; 8th September 2020 at 02:47.

  14. #13
    Join Date
    Jan 2008
    Location
    Alameda, CA, USA
    Posts
    4,695
    Thanks
    259
    Thanked 753 Times in 743 Posts
    Qt products
    Qt5
    Platforms
    Windows Android

    Default Re: QStatusBar wrong adjustSize()? When is it calculated?

    Some events, like key...Event, say you should call the parent class event, other events have no mention of whether I should or should not.
    I agree. Even after 12 years of working with Qt, I still do not know the answers to questions like these.

    Call constructor of my QMainWindow subclass "MainWindow" > QMainWindow gets constructed > MainWindow gets constructed >
    call MainWindow::show() -> Layout system "showEvent" (?) is queued to calculate geometries > some time later: geometries are done calculating, MainWindow showEvent is called > I should get the calculated size here >.. something? queues paintEvent > ...
    It is probably more like:

    - Call QMainWindow constructor to get the parent-child pointers set up and do whatever construction QMainWindow (and its base classes) requires
    - call setupUi() if you are using a UI file. This constructs the C++ child widgets / layouts / actions / etc. and initializes their parent-child relationships and properties
    - or call QWidget constructors directly (via new()) to create child widgets and layouts and set their properties.

    - at the end of the MainWindow constructor, there is a logical description of the UI in the form of QWidgets, layouts, and other components. Nothing else happens yet.

    - then somewhere, MainWindow:: show() is called (usually in main()). At this point, the Qt layout machinery takes over:

    - MainWindow:: resizeEvent() (and possibly other events) are called, sometimes multiple times as the layout system puts the parts of the QWidget / layout hierarchy into place and adjusts their positions and sizes
    - MainWindow:: showEvent() is called when all layout is done and the final geometry is set
    - MainWindow:: paintEvent() is called to finally render the widget to the screen

    When you manually resize the widget, either using the mouse or a call to resize(), then this layout procedure takes place again (minus the final showEvent(), since the widget is already visible), If you show or hide child widgets, the same thing happens. It can be expensive if you have a complex layout or if repainting the content of the centralWidget is expensive. This is one reason why repeatedly toggling the visibility of the status bar might be a false optimization - the layout (and possibly repainting) might actually happen twice - once when you show or hide the status bar, then again when you resize the centralWidget to take account of its presence or absence.

    The status bar does not live in isolation. It is probably contained within a QFrame within the MainWindow, which itself has dimensions. The frame could have a margin around its content, the main window's layout could have a margin around the frame, and so forth. So showing or hiding the status bar also must show or hide its container, and that geometry must be taken into account by the re-layout code. So the delta between the size you retrieve for the status bar itself and what you retrieve for the entire main window probably accounts for this extra decoration placed around the status bar.

    And remember that resizeEvent() might happen more than once during the layout before the final geometry is established. This will be especially true if you change the visibility of something in the layout - not only does the layout manager have to scale the contents of the widget to their new sizes, if you add or remove something, then it might have to layout the entire thing from scratch.
    <=== The Great Pumpkin says ===>
    Please use CODE tags when posting source code so it is more readable. Click "Go Advanced" and then the "#" icon to insert the tags. Paste your code between them.

  15. The following user says thank you to d_stranz for this useful post:

    Maryu (8th September 2020)

Similar Threads

  1. Replies: 1
    Last Post: 24th October 2009, 06:52
  2. QStatusBar
    By newermind in forum Qt Programming
    Replies: 3
    Last Post: 1st June 2009, 22:48
  3. Question about QWidget::adjustSize()
    By Vladimir in forum Qt Programming
    Replies: 2
    Last Post: 30th August 2007, 14:33
  4. about QStatusBar
    By Pang in forum Qt Programming
    Replies: 1
    Last Post: 16th November 2006, 05:15
  5. adjustSize for right adjustement
    By square in forum Qt Programming
    Replies: 1
    Last Post: 23rd May 2006, 10:03

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Digia, Qt and their respective logos are trademarks of Digia Plc in Finland and/or other countries worldwide.