Question on QLineEdit Style

[comuslxl]

Hi all:
I want one enabled QLineEdit widget(named testLE) to have the same background color when it is disabled.(It should look like a QLabel) The following is my code:

QColor *color = new QColor;
*color = palette->color(QPalette::Disabled,QPalette::Base);
palette->setColor(QPalette::Normal,QPalette::Base,*color); 
ui->testLE->setPalette(*palette);
ui->testLE->setFrame(false);

QColor *color = new QColor;
*color = palette->color(QPalette::Disabled,QPalette::Base);
palette->setColor(QPalette::Normal,QPalette::Base,*color); 
ui->testLE->setPalette(*palette);
ui->testLE->setFrame(false);

To copy to clipboard, switch view to plain text mode 

The above code can realize my idea. However when i click a button that opens an file-open-dialog, the background of the QLineEdit comes to default(white).
Could anyone plz explain why the background changes to default?
And could u plz tell me the way to keep it's color when other dialog popup?
QT.jpg

[d_stranz]

You write some pretty strange code. Most of these pointers are totally unnecessary; these should be local variables allocated on the stack, not allocated pointers from the heap. If you do this in other parts of your code, no doubt you have memory leaks everywhere from local variables that are allocated on the heap but never deleted.

QPalette palette = ui->testLE->palette();
QColor color = palette.color( QPalette::Disabled, QPalette::Base );
palette.setColor( QPalette::Normal, QPalette::Base, color ); 
ui->testLE->setPalette( palette );
ui->testLE->setFrame( false );

QPalette palette = ui->testLE->palette();
QColor color = palette.color( QPalette::Disabled, QPalette::Base );
palette.setColor( QPalette::Normal, QPalette::Base, color ); 
ui->testLE->setPalette( palette );
ui->testLE->setFrame( false );

To copy to clipboard, switch view to plain text mode 

Other than that, you haven't showed enough code to tell where the problem might be. Remember also the QPalette is inherited - anything that is not explicitly set is inherited from the widget's parent or from the application defaults.

You might also try setting the QPalette::Window color to be the same as the disabled Base color.

[comuslxl]

Thank you very much for figuring out my mistake. In fact, in C++ GUI Programming with QT4, many examples like QLabel* label = new QLabel("") are given which may also lead to memory leak. The right code should be QLabel label(""), or QLabel* label = new QLabel("",this) [add "this" to tell parent, namely this, to delete QLabel when parent itself is destoried], or just delete the (QLabel*) label manually, right?

As for the QLineEdit's background, to be exact, it changes to default(white) every time the dialog loses focus(e.g click to active another window like firefox or notepad), so I add

palette.setColor(QPalette::Inactive,QPalette::Base,color);

palette.setColor(QPalette::Inactive,QPalette::Base,color);

To copy to clipboard, switch view to plain text mode 

then it works! Thank u again for your help and I've learnt a lot. Thank you!

[wysota]

In fact, in C++ GUI Programming with QT4, many examples like QLabel* label = new QLabel("") are given which may also lead to memory leak.

No, they may not.

The right code should be QLabel label(""), or QLabel* label = new QLabel("",this) [add "this" to tell parent, namely this, to delete QLabel when parent itself is destoried], or just delete the (QLabel*) label manually, right?

No.

[high_flyer]

@wysota:
Don't be so harsh.
They wont understand what you mean.

@comuslxl
Allocating on the heap does not lead to mem leaks.
Programmers who forget to delete the pointers do.
It is not always desired to have a parent for any given object, and more often than not, you want your variable to stay alive beyond the scope in which it was allocated in which case you have to use dynamic allocation.

[wysota]

@wysota:
Don't be so harsh.
They wont understand what you mean.

And you think they are going to understand what you mean?

Let me be very very explicit about what I said earlier, then - examples in the book call a method that sets a QObject parent to object created on the heap without explicitly passing a parent to the constructor of the object.

[high_flyer]

And you think they are going to understand what you mean?

