[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

[Litkevich Yuriy]

Но если поменять местами коннекты,

очень интересное наблюдение.
Они, что асинхронно подключаются? Хм.

[BRE]

Но если поменять местами коннекты,

очень интересное наблюдение.
Они, что асинхронно подключаются? Хм.

Сейчас нет времени проверить, но вроде при конекте, все получатели сигнала заносятся в список и при emit'е вызываются согласно этого списка. Думаю в этом причина.

[SABROG]

В документации о сигналах и слотах написано:

If several slots are connected to one signal, the slots will be executed one after the other, in an arbitrary order, when the signal is emitted.

Но тут я понимаю, один и тот же сигнал и несколько слотов. А вот почему меняется порядок вызовов слотов для двух совершенно разных сигналов - непонятно. Не исключаю, что порядок connect'ов может влиять на ситуацию, но это такое же откладывание существующей проблемы как и show вместо exec. В варианте с QHttp сначала приходил сигнал finished(), а потом сигнал dataReadProgress. Но т.к. сам сигнал информационный и безобидный, то с этим еще как-то можно жить, а вот когда приходит сигнал readyRead и слот пытается записать данные в файл, который уже закрыт и указатель стал уже не валидным, вот тут программа и падает. И виной всему этому, казалось бы безобидный, QProgressBar, который я решил добавить для удобство пользователя. Маленькие причины - большие последствия.

Проверил на Qt 4.6, там ситуация еще хуже. Помимо того, что есть баг с неправильным порядком вызовов слотов, так там с каждым новым скачиванием приходит на 1 больше сигналов finished(). Т.е. если я скачаю файл 10 раз, то в конце скачки десятого раза придет 10 сигналов finished() + последним может прийти сигнал readyRead после них. Тролли молчат второй день, наверно выходные.
---

Моя ошибка, тут каждый раз один и тот же сигнал добавляется к предыдущему:

    void buttonClicked(bool checked = false)
    {
       connect(&netmanager, SIGNAL(finished(QNetworkReply *)),
                this, SLOT(finished(QNetworkReply *)));

Переделал на

connect(reply, SIGNAL(finished()), this, SLOT(finished()))

Но проблема с тем, что слот finished вызывается предпоследним осталась.

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