[Qt 4.5.0] QHttp и QProgressDialog, странное поведение Опции

[SABROG]

Хочу отображать QProgressDialog сразу же как пользователь нажал на кнопку типа "Скачать". Если не делать dialog.exec(), то обычно диалог появляется через 4 секунды сам (minimumDuration) или при первом step'e (изменении значения в прогрессе). Вроде бы все работает нормально за исключением того, что пользователь ждет появления диалога секунд 10, а сам диалог появляется на секунды 3. Связано это с тем, что при запросе xml файла с http сервера присходит его генерирование на основе данных в БД, а сам процесс скачивания быстрый. Так вот если все-таки делать dialog.exec(), чтобы пользователь хотябы видел, что нажатие на кнопку запустило процесс ожидания файла с сервера, то получается следующая ситуация.

По сигналу void QHttp::dataReadProgress ( int done, int total ) [signal] я меняю прогресс на диалоге. Иногда всё нормально работает и при достижении done==total диалог автоматически закрывается (типа 100% скачано). А иногда done приходит меньше, чем total, но затем следует requestFinished не дойдя до 100% и диалог остается висеть на 98-99% пока не нажмешь cancel. Ввиду разного поведения в разных ситуациях я исключаю возможность того, что сервер передает неправильный размер данных.

Сообщение отредактировал SABROG - 17.6.2009, 12:34

[SABROG]

и посмотреть, действительно ли это происходит.

Действительно происходит, но метод, который ты предложил об этом не сообщит, т.к. он вызывается только в методе QObject::disconnect(), а деструктор QObject::~OObject не использует метод disconnect(), он предпочитает сам пробежаться по списку и поудалять всё при этом никуда не сообщив.

Скорее всего сомнение закралось в тот момент, когда представилась следующая картина. Один объект постоянно живет и его сигналы подключены к массе другим объектам, которые то появляются, то умирают. Узнает ли объект о том, что какие-то объекты уничтожились и нужно ли разрывать с ними связь. Так вот в деструкторе каждого QObject'a разрывается связь как с приемниками (receivers), так и с передатчиками (senders). В последнем случае удаляющийся объект как лазутчик получает доступ к объекту, который шлет ему сигналы и удаляет себя из его списка. Типа как в qip "Удалить себя из списка контакта".

---
Сейчас еще одна проблема возникла, у QNetworkReply есть метод abort(), но это не слот и поэтому я никак не могу соединить кнопку cancel у QProgressDialog со слотом abort. Придется создавать свой собственный слот, т.к. наследоваться от QNetworkReply не хочется, да и бесполезно, ведь указатель на него генерит QNetworkAccessManager, а он ничего не знает о моем классе.
---
Блин, тролли жгут. Когда я задал вопрос в тех поддержку о том кто должен удалять указатель на QNetworkReply возвращаемый от QNetworkAccessManager::get(), то получил ответ - читай документацию. Я прочитал и там было написано:

Note: The slot is responsible for deleting the object at that poi

Дословный перевод гугла:

Примечание: слот отвечает за удаление объекта в этой точке.

На самом деле не совсем понятно, что эта фраза означает. Толи объект удалится сам по себе при выходе из слота, толи пользователь должен его удалить. Сегодня фразу в документации поправили:

After the request has finished, it is the responsibility of the user to delete the QNetworkReply object at an appropriate time.

После запроса закончил, это ложится на пользователя, чтобы удалить QNetworkReply объекта в надлежащее время.

Только теперь стало понятным, что указатель должен удалять сам пользователь. Будьте осторожны народ, а то memory leak схватите.

Сообщение отредактировал SABROG - 20.6.2009, 17:29