Well, if they don't they have to go back to C++ basics.

[comuslxl]

@high_flyer
I understand what you said. Thank you!
In standard C++ programming, there should be delete/free operation corresponding to new/malloc. Howere, in Qt, sometimes delete seems to be unnecessary. Here is the first program in C++ GUI Programming with QT4:

#include <QApplication>
#include <QLabel>
 
int main(int argc, char* argv[])
{
    QApplication app(argc, argv);
    QLabel *label = new QLabel("Hello Qt!");
    label->show();
    return app.exec();//memory leak? correction: int ret = app.exec(); delete label; return ret; right?
}

#include <QApplication>
#include <QLabel>

int main(int argc, char* argv[])
{
    QApplication app(argc, argv);
    QLabel *label = new QLabel("Hello Qt!");
    label->show();
    return app.exec();//memory leak? correction: int ret = app.exec(); delete label; return ret; right?
}

To copy to clipboard, switch view to plain text mode 

And what about other examples?No memory leak? and what's the reason plz?

//findfiledialog.h
class FindFileDialog : public QDialog
{
    Q_OBJECT
 
public:
    FindFileDialog(QWidget *parent = 0);
 
private:
    QLabel *namedLabel;
    QLabel *lookInLabel;
    QLineEdit *lookInLineEdit;
}
//findfiledialog.cpp
#include <QtGui>
 
#include "findfiledialog.h"
 
FindFileDialog::FindFileDialog(QWidget *parent)
    : QDialog(parent)
{
    namedLabel = new QLabel(tr("&Named:"));
    namedLineEdit = new QLineEdit;
    namedLabel->setBuddy(namedLineEdit);
 
    ....
 
    QGridLayout *leftLayout = new QGridLayout;
 
    ....
 
}
//main.cpp
#include <QApplication>
 
#include "findfiledialog.h"
 
int main(int argc, char *argv[])
{
    QApplication app(argc, argv);
    FindFileDialog dialog;
    dialog.show();
    return app.exec();
}

//findfiledialog.h
class FindFileDialog : public QDialog
{
    Q_OBJECT

public:
    FindFileDialog(QWidget *parent = 0);

private:
    QLabel *namedLabel;
    QLabel *lookInLabel;
    QLineEdit *lookInLineEdit;
}
//findfiledialog.cpp
#include <QtGui>

#include "findfiledialog.h"

FindFileDialog::FindFileDialog(QWidget *parent)
    : QDialog(parent)
{
    namedLabel = new QLabel(tr("&Named:"));
    namedLineEdit = new QLineEdit;
    namedLabel->setBuddy(namedLineEdit);

    ....

    QGridLayout *leftLayout = new QGridLayout;

    ....

}
//main.cpp
#include <QApplication>

#include "findfiledialog.h"

int main(int argc, char *argv[])
{
    QApplication app(argc, argv);
    FindFileDialog dialog;
    dialog.show();
    return app.exec();
}

To copy to clipboard, switch view to plain text mode 

@wysota
Thank you! By saying examples in the book call a method that sets a QObject parent to object created on the heap without explicitly passing a parent to the constructor of the object, then can you plz explain to me what's the METHOD? or any documentation on this question?

[wysota]

And what about other examples?No memory leak? and what's the reason plz?

A leak is there if an object is not deleted when it is no longer needed and the program keeps executing. In the example you quoted the label object is used throughout the whole life of the program. I can agree that this code is not 100% correct since the destructor of the object is not called upon returning from main() however technically speaking there is no memory leak there since all memory is freed when the process dies.

@wysota
Thank you! By saying examples in the book call a method that sets a QObject parent to object created on the heap without explicitly passing a parent to the constructor of the object, then can you plz explain to me what's the METHOD? or any documentation on this question?

e.g. QLayout::addWidget()

[comuslxl]

@wysota
I've learnt a lot!
Thank you!

@high_flyer
@d_stranz

Thank you all! Great help! Many thanks!

[d_stranz]

