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);

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?
7917

[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 );


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); 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?
}
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();
}

@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();
}


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();
}


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.

[wysota]

I really miss discussions such as this one, thanks :)


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.

I'll tell you something interesting. Recently I've been interviewing people for work and one of the questions I asked them was what they considered the weakest spot in C++. Two of them (out of three? four?) said it was lack of garbage collecting. When I investigated further they couldn't say why this was so much of an issue. And those weren't some weekend programmers but rather people who programmed C++ for a living. So it seems memory management is not as big of an issue as people claim it to be. At least not for people who really know the language.


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.
I could agree that could be an issue with C but not with C++. In the latter you usually allocate memory upon constructing an object and deallocate it upon destructing the object. So it's all just a matter of proper data encapsulation. Again, not much of a deal for people who know what they are doing.


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!
Let's be very clear here. You can delete manually but you don't have to.


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.
I prefer the good old rule - delete your heap data, don't delete your stack data together with allocate your objects on the heap if you want them to persist and you can't copy them and allocate local variables on the stack so that the compiler can get rid of it for you. This works with Qt and without Qt.


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.
You can see this thread is about what happens if you don't give it a parent. Your rule says nothing about it. Furthermore this is compliant with your rule however the result depends on compiler implementation (and interpretation of C++ standard):


QObject o1;
QObject o2(&o1);


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.
That's not why you can copy them. The actual rule is that they represent values and not identities and thus can be copied. That together with an explanation of what implicit sharing is makes the proper answer of why we allocate them on the stack rather than on heap (with the only exception of QModelIndex which you should never allocate on heap regardless of anything).


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).
My official point of view is that since Qt went LGPL we have been flooded by programmers who are below average and are not willing to raise above that level. Sad but true. Even more sad that Qt really requires one to understand C++ so many of such "Sunday Developers" really waste their time instead of using something that requires less knowledge to be used efficiently (e.g. Visual Basic).


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.
Good for you -- but you're not an average person coming here what can be seen by the proportion of questions to answers in your posts.


Take Blanchette and Summerfield's "C++ GUI Programming with Qt4" for example.
I'm reluctant to discuss this book. It is much worse than "C++ GUI Programming with Qt3". I'd like to avoid talking about work of people whom I otherwise respect. I can talk about "Foundations of Qt Development" if you please. You don't have memory leaks there :)

[d_stranz]

I really miss discussions such as this one, thanks

Yeah, they are much more fun than "Why doesn't my program work? See if you can guess, because I'm not posting any code."


You can see this thread is about what happens if you don't give it a parent. Your rule says nothing about it. Furthermore this is compliant with your rule however the result depends on compiler implementation (and interpretation of C++ standard):

Yes, point taken. I thought about that as well - a good number of the posts here are programming errors that are essentially equivalent to that example - allocate something on the stack, pass it to another QObject as a child or parent by dereferencing it, then it goes out of scope, and either it goes BOOM! or nothing happens as expected.

But that leads to more rules and more exceptions to rules, and before you know it you've written another Qt book. ;)


Two of them (out of three? four?) said it was lack of garbage collecting.

Then they haven't discovered boost::shared_ptr<> yet.

At the cost of a little performance hit, it has saved me days of tracking down memory problems and has allowed me to write programs containing tens or millions of shared objects. It's the closest thing to garbage collection you can find in C++, in my opinion.


My official point of view is that since Qt went LGPL we have been flooded by programmers who are below average and are not willing to raise above that level.

I'm not sure that LGPL has all that much to do with it. (Or are you referring to this forum? I think the problem here is that too many people are finding out about it) .

Probably it has more to do with the availability of cheap PCs, free compilers and development environments, and people coming into the field at much younger ages and no experience. Even though my programming was self-taught, all I had to rely on back then was books - there wasn't much in the way of Internet in the '80s and '90s, and certainly not the tidal wave of online code you can find today. Now, if you want an algorithm to do "histogram-based image segmentation", well Google will give you page after page of hits. No need to understand why it works, just download the code and compile it.

Likewise for new people learning to program. It really isn't necessary to "learn" at all - you download an example, hack at it until it does what you want it to do, but you really haven't learned how to program. You're just a monkey with a typewriter, and sometimes by accident, you get something that works. And if you can't get it to work, you make a post here and hope that someone will get it to work for you.


"Sunday Developers"

Hey! I'm a Sunday developer! (and also Monday, Tuesday, Wednesday, Thursday, ...)

[wysota]

Yes, point taken. I thought about that as well - a good number of the posts here are programming errors that are essentially equivalent to that example - allocate something on the stack, pass it to another QObject as a child or parent by dereferencing it, then it goes out of scope, and either it goes BOOM! or nothing happens as expected.
Just let's be clear again -- the code I posted is correct. For instance:


QMainWindow mw;
QDialog loginDialog(&mw);
if(loginDialog.exec()) {
// ...
}

or more explicitly to avoid problems with broken compilers:

QMainWindow mw;
{
QDialog loginDialog(&mw);
if(loginDialog.exec()) ...
}




Then they haven't discovered boost::shared_ptr<> yet.
Unfortunately using smart pointers is not possible in every situation. I personally don't have any issues with memory management in C++ (even without using smart pointers).


I'm not sure that LGPL has all that much to do with it.
It's easy to explain. In the "pre-LGPL" era of Qt, you had to either pay for Qt (which was quite expensive, especially for people living in developing countries) or make your program open source (when using the GPL variant of the licence). Either way Qt was usually not the first choice for people wanting to write their first program but were rather used by companies and programming enthusiasts with a decent knowledge of C++. When LGPL came, Qt became accessible for virtually anyone in the world to use for pretty much anything. This caused a flood of would-be programmers from China and India as well as other Middle East countries. You can see that most of issues brought up here or on other forums related to Qt has nothing to do with Qt but rather with compilers, operating systems, low-level system API and of course C++.

[high_flyer]

@d_stranz
All is well and good - however, my point from the start didn't change, nor anything you say will change its validity:
The decision of allocating an object on the stack or heap does not depend on its type - which is what you rule essentially says.
Even if you found the rule helpful, it doesn't make it correct - and if you are a beginner reading your post, and you get used to that way of thinking, you will have hard time understanding why all of the sudden your application crashed, due to the fact you allocated something on the stack and not on the heap due to your rules, which lets say - due to scope issued was nonsense.
And having hard time to understand what the problem is was basically what you set to avoid from the start.
Making your life easier by using a principally wrong rule just shifts your problem to another time and complexity domain.
I too am not programming since yesterday, and I found out, that it pays more to start slow hard and correct, then fast easy and incorrect.