Здравствуйте, SaZ, Вы писали:

SaZ>Здравствуйте, _hum_, Вы писали:

__>>"что-то где-то как-то будет появляться". и это вы считаете информацией? в каком именно месте, и что делать, если я хочу это место изменить?

SaZ>Приведите конкретный пример, где вам нужно знать реальный тип QWidget *parent. А то вы всё говорите, что что-то хотите сделать. А что сделать — не ясно.

например, организовать эдитор, у которого бы был элемент, выходящий за пределы поля ячейки, но при этом не выходящий за пределы границы таблицы (то есть, его геометрия зависела бы от того, в каком положении относительно границ таблицы располагается ячейка). как вариант:


SaZ>Повторюсь, что в соответствии с документацией это может быть абсолютно любой виджет. Ваша задача, как разработчика делегата, разместить свой виджет поверх парента. В качестве подсказки вам вторым аргументом передали координаты ячейки, для которой запускается редактирование. У вашего же виджета есть волшебные методы move и resize. Координаты есть, парент есть — вперёд.

во-первых, там во втором аргументе QStyleOptionViewItem, в котором по документации непонятно какие координаты содержатся — по крайней мере, ничего, кроме

QStyleOptionViewItem
[...]
Inherits: QStyleOption
[...]
QRect QStyleOption::rect

This variable holds the area that should be used for various calculations and painting.

я не нашел (примеры не в счет).
а во-вторых, даже если есть координаты ячейки, все равно координаты границы неизвестны, а потому перемещение "не выходя за пределы границы таблицы" не представляется возможным выполнить без знания того, кто же родитель (ну или более общее — как связаны координаты родителя с координатами поля таблицы).

и на всякий случай подчеркну еще раз — я не против того, чтобы так и было (чтоб в createEditor не было возможности позиционирования виджета эдитора, потому как для этого, как я понял, задуман updateEditorGeometry), я лишь против того, чтобы документация писалась так коряво, когда человек, впервые ее читающий, сбивается с толку фразами "parent используется для настройки того, как будет отображаться эдитор", а на деле это далеко не так (и даже примечаний на этот счет нет).
изначально-то с этого и началось — я указал, что документация к qt, несмотря на ее объемность, намного хуже написана, чем тот же msdn, а не вел речь про целесообразность организации схемы создания эдитора делегата.