@comuslxl: You are welcome.

Qt can be very confusing about use of memory. There are two simple rules which I follow:

1. If a class is derived from QObject, then usually you create it on the heap using new. If you give the new instance a parent, then the parent will delete it and there is no memory leak. You can give an object a parent in many ways:
- in the constructor: myObject = new QObject( parentObject );
- explicitly: myObject->setParent( parentObject );
- using some other method call that internally sets the parent: parentObject->addWidget( myWidget );, etc.

Classes derived from QObject always have a constructor that take a "parent" argument.

2. If a class is not derived from QObject (QColor, QFont, QPen, QString, etc.), you almost always create it on the stack: QPen myPen; and pass it into a method by reference: painter->setPen( myPen ); If you create the instance on the heap using new, then you must also delete it.

The major exception to rule #1 is when you create the main window for an application in the main() function:

int main( int argc, char * * argv )
{
  QApplicatation app( argc, argv );
  QMainWindow  mainWindow;
  mainWindow.show();
  return app.exec();
}

int main( int argc, char * * argv )
{
  QApplicatation app( argc, argv );
  QMainWindow  mainWindow;
  mainWindow.show();
  return app.exec();
}

To copy to clipboard, switch view to plain text mode 

In this case, the QMainWindow instance is created on the stack and remains in scope for the entire program. Its parent widget is the desktop, and is assigned implicitly by Qt. The window is destroyed and any memory is deleted when the program exits, so there is no memory leak.

The other exception is when you use a temporary QDialog (such as QFileDialog) to get information from the user:

void MyMainWindow::onGetColor()
{
  QColorDialog clrDlg( this );
  if ( QDialog::Accepted == clrDlg.exec() )
     newColor = clrDlg.currentColor();
}

void MyMainWindow::onGetColor()
{
  QColorDialog clrDlg( this );
  if ( QDialog::Accepted == clrDlg.exec() )
     newColor = clrDlg.currentColor();
}

To copy to clipboard, switch view to plain text mode 

This is the same situation as main() above; the QColorDialog instance is only in scope for the life of the method. Its parent is set to "this" (the main window) so it will be centered on the window when it is shown. Otherwise, it will be deleted when the method exits and will be removed from the main window's list of child widgets.

[high_flyer]

1. If a class is derived from QObject, then usually you create it on the heap using new. If you give the new instance a parent, then the parent will delete it and there is no memory leak. You can give an object a parent in many ways:
- in the constructor: myObject = new QObject( parentObject );
- explicitly: myObject->setParent( parentObject );
- using some other method call that internally sets the parent: parentObject->addWidget( myWidget );, etc.

Classes derived from QObject always have a constructor that take a "parent" argument.

2. If a class is not derived from QObject (QColor, QFont, QPen, QString, etc.), you almost always create it on the stack: QPen myPen; and pass it into a method by reference: painter->setPen( myPen ); If you create the instance on the heap using new, then you must also delete it.

Deciding if an object should be allocated on the heap or stack has nothing and should have nothing to do with the fact its a QObject or not, or any other type of class.
However:
scope of usage, performance issues, resource issue should.

[wysota]

scope of usage, performance issues, resource issue should.

Totally agreed.

[d_stranz]

Nitpicks, you two.

Sometimes presenting a relatively simple set of rules to help guide a beginner is better. If you are trying to write your first Qt programs and just can't get it to work because you misunderstand basic Qt principles, you aren't worrying about "scope of usage, performance issues, and resource issues."

When I first started to learn Qt, one of the hardest things to understand was who was in charge of an object's lifetime and whether an object could be stack vs. heap allocated. Understanding the simple rule that "if it is a QObject then its parent will delete it" was a key to end my confusion. A large percentage of the "why doesn't this work?" posts in this forum are exactly because of misunderstanding the Qt parent-child concept and stack vs. heap allocation with respect to object lifetimes.

Once the programmer figures that out and starts having working programs, that is the time to start thinking about the nuances of performance and scope.

