@amina said in inheritance problem:

it is working now

great, so don't forget to mark your post as solved!

@JJLee said in Pushbutton promoted from QPushButton is invisible:

it led me to the solution!

great! so please don't forget to mark your post as solved then.

@christian-ehrlicher said in What to subclass?:

Especially compared to the idea to parse the data somehow from a sqlite file

Where I have said that? :)
I never had the idea to "parse" the sqlite file directly.

I will try to get the data with a query first and see what I can do with it :)
(I guess QSqlResult is the key?!)

No apologies needed (at least on my part). I don't hold grudges, and as long as you are staying civil there's nothing wrong with heaving a healthy argument.

How do you think about the usage of customised constructor implementations for the class “QStandardItem”?

@jsulm
TBH, I'm not I exactly sure I understand my own question!

@mrjj & you explained the practicalities --- you just need a QObject. (I am PyQt, so I don't have a "Q_OBJECT macro", but I guess PyQt's QObject() automatically has that present if I use such an object or inherit from it?)

My question was more of a "conceptual" one. If the OP has subclasses "with no UI", they are divorced from the UI, so I don't really see how they & the UI would know which signals to exchange/place slots on. But it's a bit of a woolly question....!

I had to add Q_OBJECT and also delete my debug folder once, to get rid of a few link errors.

Also got rid of the QThread subclassing, it is way easier to create a worker class and connect it through signals. There is really a lot of outdated example code out there.

Thanks for your help!

Hello,

Thanks you for the answer.

Mid'.

The Q_OBJECT macro can be put in public, protected or private section and it will do the same. It doesn't matter for moc but I highly recommend to always put it at the top of your class for the following reason:

The Q_OBJECT macro is defined like this:

#define Q_OBJECT \ public: \ //stuff... \ private: \ //other stuff...

So it's easy to make your other members private by mistake like this:

class Foo { public: Q_OBJECT int bar; //oh no! bar is private };

If you put the macro at the top it won't affect access declarations below:

class Foo { Q_OBJECT public: int bar; //yes! bar is public as intended };

For item to be editable you would implement flags() in your model and make sure the returned flag set contains Qt::ItemIsEditable. You'd also need to implement the setData() method and handle Qt::EditRole in the data() method.

For the columns from the database just return the base implementation of these methods and provide override only for your extra column.

It should be yes

Oh, I see. Thank you sir.

I don't understand your question 1.

With a QList of hidden column, you don't need to know the size of the array in your model and you don't need to loop through the complete array to know which columns are hidden or not. You just need to do something like if (!hiddenColumnList.contains(index.column())) { // do some stuff if column is not hidden }

Then what does your custom widget contain ?