Hi Bo and André! On Thu, Jun 28, 2012 at 3:41 AM, André Somers <[email protected]> wrote: > Op 28-6-2012 9:02, Bo Thorsen schreef: >> Den 28-06-2012 08:55, Andre Somers skrev: >>> Op 28-6-2012 8:21, Andreas Pakulat schreef: >>>> Hi, >>>> >>>> Am Donnerstag, 28. Juni 2012 schrieb Bo Thorsen : >>>> >>>> Hi Frank, >>>> >>>> Den 28-06-2012 06:40, K. Frank skrev: >>>> > Where in the documentation (not the source code) can I find out >>>> which >>>> > of the properties of a standard Qt QObject class is the designated >>>> > USER property? >>>> >>>> You can't find this, and it doesn't matter. You might be able to >>>> find it >>>> using the QMetaObject introspection, but I guess this is only for >>>> designer or something like it. I've never used this property. >>>> ... >>>> What do you need this for?
Well, it's not that important, but here's how the question came about for me: I'm using a custom delegate to create and editor for a QTableView. (See my earlier thread, http://lists.qt-project.org/pipermail/interest/2012-June/002775.html.) Editors don't have their own specific interface -- they're just QWidgets. (QAbstractItemDelegate::QWidget *createEditor (..)) How does the default version of void QAbstractItemDelegate::setModelData ( QWidget * editor, QAbstractItemModel * model, const QModelIndex & index ) const know which data in the QWidget is to be copied into the model? It's the USER property. So somebody (like me) who wants to use a QComboBox as the editor provided by a custom delegate has to experiment (or read the source code) in order to know whether he needs to override setModelData, as well as createEditor. >>>> ... > ... > I don't think these flags are implementation > details that don't need to be documented. The problem with them not > being documented is, that we also cannot rely on them being stable even > if we do find out what the flags are. Yes, I agree with this. Let's say I use a QComboBox as an editor provided by a custom delegate (and I don't override setModelData). Then the data that gets copied from my QCombox into my model is the QComboBox's curentIndex (its USER property). Let's say that this is exactly what I want. If we take the attitude that the lack of documentation of which property is the USER property means that this is not part of the official public interface of the class and is a mere implementation detail that can be changed willy-nilly in the future, then a new version of Qt would be allowed to break my (beautiful) code. The USER property feels like part of a QObject's public interface and therefore ought to be documented (and stable). >> That's why I asked OP what he wanted to use it for, since I think he's >> going in a wrong direction and there is some other way to achieve >> whatever it is he is doing. Well, it may be the wrong direction, but it's the direction that Qt has elected to go with its delegate / editor framework. > I do agree that it would be good to get some more insight into what the > OP wants to achieve. Well the summary (detailed in my earlier thread, linked to above) is that I want to use a QComboBox to edit a QString-valued column in a QTableView. > ... It seems that the take-away is that which property is the USER property isn't documented (in the standard documentation). Even if the USER property in a less commonly used feature of Qt, I would argue that it's still part of the public interface of QObject classes. (Not in the c++-purist sense of "public interface" since c++ doesn't have a property system, but still ...) So it ought to be specified in the class documentation. > André Thanks for everyone's comments. Cheers to all! K. Frank _______________________________________________ Interest mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/interest