[wysota]

Sometimes presenting a relatively simple set of rules to help guide a beginner is better.

The problem is usually people stop at this point. Then they spread those rules without proper understanding that it is merely a simplification. They write a "tutorial", post it somewhere in the Web and then other people read it, incorrectly apply those rules they learned by reading the tutorial and come here (or elsewhere) claiming that Qt is stupid and difficult becaust it doesn't work the way they read about in the tutorial. Of course totally missing the point that Qt has nothing to do with this.

If you are trying to write your first Qt programs and just can't get it to work because you misunderstand basic Qt principles, you aren't worrying about "scope of usage, performance issues, and resource issues."

If one knows the rules of C++, those same rules apply to Qt. If they don't know the rules, they should learn them first before trying to write their first Qt program.

Once the programmer figures that out and starts having working programs, that is the time to start thinking about the nuances of performance and scope.

What I'm worried about is that this "once" often never happens.

[comuslxl]

@d_stranz
I have almost the same question when I begin my first Qt program. Your rules are helpful, and can help new Qt programmers to quickly finish their first Qt program without too many critical bugs. This's a very very good way to lead someone to the world of Qt programming.
@wysota
In fact, many books are using the same way to help programmers to gradually understand Qt. Just think about what we have learnt when we are 7,8 years old, we are told sqrt(-1) is wrong, but what about 10 years later? I think people would like to learn a certain thing step by step. If a beginner is told the danger of memory leak or some other abstract issues at their first program, they may not serious about those because they don't know what they are and how they come up. Only when they themselves witness the consequences of e.g memory leak will they keep an eye on the problem. So I think study is a process of correction. If one is STUDYING, then "once" will happen, i'm sure.

[wysota]

In fact, many books are using the same way to help programmers to gradually understand Qt.

Two facts:
1. People don't read books nowadays, they read tutorials
2. If they do read a book, they read the first chapter and then they put the book aside because they are excellent programmers now.

Just think about what we have learnt when we are 7,8 years old, we are told sqrt(-1) is wrong, but what about 10 years later?

When you are 8 years old, you do not try to calculate sqrt(-1). People do try to use everything C++/Qt offer starting from the first day of their programming life. Just read 100-200 random threads on this forum and you'll come to similar conclusions.

If one is STUDYING, then "once" will happen, i'm sure.

Yes... "if"... And yet people come here and don't know the difference between C++ and Qt or between a compiler and an IDE (e.g. "I upgraded QtCreator to 2.5.0 and now my program doesn't work"). People do not bother learning why things work the way they work if they find a "solution" to their "problem" after searching the internet for two minutes. They immediately fall into another pitfall and start browsing forums for solutions on that.

[ChrisW67]

In standard C++ programming, there should be delete/free operation corresponding to new/malloc. Howere, in Qt, sometimes delete seems to be unnecessary. Here is the first program in C++ GUI Programming with QT4:

Just for the record, that example is accompanied by an explanation that reads:

For simplicity, we don't bother calling delete on the QLabel object at the end of the main() function. This memory leak is harmless in such as small program, since the memory will be reclaimed by the operating system when the program terminates.

So I think it was adequately explained from the start. This is, of course, nothing to do with Qt... it's the "standard C++ programming" you allude to.

[high_flyer]

So I think it was adequately explained from the start.

Which just underlines what wysota said here:

The problem is usually people stop at this point. Then they spread those rules without proper understanding that it is merely a simplification.

@d_stranz:

Nitpicks, you two.

Not at all.
You are taking this personally (so it seems).
Its not Nitpicking, its correcting a WRONG explanation you wrote.
What you wrote is just not true. period.

If you are trying to write your first Qt programs and just can't get it to work because you misunderstand basic Qt principles, you aren't worrying about "scope of usage, performance issues, and resource issues."

