Version imprimable
Bonjour,
Je suis passé de Delphi 7 à Delphi 2007. Mes anciennes applis se compilent sans problème dans le nouvel EDI. Pourtant, dans la fenêtre "Structure", toutes les occurences de "application.processmessages" dans le code sont signalées comme des erreurs.
Quelqu'un aurait-il constaté le même problème ?
Merci.
Il faudrait que tu dois plus précis, puisque tu dis que tes projets compilent sans problèmes, alors qu'appelles-tu "signalé comme une erreur" ?
Toujours est-il que moi je ne recommande jamais l'utilisation de cette fonction à l'origine de bien des problèmes quand mal utilisée (ce qui est souvent le cas).
Dans Delphi 2007, il y a une fenêtre "Structure", par défaut en haut à gauche, qui comporte une rubrique "Erreurs". Quand je charge un programme développé en Delphi 7, une liste de lignes en rouge s'affiche pour chaque "application.processmessages". Mais la compilation s'opère correctement.
Moi aussi je n'utilise cette instruction que modérément. Mais comment faire autrement quand tu attends une réponse d'un port série ou ethernet dans une boucle while lorsque la communication s'est interrompue inopinément ?
Merci pour ta réponse, mais as-tu Delphi 2007 ?
Salut.
Ça serait cool que tu précises (avec un exemple ?), histoire de pas mourir idiot.Citation:
Envoyé par ZZZzzz2
Merci,
--
jp
Non je n'ai pas Delphi2007 mais s'il compile il ne s'agit probablement pas de "vraies erreurs" mais plutôt d'avertissements je suppose.
Avec les canaux de communications, il faut passer par des gestionnaires d'événements. Par exemple ton port COM ou TCP, quel composant utilises-tu ? Normalement ils doivent déclencher des événements (qui sont souvent synchronisés sur la thread principale pour simplifier le développement même si cela peut affecter les performances). Tu ne devrais jamais avoir d'attentes "actives" genre boucle while dans ton code.
Au pire un timer est un moyen d'avoir un pseudo traitement en tâche de fond bien que celle-ci s'execute dans la même thread.
Un exemple :
Imagine une application qui récupère des résultats depuis une BD et que cela puisse être long. Disons que ce traitement s'effectue sur le clique d'un bouton. Afin que ton interface "continue" de répondre à l'utilisateur tu vas générer des appels à "ProcessMessages" tous les 100 appels à "Query.Next". Seulement ton appli. possède d'autres boutons qui récupèrent d'autres résultats depuis la BD, et à cause des appels à 'ProcessMessages" rien n'empêche l'utilisateur de cliquer sur un autre bouton alors que le premier traitement n'est pas terminé : je te laisse deviner les conséquences que cela peut avoir. Plus simplement lorsque tu fais un appel à ProcessMessages il faut que tu t'assures que le code exxcuté résultant ne compromet pas ton traitement actuel en utilisant des données communes.
Citation:
Envoyé par Jipété
Merci, ZZZzzz2
J'utilise Tcomport pour la rs232, et les composants ICS pour tcp. Pour recevoir une réponse, j'utilise une boucle repeat jusqu'à réception de la réponse, ou un dépassement de temps (avec gettickcount). Dans cette boucle, il me faut donc un processmessages (mais lors de l'attente, aucun bouton n'est accessible). Dans le cas de la rs232, il n'y a aucun moyen de savoir si le câble est débranché.
Je prends en compte tes conseils, et utiliser un timer.
Pour l'erreur de processmessages, elle n'est pas bloquante, mais précédée d'un point d'exclamation rouge. Le même code sous Delphi 7 ne produisait pas ce phénomène.
Citation:
Envoyé par Teddy
J'utilise les mêmes composants, avec le TComPort tu as un évenement 'OnRxChar' lorsque tu reçois des données et pour le timeout, tu peux le gérer toi-même par un timer. Le point d'exclamation rouge indique peut-être qu'il s'agit d'une appel "dangereux" ou "non recommandé" (à juste titre à mon avis, j'essai toujours d'éviter son utilisation dans la mesure du possible).