Adding status bar to QTextEdit

mchinand

It's working for your CCC_MainWindow because it inherits from QMainWindow which has a statusBar() method that returns the statusBar for the QMainWindow widget (other widgets don't have this). @ChrisW67 method is the correct way to create a Widget class that consists of a TextEdit with a statusbar. You probably want to add slots to it like updateTextEdit() and updateStatusBarText() that update the text its two sub-widgets. Then, what you previously had connected to QTextEdit::append() or QTextEdit::setText() would be connected your new class' slot instead (maybe create both an update and append slot).

Anonymous_Banned275

@mchinand What is being suggested is to replace the existing QTextEdit with generic widget class and it - makes sense. but I was trying to avoid that because it will break the rest of the code (MDI parent /child relations, QProcess etc ) ) including "read stdout ".
I still do not understand why I cannot "access " the QTextEdit layout... oh well..

mchinand

You're not replacing your QTextEdit with a 'generic Widget', it's a widget that has both a QTextEdit and a QStatusBar in a single layout; exactly what you are trying to achieve. Your new widget class will have slots that basically just forward their text arguments to either the QTextEdit or QStatusbar (i.e., the slots will consist of only one line of code).

Christian Ehrlicher

@AnneRanch said in Adding status bar to QTextEdit:

the participants to track by moving it ?

I only said that @mchinand already posted the correct solution (which you're ignoring the whole time) - so how should this distract other users here?

Anonymous_Banned275

@mchinand To all who contributed to this thread - thanks very much, appreciate all.
There has been MAJOR fault with most all of the suggestions - they are OK in THEORY.
I have said somewhere that I like to ADD status bar to WORKING code. I will not dicker about meaning of "replacing" , but the existing QTexrEdit is a MDI child and replacing it with QWidget as suggested "breaks the code" big time .
Adding "status bar " would be nice to have , but I am not willing to spent time to fix the broken code for "nice to have".
Again I do appreciate all the help rendered, but it is time to call it quits.

CASE CLOSED.

Christian Ehrlicher

@AnneRanch said in Adding status bar to QTextEdit:

I have said somewhere that I like to ADD status bar to WORKING code. I will not dicker about meaning of "replacing" , but the existing QTexrEdit is a MDI child and replacing it with QWidget as suggested "breaks the code" big time .

And everybody told you (even on so) from the beginning that this is not possible and you have to create a new widget which contains the two widgets. That's the way to go with every compound widget you want to create.

Anonymous_Banned275

Would anybody in this forum be interested in having a discussion about using "super"?

https://stackoverflow.com/questions/180601/using-super-in-c

I have received the following suggestion to resolve the QTextEdit / status bar issue.
I have never heard of using "super" , and it is little confusing to me since QTextEdit is a base class for my "child" class.

The attached code is using setLineWrapMode( and claims that method is inherited by QTextEdit.

I have not tried to implement this code in my app.

#include <QApplication>
#include <QScrollBar>
#include <QStatusBar>
#include <QTextEdit>

namespace {
  class text_edit: public QTextEdit {
    using super = QTextEdit;
  public:
    explicit text_edit (QWidget *parent = nullptr)
      : super(parent)
      , m_status(this)
      {
        m_status.setStyleSheet("background-color: gray;");
        m_status.showMessage("Status text goes here...");
        show_status(true);
        horizontalScrollBar()->installEventFilter(this);
        verticalScrollBar()->installEventFilter(this);
        setLineWrapMode(QTextEdit::NoWrap);
      }
  protected:
    virtual bool eventFilter (QObject *obj, QEvent *event) override
      {
        if (event->type() == QEvent::Show || event->type() == QEvent::Hide)
          update_status_geometry();
        return super::eventFilter(obj, event);
      }
    virtual void resizeEvent (QResizeEvent *event) override
      {
        super::resizeEvent(event);
        update_status_geometry();
      }
  private:
    void show_status (bool on)
      {
        if (on) {
          setViewportMargins(0, 0, 0, m_status.height());
          m_status.show();
        } else {
          setViewportMargins(0, 0, 0, 0);
          m_status.hide();
        }
      }
    void update_status_geometry ()
      {

        /*
         * Calculate initial geometry of the QStatusBar based on its size hint.
         */
        auto s = m_status.sizeHint();
        s.rwidth() = width();
        QRect geom(QPoint(0, 0), s);
        geom.moveTop(height() - s.height());

        /*
         * Adjust the status bar geometry to allow for the scroll bars.
         */
        if (horizontalScrollBar()->isVisible())
          geom.moveTop(geom.top() - horizontalScrollBar()->height());
        if (verticalScrollBar()->isVisible())
          geom.setRight(geom.right() - verticalScrollBar()->width());
        m_status.setGeometry(geom);
      }
    QStatusBar m_status;
  };
}

int
main (int argc, char **argv)
{
  QApplication app(argc, argv);
  text_edit te;
  te.show();
  return app.exec();
}
#endif
#endif // STATUS_BAR_NOTES_COPY_H

Chris Kawa

@AnneRanch said:

Would anybody in this forum be interested in having a discussion about using "super"?

It's an idea from other languages. Java has super, C# has base. All it does is give you a name of the base class when you're subclassing something. There's no such thing in C++, so this is a little trick to emulate that feature with an alias (using keyword). Since it's just an alias it doesn't have to be named super. You might as well call it foobar.

The idea of using this pattern is that if you decide to change the class you're inheriting from you don't have to "fix" all the other places where you used your base class name, just the alias. It also protects from a common bug that happens when you're changing the inheritance structure. For example if you have code like this:

class MyClass : public QWidget
{
   void mousePressEvent(QMouseEvent* evt) override
   {
      QWidget::mousePressEvent(evt); //calling base implementation
   }
}

and later decide to change the inheritance to

class MyClass : public QPushButton

but forget to also change the implementation of mousePressEvent to call the QPushButton implementation, this code will still compile and sometimes even work correctly if the new class implementation doesn't do anything special. But sometimes you're skipping important code and it's a difficult to find bug, because everything is legal, compiles and runs without warning. It just doesn't do what you wanted.

If you use an alias like this:

class MyClass : public QWidget
{
   using foobar = QWidget;
   void mousePressEvent(QMouseEvent* evt) override
   {
      foobar::mousePressEvent(evt); //calling base implementation
   }
}

You only have to change the alias and it will be ok everywhere. Of course you can still forget to change the alias too, but it's just one place instead of every other usage of the class name.

That being said it's just a code style, so matter of opinion if you should use it or not. It has some benefits but I find it not a big deal in practice. Personally I don't use it, but if I'm adding something to an existing codebase that does, I will for consistency.

mchinand

Using the example code in your post about super to add a statusbar to a QTextEdit looks more complicated than the compound widget approach. It's still not clear to me why you think that it will be so hard to modify your code to use a custom compound widget in place of a QTextEdit.

Chris Kawa

super has nothing to do with the status bar issue. It's just someone's code style. You can do the same without it.

And yes, the posted solution has issues, hardcoded values and styles and is generally mega-super-ugly. Whatever hackery code you can come up with is gonna have issues and be worse than the correct solution - put text edit and status bar separately in a container widget. That is how you're supposed to compose widgets in Qt, whether you like it or not. It's just a couple lines of code more, certainly a lot easier than that thing.