You should if you are confronted by the question "should I allocate dynamically or on the stack".
You may say, performance is not important for me, now, even resources, but scope of usage will smack you in face in the simplest example where scope plays a role (life time of a variable).
So the level of your programming doesn't play a role when you have to use the correct decision parameters.
Your rules imply that there is a connection between the object type and the way it should be allocated and that is plain wrong, and this is a forum where people learn - and if I see something that I know to be wrong for a fact, I can't just let it by.
Its not personal, and its not hairsplitting - its fundamental and you'd be wise to try and understand it, and not fight it.

[d_stranz]

You are taking this personally (so it seems).

No, not at all. Arguments over religion are just that - arguments - where both sides can agree to disagree and still laugh over beers later.

I've been programming in C and C++ since about 1983, when C compilers first started appearing for PCs. One of the first things you learn (especially in the days of 640KB PC RAM) is that if you malloc(), you had better match it with a free() or things will quickly grind to a halt. Later, C++ taught the same thing: match up your new() and delete() or you are in for big trouble.

You spend days beating your head on the wall, trying to find memory leaks where you thought you had paired everything up, or looking for crashes because you did pair things up but made the mistake of using the pointer after it had been deleted. These are lessons every C++ programmer learns the hard way, and you would be lying to me if you said it had never happened to you.

Along comes Qt. Here you have a programming paradigm where you almost always use new() to allocate a Qt object instance, but then almost never use delete() to get rid of it! How can this not cause massive memory leaks? Widget after widget being created but apparently never deleted. Even worse, if you do call delete on an instance you have allocated, your program crashes! What's going on here?

Here is where I insist that the simple rule I gave is important to new Qt programmers. The simple rule explains why you don't have to call delete() on QObject instances, why you usually can't call delete() on QObject instances without bad things happening, because the rule explains who is in charge of the instance's lifetime and makes it clear that Qt isn't somehow breaking the C++ rules.

So, the simple rule that says, if you create a QObject instance and give it a parent, the parent takes charge of deleting it clears up a lot of confusion and gets a novice on the path to writing working Qt programs much more quickly than trying to figure it out without the rule. It also helps explain why other Qt class instances can be created on the stack and can be assigned, copied, passed by value, or reused because they don't have parents and you are in charge of their lifetimes. Yes, the rules are simple, and there are plenty of use cases where you might want to do something differently, but the average programmer will learn those things as they get more proficient. (If they don't, then they are below average, IMO).

I have most of the Qt books that have been written, some of them in several editions. I haven't read the first chapter and then put them on the shelf. I pretty much read them cover to cover because that's the way I learn new concepts. But one of the things that isn't adequately explained in most of these books is QObject lifetimes.

Take Blanchette and Summerfield's "C++ GUI Programming with Qt4" for example. On the very first page of the first chapter, the Hello World example starts out with a memory leak - a QLabel instance is allocated, but never freed. On the next page, it is explained that this is indeed a memory leak, but it is OK (NOT!) because the OS will clean things up when the program exits. What? Memory leaks are OK in Qt programming? A few pages later, there is another example, with more widgets being allocated and never freed, and the same apparent memory leaks. In fact, throughout the entire first chapter, except for the one sentence aside that says the "OS will clean things up", there is no mention of what the Qt parent-child hierarchy really means in terms of memory management. So, you assume that memory leaks are just part of the game in Qt.

It isn't until page 18 in the next chapter where in a single paragraph, it is explained that "Since we used new to create the dialog's widgets and layouts, it would seem that we need to write a destructor that calls delete on each widget and layout we created. But this isn't necessary since Qt automatically deletes child objects when the parent is destroyed, and the child widgets and layouts are all descendants of the FindDialog". (Note that it isn't explained that this only applies to the QObject class hierarchy).

And then on page 19, FindDialog (the example from Chapter 2) is itself used in an app that has a memory leak.

So what do you do when even one of the more respected Qt books teaches bad programming? How is a new Qt programmer supposed to learn when to call delete() and when not to? Who cares about performance and resource allocation when you can't get your stupid program to run without crashing or memory leaks? You have to be able to walk before you can learn to run.