Bonjour,

Je suis un habitué du C et des MFC. J'ai voulu profiter de l'occasion de développer une petite IHM client pour utiliser QT.
J'ai deux questions :
_ le signal hostFound correspond-il à la résolution d'adresse IP (ie conversion d'un nom "google"->IP ? Je pose la question car lorsque j'entre une adresse IP locale invalide (machine inexistante) je rentre toujours dans cet état.

_ Après contrôle avec wireshark j'ai vu que les octets réseau de ma trame (struct TRAME : 3 int32) étaient envoyés "little endian" (sur mon intel).
Pour l'écriture j'utilise la méthode du parent QIODevice::write() pour reprendre les exemples de la doc QT.

Voici le bout de code :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
	m_stFrame.order = START ;
	// Get parameters and send it to our boy
	m_stFrame.bUsedFixedData = (ui.rbFixedData->isChecked()) ? 1 : 0 ;
	m_stFrame.uiDelay = ui.sbDelayTransmission->value() ;
	bytesToWrite = sizeof(m_stFrame) - m_hostSckt.write((const char*)&m_stFrame, sizeof(m_stFrame)) ;
	if (bytesToWrite == -1)
	{
		on_socketError() ;
	}
Maintenant qu'est-il préférable de faire ?
  • une méthode "convert_frame()" dans ma classe avec des appels à htons()/htonl()
  • Surcharger la classe QDataStream pour définir un opérateur <<(struct TRAME&)


Que pourrait réellement apporter QDataStream dans le cadre de ce développement ? En fait j'hésite à utiliser cette classe car je crains de perdre le contrôle des écritures sur la socket.

Voilà merci pour vos retours d'expérience.

edit : Parfois en articulant nos questions on y trouve des réponses.
Si je surcharge QDataStream avec ma fonction << probablement que j'utiliserai la fonction operator<< ( qint32 i ). Mais ensuite comment est envoyé le message ? Est-ce qu'en procédant ainsi je force l'écriture de plusieurs trames ou les données sont bufferisées ?
S'agit-il d'une écritures synchrone qui peut bloquer mon IHM ?


J'ai encore une autre question :
Pour l'instant j'utilise la méthode write() et un slot pour gérer le signal bytesWritten(qint64 bytes) et écrire le reste des données (reprise de l'exemple QT network dialog

Pourtant dans ce même exemple je trouve l'appel à la fonction QIODevice::bytesToWrite () ce qui me laisse penser que les données à envoyer passées par la fonction write() ont été bufferisées et seront écrites par l'API (ce que je trouve bizarre parce le buffer peut ne récupérer qu'une partie du message si celui-ci est trop grand) . Alors pourquoi refaire des appels à write() pour écrire le restant du message ?