Bonjour, depuis que j'ai commencé à utiliser le language c# il y a un an déjà, j'ai remarqué que mon seul programme que je développe depuis est de plus en plus long, malgré que je n'utilise pas des commandes ou un code compliqué, l'idée est de prendre des valeurs depuis un microcontroleur un Arduino par exemple, les afficher dans une fenêtre, et de bouger le curseur en utilisant un joystick par exemple, aujourd'hui j'ai changer l'arduino en en un autre microcontroleur plus puissant le STM32 et là mon ordinateur n'arrive plus à suivre le flux des données.
Avant j'avais ce même problème avec l'arduino mais j'ai réussi à le résoudre en utilisant un Thread même si jusqu'à ce moment je ne sais pas comment ça marche exactement, et l'idée d'utiliser plusieurs est hors de ma portée à cause des interférences.
En tout cas, avant d'analyser en profondeur le code j'aimerai utiliser les pointeurs car je pense que la lecture et l'écriture des données se fait sur le SSD au lieu de la RAM, mais en cherchant un peu sur le net, j'ai trouvé que le language c# et les pointeurs ne sont pas vraiment des amis d'après ce que j'ai compris, donc ma question est comment je peux accéder aux cases mémoire de mes variables en utilisant un pointeur ou un truc équivalent.
Voici la classe que j'utilise:
class Accelerometer
{
public int[] ac = new int[3], gy = new int[3];
public static int Filter(string serial)
{
int value;
serial = serial.Remove(0, 1);
if (int.TryParse(serial, out value))
{
value = int.Parse(serial);
}
return value;
}
}
"C'est un coup du sort étrange : tout les hommes dont on a ouvert le crâne avaient un cerveau" . Wittgenstein.
> là mon ordinateur n'arrive plus à suivre le flux des données.
C'est que vous avez merdé quelque part.
Un ordinateur "moderne" peut écouter dans problème un flux plein gaz sur un port série (dont le débit maximal est plafonné très très bas).
Quel est la charge CPU quand votre programme tourne ?
>j'ai réussi à le résoudre en utilisant un Thread
Solution à moindre cout, si le problème n'était que l'utilisation d'une IHM bloquante, mais c'est pas une "Silver Bullet".
>même si jusqu'à ce moment je ne sais pas comment ça marche exactement
C'est pas bien.
>hors de ma portée à cause des interférences
Les threads, c'est pas des ondes. On parle de "concurrence".
>En tout cas, avant d'analyser en profondeur le code j'aimerai utiliser les pointeurs
Les pointeurs n'existent pas en C# et cela n'a jamais été une "Silver Bullet" dans n'importe lequel des langages qui les supportent.
Commencez par le commencement, analyses les performances et goulots d'étranglement de votre application avant de choisir un "grigris" au pif en espérant un miracle à base de sang de poulet un jour de plein lune dans un pentacle fait à des cendres d'os de licorne.
>car je pense que la lecture et l'écriture des données se fait sur le SSD au lieu de la RAM
Arrêtez de penser, mesurez !!!
(hypothèse complètement farfelue)
Regardez pourquoi votre thread block ailleurs qu'au moment de la lecture sur le port série.
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
J'en ai aucune formation en développement, à part un peu en c/c++ donc je ne connais pas les mots technique ni comment exprimer convenablement mon problème, et oui je veux dire lent, mon application prend environ 48% de mon CPU et la boucle infinie dans la quelle se trouve mon programme principal s'éxecute environ 550 fois par seconde (sur l'arduino 150 fois par seconde), sinon quel outil je peux utiliser pour diagnostiquer les différents suspects :p.
"C'est un coup du sort étrange : tout les hommes dont on a ouvert le crâne avaient un cerveau" . Wittgenstein.
Bon j'ai réussi à optimiser le code un peu plus, au lieu de 550 fois par seconde j'ai atteint les 930 voire plus (tout en gardant les mêmes porgrammes en arrière plan), mais le temps de réponse du PC est encrore lent par rapport au microcontroleur, je pense que je peux faire mieux en utilisant des variables unsigned et en fixant un nombre de caractère précis lors de la réception des données.
"C'est un coup du sort étrange : tout les hommes dont on a ouvert le crâne avaient un cerveau" . Wittgenstein.
J'ai un microcontroleur qui envoie des données vers l'ordinateur de ce type:
"a123"
"b456"
"c789"
et rebelote...
Les lettres a,b et c sont les signatures de chaque capteur, c'est juste pour répondre à cette question: cette donnée provient de quel capteur?
puis l'ordinateur enlève la lettre et stock le reste dans une variable de type int, et en fonction de la valeur je peux faire bouger le curseur par exemple, jusqu'à le moment c'est ça le processus, mais je compte ajouter plusieurs capteurs et plusieurs fonctions dans le futur et d'après ma petite expérience il m'est impossible de continuer si je trouve pas une solution à ce niveau, la seule chose qui a résolu mon problème est de réduire le flux de données depuis le microcontroleur mais ça reste uen solution temporaire car j'aurai besoin de toute la bande passante un jour.
Les fonctions de collecte de données ainsi du mouvement du curseur ont besoin d'une boucle infinie pour fonctionner sinon y a-t-il une autre méthode ?
"C'est un coup du sort étrange : tout les hommes dont on a ouvert le crâne avaient un cerveau" . Wittgenstein.
On parle pas de boucle infinie (qui est aussi une connerie au passage, car il faut toujours une condition de sortie), on parle d'une boucle active.
(Ooups @galactose a fourché )
Si votre boucle "infinie" attend juste des entrés sur les ports séries, elle est bloquée au minimum 99% du temps. C'est pas ça qui prend les cycles CPU, à moins d'avoir utilisé n'importe comment des primitives non bloquantes.
Vous êtes sûr que c'est pas vos routines de "faire bouger le curseur" qui bouclent n'importe comment ?
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
Mon code contient 3 boucles en série, une boucle active et deux boucles de vérifications:
private void loop()
{
while (true)
{
do
{
do
{
serial = null;
serial = MCU.ReadLine();
} while (serial.Length != 4); // boucle de vérification N1 "a123"
switch (Convert.ToChar(serial.Substring(0, 1)))
{
case 'a':
cap_1 = (int) serial;
cap[0] = true ;
break;
case 'b':
cap_2 = (int) serial;
cap[1] = true ;
break;
}
}while (checking(cap)); // boucle de vérification N2
}
/* code */
}
Au début nous avons notre boucle active, ensuite on passe vers la boucle de vérification numéro 1, cette boucle assure que la longueur de la chaine de caractères est 4, car parfois (99% des cas) au lieu de recevoir par exemple "a123" je reçois "a123\n", "9a123b"...et plein d'autres combinaisons ce qui n'est pas cool au moment de la conversion de string vers int, d'habitude j'utilise le TryParse mais hier je l'ai enlevé en utilisant cette méthode avec des variables unsigned et ça marche.
La deuxième boucle de vérification consiste à vérifier la totalité des données, je m'explique le microcontroleur envoie une seule donnée à la fois alors pour bouger le curseur j'en ai besoin de deux données (axe x et y) donc pour s'assurer que mon code utilise toujours de nouvelles données j'ai ajouté un tableau booléan que j'ai nommé "cap" et une fonction "checking" qui renvoie "false" si tout les cases du tableau sont "true".
Je pense d'après ce que j'ai compris que le problème est situé à la première boucle de vérification, si c'est le cas alors comment je peux faire mieux ?
- Edité par Vertinhol 26 février 2020 à 15:46:53
"C'est un coup du sort étrange : tout les hommes dont on a ouvert le crâne avaient un cerveau" . Wittgenstein.
On va laisser tomber les lignes 13 à 23 qui sont truffés de bugs à chaque ligne. Clairement, les performances, avec un truc aussi bogué, c'est vraiment dérisoire. VIREZ-moi ces cast et faites correctement les choses !!!
>d'habitude j'utilise le TryParse
Et bien faites !!!
>mais hier je l'ai enlevé en utilisant cette méthode avec des variables unsigned et ça marche.
Comme un poulet sans tête, virez-moi cette horreur !!!
Ligne 3, pas de commentaire, virez-moi cette cochonnerie, au moins avec un truc qui permet au thread principal de piloter de thread de travail complètement zinzin.
Ligne 5 et 25, utilisation de données partagées en thread sans précautions, on est bon pour un complètement quasi-aléatoire.
Ligne 9, elle dégage.
Bon, vous n'avez absolument rien compris au multi-threading. Je vous conseille donc de ne plus vous en servir avant d'avoir compris comment ça marche et de vous rabattre sur de l'évènementiel/asynchrone, moins casse-gueule pour vous.
Vous êtes bien gentil, mais tout ce que vous faites ici, doit l'être de manière très spécifique dés qu'on fait du multi-thread, et comme vous ne le mentionnez pas, ça pue les emmerdes.
- Edité par bacelar 27 février 2020 à 17:38:51
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
En enlevant le TryParse j'ai remarqué une augmentation en performance donc je ne vois pas pourquoi je dois l'utiliser tant que je peux gérer les exceptions.
"C'est un coup du sort étrange : tout les hommes dont on a ouvert le crâne avaient un cerveau" . Wittgenstein.
Si vous n'avez qu'un thread, votre boucle ACTIVE est alors dans le thread de votre IHM et est donc complètement freezée.
Je pense que vous n'êtes pas si à l'Ouest pour avoir freezé votre IHM avec cette boucle, que vous supputez active (il y a beaucoup de chance que vous n'avez pas correctement analysé votre programme à la vue des contre-vérités et autres énormités que vous assénez). Vous avez donc très vraisemblablement 2 thread, au moins, donc vous faites, très probablement, du multi-threading (et comme un gros cochon!).
Et, en regardant les codes que vous postez, elle fait quoi dans votre code cette ligne ? :
main.Start();
Vous faites peut-être du multi-treading comme Mr Jourdain fait de la Prose, mais lui n'est pas si obtus. Et en faisant du multi-threading, il faut un minimum de connaissance que vous ne semblez pas avoir (concurrence d'accès aux variable, caching des valeurs, etc...)
>j'ai un seul thread en plus la méthode écrite dans l'exemple de Microsoft est TROP TROP LENTE.
Je suppose qu'il manque un point, non ?
donc : "j'ai un seul thread" répondu avant.
>En plus la méthode écrite dans l'exemple de Microsoft est TROP TROP LENTE.
LOL, PTDR, MDR, ....
long epoch = 1000000l;
int res;
Stopwatch stopWatch = new Stopwatch();
stopWatch.Start();
for (long i = 0; i < epoch; i++) { int.TryParse("1234", out res); }
stopWatch.Stop();
Console.WriteLine("Temps moyen d'un TryParse en secondes : " + stopWatch.Elapsed.TotalSeconds / epoch);
Code fait à l'arrache, sans aucune optimisation.
Ça donne sur un W7 CPU i7-2600 à 3.40GHz super chargé de la mort (décompilation de plusieurs milliers d'assemblies .NET):
Temps moyen d'un TryParse en secondes : 1,019532E-07
115 200 bits/s => 14400 o/s Ce qui donne un temps de traitement de 0,00146812608 second pour le traitement de tout le flux d'une seconde de port série.
En résumé, vous pouvez coller plus de 500 ports séries au cul, c'est pas ce truc qui fera perdre le moindre octet.
Faites-moi voir un code de parsing QUI FONCTIONNE, qu'on compare les performances de chacun.
Je ne sais pas quel sombre option ou quel classe vous utilisez pour lire les données sur le port série, car votre code ne compile même pas chez moi.
>En enlevant le TryParse j'ai remarqué une augmentation en performance
Et ? Si le résultat est faux, ça nous fait une belle jambe.
>donc je ne vois pas pourquoi je dois l'utiliser
Pour avoir un résultat "correct", ça peut servir.
>tant que je peux gérer les exceptions.
Vu le coup de la moindre exception, vos performance seront RIDICULES par rapport à TryParse.
En plus, il n'y aucune gestion d'exception dans
Le Framework .NET vous facilite la manière de bien utiliser l'API (c'est de l'affordance) alors pourquoi faire des usines à gaz totalement boguées aux performances totalement dans les pâquerettes ?
Votre dernier code ne fait pas le travail de décodage des données transmises mais se plombe les performances avec des appels à la console.
Vous cherchez à vous décrédibilisez totalement à chaque fois que vous parlez de "performance" ???
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
J'ai moodifié certaines parties du code quand j'ai commencé cette discussion dans le but de simplifier la compréhension, sinon voici la totalité ou presque car le reste n'a aucun impact sur le truc, c'est juste des fonctions qui s'éxecutent quand je fais appel à eux.
private void loop()
{
while (check_connection)
{
do
{
do
{
serial = null;
serial = MCU.ReadLine();
} while (serial.Length != 6);
switch (Convert.ToChar(serial.Substring(0, 1)))
{
case 'a':
AC_1.ac[0] = Accelerometer.Filter(serial);
AC_1.flag[0] = true;
this.Invoke((MethodInvoker)delegate { display(AC_1.ac[0], ax1, "ax: "); });
break;
case 'b':
AC_1.ac[1] = Accelerometer.Filter(serial);
AC_1.flag[1] = true;
this.Invoke((MethodInvoker)delegate { display(AC_1.ac[1], ay1, "ay: "); });
break;
case 'c':
AC_1.ac[2] = Accelerometer.Filter(serial);
AC_1.flag[2] = true;
this.Invoke((MethodInvoker)delegate { display(AC_1.ac[2], az1, "az: "); });
break;
case 'd':
AC_1.gy[0] = Accelerometer.Filter(serial);
AC_1.flag[3] = true;
this.Invoke((MethodInvoker)delegate { display(AC_1.gy[0], gx1, "gx: "); });
break;
case 'e':
AC_1.gy[1] = Accelerometer.Filter(serial);
AC_1.flag[4] = true;
this.Invoke((MethodInvoker)delegate { display(AC_1.gy[1], gy1, "gy: "); });
break;
case 'f':
AC_1.gy[2] = Accelerometer.Filter(serial);
AC_1.flag[5] = true;
this.Invoke((MethodInvoker)delegate { display(AC_1.gy[2], gz1, "gz: "); });
break;
}
} while (checking(AC_1.flag));
for (int i = 0; i < 6; i++)
{
AC_1.flag[i] = false;
}
cursor(AC_1.gy[0], AC_1.gy[1], Cx_2);
}
}
Ici j'utilise deux fonctions "cursor" et "display", la première pour bouger le curseur et la seconde pour afficher les valeurs dans une fenêtre
private void display(double n, Label label, string name)
{
label.Text = name + n.ToString();
}
private void cursor(int x, int y, int C)
{
int Sensibility = 50, edge = 1000;
if (x > C + edge)
{
Cursor.Position = new Point(Cursor.Position.X + x / Sensibility, Cursor.Position.Y);
}
else if (x < C - edge)
{
Cursor.Position = new Point(Cursor.Position.X + x / Sensibility, Cursor.Position.Y);
}
if (y < C - edge)
{
Cursor.Position = new Point(Cursor.Position.X, Cursor.Position.Y + y / Sensibility);
}
else if (y > C + edge)
{
Cursor.Position = new Point(Cursor.Position.X, Cursor.Position.Y + y / Sensibility);
}
}
et enfin j'ai une classe "Accelerometer" :
class Accelerometer
{
public int[] ac = new int[3], gy = new int[3];
public bool[] flag = new bool[6];
public static int Filter(string serial)
{
int value = Convert.ToUInt16(serial.Remove(0, 1));
return value;
}
}
ah oui j'ai oublié, la variable "check_connection" est de type bool, elle prend la valeur TRUE quand je clique sur un bouton et la fonction "checking" renvoie FALSE si tout les valeurs du tableau sont TRUE.
private void Start_Click(object sender, EventArgs e)
{
main = new Thread(new ThreadStart(this.loop));
main.IsBackground = true;
main.Start();
}
"main" est le nom de mon puissant Thread !
- Edité par Vertinhol 4 mars 2020 à 16:38:56
"C'est un coup du sort étrange : tout les hommes dont on a ouvert le crâne avaient un cerveau" . Wittgenstein.
Je prend la discutions au fil de l'eau mais si tu cherches juste à traiter à chaque fois les infos que t'envoie l'arduino (150 fois / seconde ) pourquoi ne pas utiliser le design pattern Observer ?
ça t'évite de faire des boucles en plus pour rien.
J'espère que maintenant vous voyez le problème du partage de données entre thread.
Mais vous enquiquinez pas, votre "mon puissant Thread" devrait dégagé.
Votre classe "Accelerometer" est très mal conçue.
Cela entraine un "switch" des enfers que des Design Pattern comme "Factory" et l'utilisation d'un dictionnaire à la place des horribles tableaux rendrait bien plus lisible (et aussi bien plus flexible).
Mais bon, je ne sais pas si c'est votre boucle active mais il y a bien au moins 7 lignes qui font que ce machin va ramer ça mère.
Les lignes 18, 23, 28, 33, 38 et 43, et la ligne 54 avec l'appel à "cursor" qui est différentes des 6 premières.
Les lignes "Invoke" implique un changement de contexte d'exécution ("this" étant le formulaire, je suppose).
Opération très couteuse en elle-même, synchrone, donc bloqué tant que l'IHM n'est pas disponible, et obligatoire car le thread qui a créé le formulaire n'est pas le thread courant.
En utilisant l'approche "DataReceivedHandler", vous ne swichez quasiment jamais de contexte, voir jamais avec les bons contextes de synchronisation (je crois que c'est 0% de switch de contexte avec la configuration par défaut de WinForm).
Pour ce qui est de la méthode "cursor", j'aurais jamais l'appeler depuis un contexte non graphique de peur de me prendre une exception venant du GDI qui ne supporte pas le multi-threading. Il y a peut-être une protection dans le Framework .NET pour éviter cela, mais elle n'est surement pas gratuite.
Je ne vous pas ce que vous reprochez à l'approche "DataReceivedHandler", qui est bien plus simple et bien plus performante que votre bricolage.
EDIT: très bonne remarque de @Flingouin, maintenant, il faudrait que le PO est le courage de faire un Model ou un ViewModel pour que ce DataBinding soit maintenable.
- Edité par bacelar 4 mars 2020 à 18:20:07
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
Bon il me faut du temps pour assimiler tout ça xD, je voulais ajouter le fait que j'ai déjà mis en commentaire les lignes de la fonction "display", donc pas de Invoke mais ça ne change rien de point de vu performance.
En tout cas pouvez-vous svp me donner un petit exemple d'une fonction qui reçoit activement des données d'un port COM et les stocks dans une valeur, pour le reste je peux me débrouiller (enfin je pense).
"C'est un coup du sort étrange : tout les hommes dont on a ouvert le crâne avaient un cerveau" . Wittgenstein.
non mais comme je l'ai déjà essayé sans avoir de bons résultats je me suis dit que je l'ai mal implémenté, ne plus je ne sais pas comment je peu copier un projet c# en .NET, ce n'est pas la même structure.
"C'est un coup du sort étrange : tout les hommes dont on a ouvert le crâne avaient un cerveau" . Wittgenstein.
Attends xD je pense que je viens de découvrir un truc, dans un projet .NET mes fonctions doivent être dans le fichier Program.cs ou Form1.cs ?
Parce que j'ai cru que la fonction main() existe seulement dans un projet c# (sans graphique) et non pas .NET, peut être aussi que c'est ça le problème.
"C'est un coup du sort étrange : tout les hommes dont on a ouvert le crâne avaient un cerveau" . Wittgenstein.
>dans un projet .NET mes fonctions doivent être dans le fichier Program.cs ou Form1.cs ?
Bin, déjà, faudrait qu'il y ait un Form1.cs, ce qui n'est le cas QUE dans des projets Winform.
Et pour le Program.cs, il peut s'appeler comme il veut, c'est pas ça l'important.
Il faut juste qu'il existe une méthode static avec les bons attributs .NET (fonction du type de projet) et que la configuration du projet l'indique comme point d'entrée du programme.
>Parce que j'ai cru que la fonction main() existe seulement dans un projet c#
Tout programme à un point d'entrée, qu'il soit .NET ou pas, qu'il soit écrit en C# ou pas.
Je ne vois pas trop le rapport avec le problème initial.
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
Bon, pour moi il y a beaucoup d'incompatibilité entre ce qu'il y a dans le site de Microsoft et ce que je cherche à faire.
Tout d'abord il n'y a pas de boucle active dans l'exemple, j'ai déjà essayé de mettre l'appel de la fonction "DataReceivedHandler" dans une boucle active et le résultat était catastrophique (performance nulle).
Deuxièmement je ne peux pas mettre la fonction dans le fichier Program.cs car je dois recréer un autre port COM vu que Form1.cs [Design] qui contient déjà un port COM configuré, n'est pas visible par Programe.cs et je pense que si je reconfigure un port comme dans l'exemple alors les données que je reçois ne seront visible que par Program.cs hors je veux les afficher dans une fenêtre qui se trouve dans le fichier Form.
RayaneStaszewski a écrit:
Tes fonctions peuvent être dans tous les fichiers, mais le fichier program est fait pour lancer le logiciel et non pas pour accueillir des fonctions !
Et je te conseille de très vite basculer sur WPF, car winform est très vieux et mal optimiser !
Je n'ai même pas réussi à faire un truc qui marche convenablement sur .NET alors sur WPF ça va être chaud, j'aimerai au moins comprendre mes erreurs avant de passer à autre choses.
"C'est un coup du sort étrange : tout les hommes dont on a ouvert le crâne avaient un cerveau" . Wittgenstein.
Bon, bin déjà, IL FAUT ÉVITER LES BOUCLES ACTIVES.
Alors quand vous critiquez le code de M$ pour un problème de performance, ce qui peut être possible car c'est des exemples à but pédagogique, mais que vous en êtes encore à chercher cette putain de cochonnerie de boucle active, vous n'êtes pas crédible sur cette critique de performance.
Comment pouvez-vous ne serait qu'évaluer la pertinence de vos mesure quand vous collez un appel inter-thread toutes les 3 lignes ?
Franchement, à chaque fois que vous parlez de performance, je me dis "Quelles conneries il a fait avec les API pour se plomber lui-même les performances, si on fait l'assertion qu'il c'est ce qu'est la 'performance' ?".
No-offence, mais je veux bien plus que vos dire pour juger que l'approche "DataReceivedHandler" n'a pas les performances nécessaires.
Donc, en l’absence du code qui vous permet de dire "performance nulle", je fais l'assertion que c'est vous qui faites nimportnawak.
Votre code d'illustration de "performance nulle", SVP.
>je ne peux pas mettre la fonction dans le fichier Program.cs
Et on vous ne demande pas de le faire. Qu'est-ce qui vous empêche de mettre ce code dans un "Form" ???
>je pense que si je reconfigure un port comme dans l'exemple alors
Non, mais, reprenez les bases. Dans l'exemple, ce n'est pas une "reconfiguration" d'un port, c'est juste le code minimal pour que l'exemple tourne dans un projet console (le plus simple). Si vous faites cette configuration dans votre Form, tant mieux, ajoutez le code d'utilisation de "DataReceivedHandler" à ce niveau. Pas la peine de ce prendre la tête sur de faux problèmes.
>les données que je reçois ne seront visible que par Program.cs
De quelle "visibilité" parlez-vous ??? Si vous configurez "DataReceivedHandler" correctement, vous aurez accès à tous ce qui est nécessaire. Comme c'est vous qui implémentez ce handler, vous avez toute liberté pour rendre visible tout et n'importe quoi.
Vous n'avez vraiment pas cherchez à comprendre comment ça s'utilise pour dire autant d'énormités.
Je conviens que si on ne connait pas les delegate/event/..., comprendre comment cela marche n'est pas trivial, mais vous n'êtes pas obligé de comprendre toute la mécanique derrière pour vous en servir, au moins dans un premier temps. Et critiquer les performances quand on voit que vous n'avez même pas cherché à vous en servir, ça devient risible.
>hors je veux les afficher dans une fenêtre qui se trouve dans le fichier Form
C'est pour ça que je vous ait indiqué de l'utilisez dans une Form, si c'est plus pratique pour vous.
>Je n'ai même pas réussi à faire un truc qui marche convenablement sur .NET alors sur WPF ça va être chaud
Je suis d'accord avec vous, si vous n'avez pas les bases, en WPF, ça va être catastrophique (structuration bien plus stricte pour tirer partie de tous les avantages de WPF)
>j'aimerai au moins comprendre mes erreurs avant de passer à autre choses.
Le plus importante, c'est que vous ne cherchez pas trop à comprendre. Faites le cas le plus simple, faites la configuration de votre "DataReceivedHandler" dans le OnLoad de votre formulaire.
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
Je voulais refaire le code en WPF juste pour voir ce que ça donne comme résultat, et en essayant d'ajuster les changements nécessaire entre les deux Framework (.NET et WPF) si c'est ça le nom technique, j'ai eu quelques questions qui peuvent m'aider dans le futur:
Pourquoi est-ce que j'aurai besoin d'afficher les valeurs toutes les millisecondes alors que je ne suis pas un Superman pour les voir et si je l'étais le moniteur aura déjà atteint sa limite matériel.
Est-ce que je peux gérer le temps de chaque boucle, autrement dit, si j'ai une ressource de 100% du processeur par exemple à exploiter, alors est-ce que c'est possible d'accorder à chaque fonction un poucentage défini avec lequel elle peut fonctionner ? Une sorte de priorité.
>Le plus importante, c'est que vous ne cherchez pas trop à comprendre. Faites le cas le plus simple, faites la configuration de votre "DataReceivedHandler" dans le OnLoad de votre formulaire.
Je l'ai déjà fait et ça fonctionne pas convenablement.
"C'est un coup du sort étrange : tout les hommes dont on a ouvert le crâne avaient un cerveau" . Wittgenstein.
Passer de Winform à WPF n'est pas une "simplification", bien au contraire.
WPF est bien plus "puissant " que Winform.
Mais, bon, vos mé-conceptions de comment fonctionne un processus et les threads sont tellement "basiques" que passer de l'un à l'autre de ces framework graphiques ne changera rien au problème (ça ne le résoudra pas, mais cela ne le complexifiera pas plus).
>Pourquoi est-ce que j'aurai besoin d'afficher les valeurs toutes les millisecondes
Ce n'est pas vraiment le cas, sauf dans vos usines à gaz.
De manière "normale", la carte graphique envoie au moniteur le contenu de la "RAM vidéo" à la cadence de 60Hz ou tout autre vitesse de rafraichissement configurée. Modifier le contenu de la "RAM vidéo" plus vite que se rafraichissement vertical de l'écran n'a aucun intérêt.
Donc, l'OS ne demande aux processus de mettre à jour leur affichage qu'à la fréquence de rafraichissement vertical du moniteur. De plus, l'OS indique l'ensemble des zones à rafraichir depuis la dernière synchronisation car il a été notifié par les contrôles qu'ils ont été "modifiés" (quand on change le texte d'un Label, par exemple, le label ne change pas tout de suis le rendu; mais notifie le système que la zone qu'il occupe dans la fenêtre doit être "rafraichi").
Avec cette information des zones à mettre à jours, généralement planquée dans les arcanes du framework graphique, ce framework demande à tous les contrôles devant rafraichir leur rendu, de le faire. C'est à ce moment que le nouveau texte est "rendu" dans la mémoire vidéo avec la nouvelle valeur, que le contrôle a stocké entre son changement et son rendu effectif dans la mémoire vidéo. (Il garde cette valeur après pour d'autres usages)
Donc bourriner comme vous le faite "l'affichage", c'est pas très fut-fut.
>Est-ce que je peux gérer le temps de chaque boucle
Pourquoi vous faire chier avec ??? L'OS le fait très bien à votre place, si vous lui collez pas des boucles actives dans les dents.
>si j'ai une ressource de 100% du processeur par exemple à exploiter
Sympa pour les autres processus (et autres services Windows, drivers de matériel, etc...) qui ne peuvent pas faire leurs tâches malgré l'importance essentielle celles-ci.
Heureusement que les concepteurs d'OS modernes ont de quoi vous empêcher de faire votre œuvre de sociopathe.
>alors est-ce que c'est possible d'accorder à chaque fonction un poucentage défini
Pas au niveau de la fonction, mais du processus, ça fait déjà largement l'affaire, on laisse le sociopathe pourrir sa machine mais pas directement les autres processus ou le hardware.
Vous avez une vue complètement biaisé de comment fonctionne un ordinateur. Vous faites des assertions complètement fausses à partir de cette conception simpliste.
Les concepteurs des framework sont là pour vous faciliter la vie, pas pour vous empêcher de faire des choses "bien".
Comprenez comment utiliser ces frameworks. Vous n'êtes clairement pas en capacité de comprendre comment ils fonctionnent, pour essayer de faire mieux ou de faire "autrement".
>Je l'ai déjà fait et ça fonctionne pas convenablement.
Le plus probable, c'est que vous ne VOUS en n'êtes pas servi correctement.
Montrez ce code qui "fonctionne pas convenablement.", SVP ?
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
Pointeur
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Un bon dev est un dev qui sait Googler