Bienvenue sur le forum !

Si vous souhaitez rejoindre la communauté, cliquez sur l'un de ces boutons !

Qt 5 : 5.7.1 - Qt Creator : 4.2.0 - Qt Installer : 2.0.3 - JOM : 1.1.2 - Qt Build suite : 1.7.0 - VS Qt 5 : 2.0.0

QProcess et shell de cmd

December 2006 modifié dans Année 2006
Bonjour à tous

je développe actuellement dans le cadre de mes études une ihm pour controler l'execution (point d'arret ) d'un language de programmation développer à cette occasion : un interpreteur du language , compilateur vers un language type ASM (jajacode ) et interpretation du programme compilé (jajacode) . ( pour + d'infos voir http://lifc.univ-fcomte.fr/~bouquet/Enseignement/Compilation/index.html ) .
j'ai developpe une interface de commande pour l'interpreteur minijaja qui permet egalement de réaliser la compilation et une interface de commande pour l'interpreteur jajacode . actuellement je dois interfacer l'interface graphique au interpreteur de commandes la compilation à partir de la ligne de commande marche parfaitement en envoyant dans le QProcess les commandes qui vont bien par contre pour envoyer des commandes à partir d'un QLineEdit depuis l'interface graphique vers l'interpreteur j'ai quelques problemes .. :-(

j'ai un signal qui est envoye du QLineEdit vers cette objet qui envoie les commandes saisies dans la variable MessagesToDebugger. met le programme boucle malgré la vérification de messagestodebugger pour etre certains qu'il
ne soit pas vide et ignore les commandes taper dans l'interface graphique . Comment envoye des QString au QProcess par
un signal ? qui ecrit directement la chaine de caracteres dans le QProcess ?

Voici le code qui concerne cette partie et une capture de l'ihm en piece jointe .
cordialement
// realise la compilation 
bool MjjSh::launchCompiler()
{
emit print(tr("start compiling ")+ mjjSource);
processSh=new QProcess();
connect(processSh, SIGNAL(readyReadStandardOutput()), this, SLOT(slotMessagesDebug()) );
connect(processSh, SIGNAL(readyReadStandardError()), this, SLOT(slotMessagesDebug()) );
setEnvironment(processSh);
processSh->start("./main", QStringList() << QStringList() << "-gui");
if (!processSh->waitForStarted())
return false;
cmdCompilationSh();
writeMessagesToSh();
processSh->closeWriteChannel();
if (!processSh->waitForFinished())
return false;
emit print(tr("compilation ended "));
qDebug() << "Exit code:" << processSh->exitStatus();
return true;
}

bool MjjSh::executeWithDebug()
{
emit print (tr("Running ..."));
processSh=new QProcess();
// connect l'entree et la sortie
connect(processSh, SIGNAL(readyReadStandardOutput()), this, SLOT(slotMessagesDebug()) );
connect(processSh, SIGNAL(readyReadStandardError()), this, SLOT(slotMessagesDebug()) );

setEnvironment(processSh);

processSh->start("./main", QStringList() << QStringList() << "-gui");
if (!processSh->waitForStarted()){
emit print(tr("Failed to start interpreter"));
return false;
}
configureSh();
writeMessagesToSh(); // ecrit une QstringList (MessagesToDebugger) vers le Qprocess

while(processSh->state()== QProcess::Running){ // tant que le processus est lance
processSh->waitForFinished(5); // dormir 5ms
if(messagesToDebugger.empty()== false) //
writeMessagesToSh(); ecrire les commandes dans le QProcess
}
emit print (tr("Interpreter exited"));
return true;
}

// command envoye pour compiler
void MjjSh::cmdCompilationSh()
{
QString name;
slotDebugCommand("ouvrir "+ mjjSource + " \n");
slotDebugCommand("analyser \n");
int pos=mjjSource.lastIndexOf("/");
name=mjjSource.mid(pos+1);
int pos2=name.lastIndexOf(".");
name=name.mid(0,pos2);
slotDebugCommand("compiler " + name + ".jjc \n");
slotDebugCommand("quit\n");
}

Réponses

  • Salut,

    Heuu ..,
    Il manque des parties importantes pour comprendre ton code !
    Ou alors tu n'as pas code ce que tu veux (voudrais) !?

    Tu pourrais essayer de ramener ton code au minimum vital, on y peut etre verra un peu mieux !

    Ludo
  • Euh j'ai deja simplifier au maximum ! c'est la partie qui s'occupe du dialogue avec QProcess
    qu'est ce qui n'est pas comprehensible ?
    je px deposer le code sur un site si ca interesse quelqu'un ?

    merci de m'avoir répondu
  • Je ne comprends pas ton bout de code ?
    Qu'est-ce que la classe MjjSh ? Est-ce qu'elle hérite de QProcess ?

    Si c'est le cas, pourquoi les fonctions ne sont pas dans le run ?

    Le plus simple à mon avis, c'est de créer un slot qui récupère le string tapé par l'utilisateur, avec un sémaphore qui permet d'attendre qu'il y ait quelque chose à traiter (ou une boucle d'attente).

    Mais il manque des bouts de code pour qu'on puisse tout comprendre.
  • Je pense que MjjSh doit etre le shell qu'il a creer pour son langage, d'ailleur dans le constructeur on le voit creer un QProcess, qui tend a prouver que MjjSh n'est pas un QProcess.

    @blobgrinder: montre la parti qui conencte ton lineedit a ton slot qui envoi els données au process.

    P@sNox,
  • December 2006 modifié
    Bah en fait je ne vois pas ou tu ecris dans ton process (surement writeMessagesToSh(), mais y pas le corps de la fonction).

    Si tu veux un exemple de communication avec un QProcess jette un oeil au chef-d'oeuvre d'IrmatDen : http://qtfr.org/doc/tuto/mplayerintegration
    Il communique avec Mplayer, mais le principe est le meme

    Ludo

    -- edit --
    corrige
    au chef-d'oeuvre IrmatDen
    en
    au chef-d'oeuvre d'IrmatDen

    Et ca change tout le sens de la phrase :=)

    -- /edit --
  • Merci de m'aider je vais donc coller les parties qui sont demandees :
    MjjSh est un Thread qui lance le shell et "devrait" le contôler
    morceau du MjjSh.h 
    /*!
    * Class wrapper du shell interactif Mjj
    */
    class MjjSh : public QThread
    {
    Q_OBJECT
    public:
    MjjSh(QObject * parent,QString source, bool exeOnly);
    void run();
    signals:
    void message(QString);
    void print(QString);
    // void endDebug();
    // void onPause();

    protected slots:
    void slotMessagesDebug();
    void slotDebugCommand(QString text);
    // void slotStopDebug();
    // void slotPauseDebug();
    private:
    /* Methode */
    void writeMessagesToSh();
    bool launchCompiler();
    bool executeWithoutDebug();
    void configureSh();
    void cmdCompilationSh();
    void setEnvironment(QProcess *process);

    /* Variables */
    QString mjjSource; // le programme mjj
    bool m_execute; // on execute ou on compile

    QStringList messagesToDebugger; // liste des message à envoye au sh
    QProcess *processSh; // mon processus
    };

    /*! MjjSh est un thread permettant soit d"executer simplement
    du code ou compiler (exeOnly)
    */
    MjjSh::MjjSh(QObject * parent,QString source,bool exeOnly):QThread(parent),mjjSource(source),m_execute(exeOnly)
    {
    connect(parent,SIGNAL(cmdSh(QString)), this,
    SLOT(slotDebugCommand(QString)) );
    // connect(parent, SIGNAL(stopDebug()), this, SLOT(slotStopDebug()) );
    // connect(parent, SIGNAL(pauseDebug()), this,SLOT(slotPauseDebug()) );
    pid = 0;

    }
    void MjjSh::run()
    {
    bool ret;
    if(m_execute)
    ret=executeWithoutDebug();
    else
    launchCompiler();
    if(!ret)
    emit message(tr("Error... :-("));
    QThread::quit();
    }

    /* SLOTS */

    void MjjSh::writeMessagesToSh()
    {
    QStringListIterator it(messagesToDebugger);
    while( it.hasNext() )
    {
    QString msg = it.next();
    qDebug()<< "message:" << msg;
    if(msg != "")
    processSh->write( msg.toLatin1() );
    }
    messagesToDebugger.clear();
    }
    @pasnox : le Widget interpreteur contient le lineEdit et un QtextEdit pour voir ce qui a ete tape mais c'est aussi la sortie de
    Qprocess
    class Interpreteur : public QWidget
    {
    Q_OBJECT

    public:
    Interpreteur(QWidget *parent=0);
    QString mjjFile();
    virtual ~Interpreteur();
    public slots:
    bool printTerm(QString texte);
    bool slotEditToSh(QString string);
    bool slotStartSh(bool executeOnly=false);
    bool compileMjj(QString filename);
    /* socket slot */
    void acceptConnection();
    //void startTransfer();
    //void displayError(QAbstractSocket::SocketError socketError);
    signals:
    // signal a renvoyer à lineedit
    // void newCmd(QString text);
    //signal a envoyer au shell interactif
    void cmdSh(QString text);
    void stopDebug();
    void pauseDebug();
    // signal de validation du cmd(); // une tentative qui ne fonctionne pas
    void valid();
    //void resetExecutedLine();
    private:
    QTextEdit* shellLog;
    QGridLayout *gridlayout;
    QHBoxLayout *hboxlayout;
    QLabel *labelSh;
    LineEditHisto *edit;
    /* ^ widget LineEdit modifie de Qde de Jean-Luc Biord rajoue du signal newCmd(QString) */
    MjjSh *sh;
    QString mjjSourceFile;
    // echane de flux xml avec le shell
    QTcpServer *tcpServer;
    QTcpSocket *tcpServerConnection;
    quint16 blockSize;
    };
    #define JJPORT 6666

    Interpreteur::Interpreteur(QWidget *parent): QWidget(parent)
    {
    ...
    shellLog = new QTextEdit(this);
    shellLog->setObjectName(QString::fromUtf8("shellLog"));
    ....
    edit = new LineEditHisto(this);
    edit->setEnabled(false); // désactive tant que le sh n'est pas lancé
    edit->setObjectName(QString::fromUtf8("edit"));
    ......
    /* connection du lineedit au slot d'edition ds la console de log */
    connect(edit, SIGNAL(newText( QString )), this, SLOT(slotEditToSh(QString)));
    /* socket server */
    tcpServer = new QTcpServer(this);
    }
    Interpreteur::~Interpreteur()
    {}

    /*Affiche sur la console*/
    bool Interpreteur::printTerm(QString texte)
    {
    if(texte != " "){
    shellLog->append(texte);
    qDebug() << "affiche:" << texte;
    }
    }

    /* Execute réellement les cmds */
    bool Interpreteur::slotEditToSh(QString texte)
    {
    shellLog->append(texte);
    // envoie la commande saisie au sh
    qDebug() << "Cmd:" << texte;
    emit cmdSh(texte+"\n");
    }

    bool Interpreteur::slotStartSh(bool executeOnly)
    {
    sh=new MjjSh(this,"test",true);
    // signal d'affichage du sh
    connect(sh,SIGNAL(message(QString)),this,SLOT(slotEditToSh(QString)));
    // signal d'envoi de cmd au sh
    //connect(this,SIGNAL(cmdSh(QString)),sh,SLOT(slotDebugCommand(QString)));
    edit->setEnabled(true);
    sh->start(); // on lance le thread du shell
    return true;
    }

    bool Interpreteur::compileMjj(QString filename)
    {
    QString path,s,name,jjcfile;
    sh=new MjjSh(this,filename,false);
    connect(sh,SIGNAL(message(QString)),this,SLOT(slotEditToSh(QString)));
    connect(sh,SIGNAL(print(QString)),this,SLOT(printTerm(QString)));
    sh->start();
    sh->wait(); // attendre la fin du shell
    int pos=filename.lastIndexOf("/");
    s=filename.mid(pos+1);
    path=filename.mid(0,pos+1);
    int pos2=s.lastIndexOf(".");
    name=s.mid(0,pos2);
    jjcfile=path+name+".jjc";
    if(QFile::exists(jjcfile))
    return true;
    else
    return false;
    }
    Ca y est je crois que j'ai tout mis cette fois ci ^^

    @nikikko : t'a solution m'interesse :
    nikikko said:
    Le plus simple à mon avis, c'est de créer un slot qui récupère le string tapé par l'utilisateur, avec un sémaphore
    qui permet d'attendre qu'il y ait quelque chose à traiter (ou une boucle d'attente).
    j'ai peur que mon thread se finisse avant ? à moins de l'endormir avec un processSh->waitForFinished(-1);
    et on le reveil comment ?

    @lud42fr : au je vais aller voir ça ! merci pour le lien

    Au fait ma classe Interpreteur se comporte maintenant comme un serveur qui receptionne des données durant l'execution etat de la pile et du tas envoye par le shell cette partie fonctionne mais l'application semble freeze des que le shell se connecte ! normal ?
    je dois en faire un thread ? y a t'il un moyen de realiser cela avec des slots/signaux ?

    merci pour vos réponses !

    bonne soirée
  • December 2006 modifié
    Salut,

    Je débarque un peu, mais après avoir relu le thread (mais pas la totalité du code :/), j'ai comme la sensation qu'il y a un gros problème d'archi:
    * MjjSh : je vois pas pourquoi tu en fais un thread?
    * Interpréteur qui se trouve être juste la gestion de saisie et d'affichage et dont tu veux aussi faire un thread à part?

    Les threads ont leur utilité, mais je n'ai pas l'impression que tu en ais besoin, d'après ce que je peut lire ici.
    blobgrinder said:
    j'ai peur que mon thread se finisse avant ? à moins de l'endormir avec un processSh->waitForFinished(-1); et on le reveil comment ?
    Oulala, waitForFinished est faîte pour attendre qu'une application se termine, pas pour la mettre en pause. Avec -1, elle attendra indéfiniment.
    blobgrinder said:
    mais l'application semble freeze des que le shell se connecte
    C'est à dire? Quand tu debug, quelle est la ligne qui fait freezer?

    Edit: Les signaux interthreads ne peuvent s'exécuter que si la boucle d'événement s'exécute, ce que tu ne fais pas. Penses signaux/slots/événements, et pas séquentiel comme un programme en console. Lis ça aussi BTW ;)
  • Salut ,
    IrmatDen said:
    Je débarque un peu, mais après avoir relu le thread (mais pas la totalité du code hmm), j'ai comme la sensation qu'il y a un gros problème d'archi:
    * MjjSh : je vois pas pourquoi tu en fais un thread?
    * Interpréteur qui se trouve être juste la gestion de saisie et d'affichage et dont tu veux aussi faire un thread à part?
    MjjSh est une classe qui permet de controle le shell de commande et Interpreteur est le widget qui affiche la sortie du shell de commande mais permet aussi d'envoyer des commandes au shell par le lineEdit .
    Je crois bien aussi qu'il y a un probleme :-(
    Interpreteur n'a pas besoin d"etre un thread mais MjjSh s'occupe de recevoir et lancer des commandes au QProcess
    c'est inutile d'en faire un thread ?
    IrmatDen said:
    Oulala, waitForFinished est faîte pour attendre qu'une application se termine,
    pas pour la mettre en pause. Avec -1, elle attendra indéfiniment.
    Ok mais comment faire pour que le QProcess recoivent des informations sans qu'il s'arrete tout seul ?
    le shell de commande attend quand on l'execute en console mais pas quand je souhaite le controler dans un QProcess :-(
    IrmatDen said:
    C'est à dire? Quand tu debug, quelle est la ligne qui fait freezer?
    La classe Interpreteur a un attribut QTcpServer pour recevoir du xml du shell de commande .
    Dans mon MjjSh je lance le shell de commande en mode gui , dans ce mode le shell doit m'envoyer un flux Xml par exemple
    l'arbre de syntaxe abstrait ou bien l'etat de la pile. C'est dès que le shell se connecte sur la socket de l'interpreteur freeze
    dès que un signal de connection est reception, de plus dans le shell je recois une chaine de caractère bizarre a cause du QDataStream::Qt_4_0 ? on peut pas utiliser un QTextStream pour envoyer dans la socket ? y a t'il un probleme avec les streams
    vu que le shell a été développé sans Qt mais aussi en C++
    voici la partie du code qui receptionne une connection dans le slot acceptConnection :
      QString Interpreteur::astHeader(void){
    QString astStream="ast.xml";
    QString header((QLatin1String("GET /%1 \r\n")));
    return header.arg(astStream);
    }
    void Interpreteur::acceptConnection(){
    QString block;
    QTextStream out(&block,QIODevice::WriteOnly);
    //out.setVersion(QDataStream::Qt_4_0);
    QString request=astHeader();
    out << request;
    QTcpSocket *clientConnection = tcpServer->nextPendingConnection();
    connect(clientConnection, SIGNAL(disconnected()),
    clientConnection, SLOT(deleteLater()));
    qDebug() << "New Connection" ;
    // clientConnection->write(block); // ne marche pas
    //qDebug() << "Write :"<< out << endl;
    QDataStream in(clientConnection); // reception du flux xml
    if (blockSize == 0) {
    if (clientConnection->bytesAvailable() < (int)sizeof(quint16))
    return;
    in >> blockSize;
    }
    qDebug() << "Reception:"<< in << endl;
    clientConnection->disconnectFromHost();}
    IrmatDen said:
    Edit: Les signaux interthreads ne peuvent s'exécuter que si la boucle d'événement s'exécute, ce que tu ne fais pas. Penses signaux/slots/événements, et pas séquentiel comme un programme en console. Lis ça aussi BTW ;)
    Ah merci je vais lire ca tout de suite !
    bonne journée
  • blobgrinder said:
    MjjSh est une classe qui permet de controle le shell de commande et Interpreteur est le widget qui affiche la sortie du shell de commande mais permet aussi d'envoyer des commandes au shell par le lineEdit .
    Je crois bien aussi qu'il y a un probleme :-(
    Interpreteur n'a pas besoin d"etre un thread mais MjjSh s'occupe de recevoir et lancer des commandes au QProcess
    c'est inutile d'en faire un thread ?
    Non, Interpreteur est du domaine de l'UI donc il n'a pas à être placé dans un thread. Pour MjjSh, QProcess est conçu comme étant basé sur des événements (par le biais des signaux/slots), donc il n'a pas à être dans un thread, sauf cas d'exécution simultanée (et encore, faut voir au cas par cas :))
    blobgrinder said:
    Ok mais comment faire pour que le QProcess recoivent des informations sans qu'il s'arrete tout seul ?
    le shell de commande attend quand on l'execute en console mais pas quand je souhaite le controler dans un QProcess :-(
    Un QProcess ne "s'arrête" que lorsque le process qu'il dirige quitte.
    Peux-tu détailler la différence apportée par l'argument -gui stp (plus que ce que tu dis dessous)? Si tu ne sais pas exactement, que se passe-t-il si tu le lances dans le shell avec cet argument?
    blobgrinder said:
    La classe Interpreteur a un attribut QTcpServer pour recevoir du xml du shell de commande .
    Dans mon MjjSh je lance le shell de commande en mode gui , dans ce mode le shell doit m'envoyer un flux Xml par exemple
    l'arbre de syntaxe abstrait ou bien l'etat de la pile. C'est dès que le shell se connecte sur la socket de l'interpreteur freeze
    dès que un signal de connection est reception, de plus dans le shell je recois une chaine de caractère bizarre a cause du QDataStream::Qt_4_0 ? on peut pas utiliser un QTextStream pour envoyer dans la socket ? y a t'il un probleme avec les streams
    vu que le shell a été développé sans Qt mais aussi en C++
    Tu confirmes que le programme que tu diriges agit en tant que client et non en tant que serveur? @_@
    En général, c'est plutôt l'inverse: le programme fournissant le service agit comme serveur, et ton interface devrait être un client. (Je dis pas que c'est le cas ici, mais c'est vraiment étrange :s .)
    As-tu le protocole réseau à portée de main? Ca aiderait à comprendre le schmilblick.
    A propos des streams, oui, ça peut poser problème. Qt va encoder ce qu'il envoie à sa façon. Donc tu ne peux pas passer par eux; il faut que tu les modifies avant transfert.
    Et pour le freeze, doit-on comprendre que ça crash sur la toute première ligne de acceptConnection()?
    blobgrinder said:
    bonne journée
    Merci, de même ;) (enfin, pour ce qu'il en reste)
  • December 2006 modifié
    IrmatDen said:
    Non, Interpreteur est du domaine de l'UI donc il n'a pas à être placé dans un thread. Pour MjjSh, QProcess est conçu comme étant basé sur des événements (par le biais des signaux/slots), donc il n'a pas à être dans un thread, sauf cas d'exécution simultanée (et encore, faut voir au cas par cas :))
    D'accord je vais essaye sans thread je verrais le resultat
    IrmatDen said:
    [quote=blobgrinder]Ok mais comment faire pour que le QProcess recoivent des informations sans qu'il s'arrete tout seul ? le shell de commande attend quand on l'execute en console mais pas quand je souhaite le controler dans un QProcess :-(
    Un QProcess ne "s'arrête" que lorsque le process qu'il dirige quitte.
    Peux-tu détailler la différence apportée par l'argument -gui stp (plus que ce que tu dis dessous)? Si tu ne sais pas exactement, que se passe-t-il si tu le lances dans le shell avec cet argument?[/quote]
    Si je le lance en ligne de commande, il va vouloir se connecte sur le port JJPORT (6666) si on lui donne des commandes comme
    afficherPile, afficherTas ou afficherASA ( arbre de syntaxe abstraite ) au lieu de l'afficher sur la sortie standard il redirige le flux dans
    un stringstream pour l'ecrire dans la socket c'est tout . J'ai fait un ptit serveur tcp vite fait qui envoie les "requetes" au shell si il n'y a pas
    de serveur le shell va pas aime du tout. les requetes sont type html tres reduit de la forme GET /asa.xml le shell repond
    length=2415\n+flux xml
    IrmatDen said:
    [quote=blobgrinder]La classe Interpreteur a un attribut QTcpServer pour recevoir du xml du shell de commande .
    Dans mon MjjSh je lance le shell de commande en mode gui , dans ce mode le shell doit m'envoyer un flux Xml par exemple
    l'arbre de syntaxe abstrait ou bien l'etat de la pile. C'est dès que le shell se connecte sur la socket de l'interpreteur freeze
    dès que un signal de connection est reception, de plus dans le shell je recois une chaine de caractère bizarre a cause du QDataStream::Qt_4_0 ? on peut pas utiliser un QTextStream pour envoyer dans la socket ? y a t'il un probleme avec les streams
    vu que le shell a été développé sans Qt mais aussi en C++
    Tu confirmes que le programme que tu diriges agit en tant que client et non en tant que serveur? @_@
    En général, c'est plutôt l'inverse: le programme fournissant le service agit comme serveur, et ton interface devrait être un client. (Je dis pas que c'est le cas ici, mais c'est vraiment étrange :s .)
    As-tu le protocole réseau à portée de main? Ca aiderait à comprendre le schmilblick.
    A propos des streams, oui, ça peut poser problème. Qt va encoder ce qu'il envoie à sa façon. Donc tu ne peux pas passer par eux; il faut que tu les modifies avant transfert. Et pour le freeze, doit-on comprendre que ça crash sur la toute première ligne de acceptConnection()?[/quote]
    En effet mon shell est un client et l'ihm est un serveur ! c'est pas commun je confirme :)) je m'en suis rendu compte que c'etait tordu
    mais ca dérange pas trop, m'enfin ca marche pas bien pour l'instant donc ... :-(
    le protocole reseau fonctionne de cette facon :
    - le serveur demande afficherASA : GET /asa.xml
    - le sh parse un minimum la requete envoye
    - le sh envoie Length=[nbre de caracteres du flux]\n et après on envoie le xml
    - le serveur ferme la socket
    pour l'instant mon mini-serveur envoie la requete le client la recoie mais qd je renvoie qq chose de l'autre cote j'ai rien !!! la chaine de caractere est vide et pourtant le nombre de caracteres correspond parfaitement ! ( mystere ... )
    J'ai regarde vite fait et je vois pas comment modifier mes QDataStream::Qt_4_0 avant de les envoye sur la socket , il existe une methode dans cette classe qui va bien ? peut-etre int QDataStream::writeRawData ?
    Quand je dis freeze , c'est juste que le rafraichissment se fait pas pendant environ 10s c'est pas terrible ...

    voila merci de ton aide
  • Pour la première partie, quand je dis d'essayer sans thread, ça inclus s'appuyer sur une méthode non bloquante aussi.

    Le second paragraphe ne répond pas trop, ou alors, je n'ai pas saisi ta réponse. Tu parles que le qprocess s'arrête tout seul en précisant que ce n'est le cas qu'avec l'argument -gui.
    La question est donc pourquoi est-ce qu'il quitte? Est-ce qu'il n'a le droit "d'exister" que pour répondre à 1 et 1 seule requête émise par le serveur??
    A quoi sert son flux d'entrée?

    Ok, je comprends mieux avec freeze dans ce sens là :)
    Comme tu peux le voir, QTcpSocket dérive de QIODevice. Cette dernière propose le signal readyRead(). Tu dois donc connecter ce signal à un slot de ta classe pour lui permettre de lire ce qui est reçu au fur et à mesure. En réseau, les données sont envoyées par paquets dont la taille est le plus souvent fixé par l'OS et les drivers, donc ne t'attend pas à tout recevoir d'un coup :)
    Le mieux étant de stocker tout ce que tu reçois dans un buffer, et seulement lorsque la taille du buffer est celle reçue en début de paquet, alors, tu le traites.
  • Salut,

    J'ai suivi tes conseils et créer un QProcess pour les shells et tout fonctionne à merveille !
    Pour mon problemes de freeze, c'est lié au fait que je faisais un wait() sur le Thread donc normale que ça bloque ....
    Au sujet de mes sockets server j'ai utilisé des QBytesArrays pour des flux XML ca marche très bien ... j'aurais voulu savoir si il y a une
    limite ? je dois envoye un flux xml de ~ 200 000 caractères et ca a fonctionne 1 fois ! ... y a t'il une autre solution sinon le mapper en memoire partage ou bien ecrire un fichier ?

    Cordailement
  • Hello,

    Une limite à quoi? A la taille du QByteArray? Non, si ce n'est ta ram dispo ;)
    Pour mapper en mémoire, y'a pas moyen de faire ça de façon multiplateforme puisque windows ne le propose pas (autant que je sache...). Donc soit tu fais du spécifique Linux, soit tu écris dans un fichier.
  • December 2006 modifié
    Si je peux me permettre 200 000 caracteres, ca ne fait 'que' ~200ko, autant dire rien, pour les machines actuelles !
    A mon avis ton probleme est ailleurs !

    Ludo

    -- edit --
    Le double en unicode ;)
    -- /edit --

    -- edit 2--
    A mon avis ton probleme sera ailleurs !
    @IrmatDen :P
    -- /edit 2 --
  • Ben, ça marche bien :P
    Il ne faisait que se renseigner ce coup-ci :D (et c'est bien)
Connectez-vous ou Inscrivez-vous pour répondre.