Discussion :

[hodhodeni]

Bonjour,
j'ai une application qui s'initialise à partir d'un fichier situé sur le net, alors je veux rendre la requête get que j'utilise pour télécharger ce fichier bloquante.
est ce que quelqu'un a une idée comment je peux faire ça?
merci
ps: j'utilise la classe QNetworkAccessManager.

[cayou66]

Salut,

Tu peux malgré tout créer ton slot qui éxécutera la suite de ton code de traitement, et le connecter à ce fameux signal de fin de requête GET. Regardes la doc pour retrouver le signal.

[nouknouk]

Salut,

L'idée de bloquer l'application ne me paraît quand même pas idéale. D'autant plus, qu'il me semble que les versions précédentes des QTcpSocket utilisent le boucle d'événements (QEventLoop) pour fonctionner (à vérifier que c'est toujours le cas). Si tu bloques le thread principal pour attendre l'événement, tu vas également bloquer l'event loop et donc ne jamais recevoir de notification comme quoi ton GET s'est terminé.

Pourquoi ne pas plutôt afficher une boite de dialogue modale le temps de récupérer le fichier ?

Ca te donnera l'assurance que l'utilisateur ne pourra pas intéragir avec l'interface tant que ton GET n'est pas terminé et ça évitera le freeze de ton application (jamais bien perçue par l'utilisateur final).

[hodhodeni]

L'idée de bloquer l'application ne me paraît quand même pas idéale... ça évitera le freeze de ton application (jamais bien perçue par l'utilisateur final).

c vrai, mais, j'aurais besoin d'attendre d'autre signaux au cours de l'exécution de mon application, donc je suis obligé de la bloquer!

->cayou66
Merci le lien m'a été très utile.

[nouknouk]

je suis obligé de la bloquer

Non, tu peux toujours implémenter un petit objet qui écoute plusieurs signaux et qui pourra retourner un état (genre un booléen everythingLoaded = true ou false), voir émettre un signal quand tous les signaux voulus auront été reçus.

Après tout dépend de tes signaux, de ce que tu attends et des besoins de ton appli, mais on peut toujours trouver une solution pour ne pas bloquer le thread prinicpal de l'appli.

[cayou66]

Tu peux toujours lancer ton get, et faire le reste de ton programme dans un slot relié à

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
void QNetworkAccessManager::finished ( QNetworkReply * reply )   [signal]

non?

[LittleWhite]

Je pensais à une solution plus simple ( enfin je crois )

Utiliser un booleen, faux, lorsque vous envoyez la requete.
Faire une animation d'attente ( une boucle :p ).
Lorsque la requete est fini, le signal requestFinished est envoyé... on connect un slot dessus, et dans ce slot on change la valeur du booléen pour débloquer la boucle. Et hop on continu le programme.

[cayou66]

Pour faire un truc plus sympa, histoire de, une petite barre de chargement pendant la boucle. J'ai vu plusieurs fois des personnes qui demandaient comment récupérer un % entre 0 et 100 sur une requête lorsqu'un fichier est téléchargé. Il existe peut être une fonctione dans le pack Network pour faire ce genre de chose.

[nouknouk]

Faire une animation d'attente ( une boucle :p ).

Ca revient à faire une attente bloquante puisque la fonction dans laquelle la boulce se trouvera ne retournera pas tant que le download n'est pas fini.

Pour rappel, le principe de fonctionnement de base de Qt est basé sur un paradigme d'événementiel, donc:

- n'importe quel slot ou fonction appelée lorsqu'un événement survient doit retourner le plus rapidement possible.

- si on a des traitements qui prennent du temps (genre gros calcul), on créé un thread séparé, et on attend la notification de 'fin de calcul' via un signal. En attendant, le thread principal qui aura créé le thread aura déjà fini son exécution et aura continué à faire tourner l'event loop.

- si on a du traitement en réseau avec une action type "j'envoie une requête ; j'attends la réponse pour en faire quelque chose", idem car la réponse pourra mettre du temps avant d'arriver complètement (réseau lent, gros download, petit débit, ...). Donc on envoie la requête et on attend l'émission d'un signal pour prévenir que la réponse est arrivée.

Pour faire un truc plus sympa, histoire de, une petite barre de chargement pendant la boucle. J'ai vu plusieurs fois des personnes qui demandaient comment récupérer un % entre 0 et 100 sur une requête lorsqu'un fichier est téléchargé. Il existe peut être une fonctione dans le pack Network pour faire ce genre de chose.

oui, ça existe, mais évidemment ça n'est pertinent que quand la réponse aura une taille relativement importante (ie. genre un download ; pas un simple GET sur une page html). Dans l'idée:

- on intancie note QNetworkManager.

- on fait un 'GET' avec QNetworkAccessManager::get

- celui-ci nous retourne immédiatement l'instance de QNetworkReply qui contiendra à terme la réponse à la requête

- on peut se connecter au signal QNetworkReply::downloadProgress(qint64 bytesReceived, qint64 bytesTotal) qui va être régulièrement émis au fur et à mesure de l'avancement du download.

- on peut alors mettre à jour une QProgressBar par exemple, avec setMinimum(0) ; setMaximum(bytesTotal) et setValue(bytesReceived)

[cayou66]

Exactement

[LittleWhite]

Je suis entièrement d'accord avec vous nouknouk, mais ( car il y a un mais ), dans le cas d'une application, qui pour démarré doit avoir la réponse ( un fichier ) à partir d'un cerveur, que sans lui, l'application ne peut rien afficher ( car le but de l'application est d'afficher ce fichier ) que faire ?

[nouknouk]

Comment font les applications qui mettent du temps à s'initialiser d'habitude (Visual Studio, NetBeans, Eclipse, Photoshop, ...) ?
Elles utilisent toutes un écran de démarrage, éventuellement avec une barre de progression.

Ca permet à l'utilisateur d'avoir le feedback que le programme est bien en train de se lancer. Car si le GET dure plusieurs secondes et que rien ne s'affiche, l'utilisateur pourrait croire que l'appli ne s'est pas lancée ... et tente de la lancer à nouveau.

Et ça tombe bien: Qt a tout ce qu'il faut, tout cuit, pour ça: QSplashScreen

L'idéal (amha) est celui avec une barre de progression ET une ligne texte de status pour dire ce que l'appli est en train de faire.
Perso, j'aime assez le conept général du splash screen de KDE : il associe une ligne de status avec des icônes qui passent petit à petit de transparent à opaque:



Mais bon, après, les goûts les couleurs, toussa ...

[LittleWhite]

Finalement, on reviens à ce qui a été dit avant ... et que j'avais cru que vous n'aimiez pas. Une barre de chargement ( et donc aussi une boucle )

( J'aime bien aussi le chargement de KDE )

[nouknouk]

que j'avais cru que vous n'aimiez pas. Une barre de chargement ( et donc aussi une boucle )

Je me rends compte que mon post n'était pas clair : la barre de chargement, je n'ai absolument rien contre (au contraire !), ce que je "n'aimais pas" (et je continue), c'est la notion de 'boucle'.

Comme dit dans le post précédent, il y a d'autres moyens pour afficher une fenêtre, un splash-screen ou n'importe quoi d'autre qu'une boucle qui bloquerait le programme (cf. post précédent).

Donc pour résumer:
- le splash screen, je suis à 300% pour
- la boucle d'attente ou quoi que ce soit d'autre qui serait 'bloquant' : c'est à éviter.

[LittleWhite]

Je suis d'accord avec vous ( c'est déjà bien ). Mais le problème, c'est qu'une barre d'attente ( ou autre ) revient à être une boucle ( une boucle qui rafraichit la fenetre d'attente ).
Mais dans tout les cas, ça fait parti d'une période d'attente.