Exec threads etc... Опции

[SABROG]

Эх.. а с блокирующими сокетами было бы всё несколько проще..

Для этого были созданы такие методы:

bool waitForConnected ( int msecs = 30000 )
bool waitForDisconnected ( int msecs = 30000 )
virtual bool waitForReadyRead ( int msecs = 30000 )

Т.е. все блокируется на 30 секунд, а там уже можешь либо повторить попытку, либо пользователю выдать еrror.

[Гость_me_*]

Гость_me_*,
петля событий потоку необходима, если в этом потоке требуется асинхронно выполнять слоты.

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

[SABROG]

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

Соединяй нужные сигналы от QFtp со слотами QThread и выполняй exec() в run(). Все, что будет одти до exec - выполняется один раз при запуске потока, потом exec() входит в "бесконечный" цикл, т.е. возврата из run() не будет до тех пор, пока не будет выход из eventloop, а это произойдет уже при завершении потока. Таким образом все слоты будут обрабатываться не до и не после exec, а во время.

QFtp::list() и прочие команды возвращают свой уникальный ID команды. Можно использовать этот номер, чтобы отслеживать, когда команда завершится. До завершения команды у тебя будут приходить сигналы listInfo(), можно его обрабатывать и заполнять свой список нужным образом, отсортировывая не нужное. В конце придет сигнал commandFinished(int id), IDшник сравниваешь с IDшником возвращенным от list()'a и если это он, то начинаем выкачивать файлы по одному из своего списка. Удаляя выкаченные файлы из списка. На завершение выкаченных файлов тоже будут приходить сигналы со своим id, там ты и будешь удалять из своего списка то, что скачалось. Когда список станет нулевым можно закрыть соединение QFtp::close(), удалить экземпляр QFtp::deleateLater() и завершить поток, т.е. сделать тот самый выход из exec() - quit()/exit(0).

Сообщение отредактировал SABROG - 18.2.2009, 16:14

[Константин]

по всей видимости, тут ещё имеют место проблемы с пониманием асинхронное работы сокетов кутэ.

void MyThread::run()
{
QFtp ftp = new QFtp;
ftp->connectToHost("ftp.trolltech.com");
ftp->login();
ftp->list();
......
ftp->close();
exec();
}

так делать не нужно. тем более, что ftp будет создан в родительском потоке. вызывай exec(), а всю работу с фтп вынеси из run()

[Гость_me_*]

Таким образом все слоты будут обрабатываться не до и не после exec, а во время.

Тоесть начиная с того как был вызван непосредственно exec и мы вошли в event loop и до тех пока не вызовем завершить поток,

т.е. сделать тот самый выход из exec() - quit()/exit(0)

Большое спасибо!!! По этому поводу все вопросы в сущности и были)

[Гость_me_*]

по всей видимости, тут ещё имеют место проблемы с пониманием асинхронное работы сокетов кутэ.

Так оно и есть...

тем более, что ftp будет создан в родительском потоке

Я там торопился... не указатель а просто
QFtp ftp;

Тоесть сделать так:

void MyThread::run()
{
QFtp ftp;
ftp.connectToHost("ftp.trolltech.com");
exec();
}

а дальше уже ловить успешное подключение и действовать дальше ?

[Гость_me_*]

не забыв конечнео же сделать connectы всё какие нужно...

[Гость_me_*]

Классы QHttp и QFtp предоставляют поддержку протоколов HTTP и FTP на клиентской стороне. Так как эти два протокола используются для решении похожих задач, классы QHttp и QFtp имеют много общих особенностей:

* Неблокирующее поведение. QHttp и QFtp асинхронны. Вы можете отправить ряд команд (также называемые "запросы" для HTTP). Команды выполнятся позже, когда управление вернется к циклу событий Qt.
* ID команд. Каждая команда имеет свой уникальный номер ID, который используется для слежения за выполнением команд. Например, QFtp передает сигналы commandStarted() и commandFinished() с ID команды для каждой выполняемой команды. У QHttp тоже имеются подобные сигналы requestStarted() и requestFinished().
* Индикаторы процесса передачи данных. QHttp и QFtp посылают сигналы при передаче данных (QFtp::dataTransferProgress(), QHttp::dataReadProgress() и QHttp::dataSendProgress()). Вы можете соединить данные сигналы, например, с QProgressBar::setProgress() или QProgressDialog::setProgress().
* Поддержка QIODevice. Оба класса поддерживают загрузку в и скачивание из QIODevice, дополнительно к API, основанному на QByteArray.

Есть два основных способа использования QHttp и QFtp. Самый обычный способ состоит в том, чтобы отслеживать ID команд и следить за выполнением каждой команды, соединившись с соответствующим сигналом. Другой способ состоит в том, чтобы запланировать все команды сразу и соединиться только с сигналом done(), который посылается, когда все команды были выполнены. Первый способ требует большего количества работы, но дает больший контроль над выполнением конкретных задач и позволяет вводить дополнительные команды, основанные на результате предыдущих. Что позволяет обеспечить пользователю детализированную обратную связь.

Чёрт, как-то забыл совсем что есть общая статья про сетевое взаиможействие и совсем упустил из виду что тамCC написанно.

[Константин]

а дальше уже ловить успешное подключение и действовать дальше ?

не забыв конечнео же сделать connectы всё какие нужно...

именно. в таком случае при невозможности соединиться (connectToHost) можно выйти и завершить поток, даже не запуская его петлю событий (т.к. вряд ли тебе нужен поток с неподключённым фтп-клиентом)

Сообщение отредактировал Константин - 18.2.2009, 16:49

[Гость_me_*]

Всем спасибо! Тему я думаю на этом закрыть можно..