Lourdeur du champs planning / éviter le recalcul visuel de centaines de rendezvous

Bonjour à tous,

j'ai un sujet autour du champs Planning, version 24, mais de ce que j'ai pu lire, ça n'est pas forcément solutionné dans les versions suivantes.

J'ai donc un planning, avec disons une bonne douzaines de machines (ça pourrait grandir), qui sont mes ressources en ligne.
Mon planning me sert à gérer des OFs (issus d'un import CSV provenant de l'ERP) que je dépose sur les files de mes machine.
Le planning peut être consulté en vue à la journée, en mode 2 semaines, sur 1 mois, et enfin sur 3 mois.

Sachant que mes OFs resteront quoi qu'il arrive en base, même lorsqu'ils seront terminés, je m'arrange donc pour ne pas alimenter mes files machines avec des OFs plus vieux qu'une certaine date (un paramètre global pour ne pas charger inutilement les vieilleries).

Malgré ce filtrage, je me retrouve quand même avec, dans le pire des cas (vue 3 mois), environ 250 objets "rendezVous" dans le planning, et cela occasionne des lourdeurs non seulement quand on scroll le planning pour faire glisser la période visualisée, mais aussi cela engendre un traitement de recalcul généralisé de tous les objets rendezvous présents dans le planning.

J'aimerais donc court-circuiter l'exécution du code d'initialisation de la fenêtre interne FI_Windev_RDV qui sert de support pour mes rendezVous, et qui s'exécute autant de fois qu'il y a de rendezVous dans le planning, chaque fois que le planning retrouve le focus, ou qu'on fait un réduire/maximise, ou qu'on fait glisser la période. Dans mon exemple, quand le planning et ses ressources sont créés, et les rendez-vous ajoutés au planning, ce traitement de "calcul" du visuel du rendezvous est nécessaire uniquement la toute première fois, ensuite, et pour toute la durée d'utilisation du programme, je n'ai absolument plus besoin que le visuel se recalcule, et je pense que l'expérience utilisateur s'en trouverait incroyablement améliorée.

https://i.postimg.cc/YCNRyh9q/ordolab3.png

Auriez-vous déjà manipulé le champs planning et rencontré ce cas de figure ?

Merci par avance pour vos suggestions de résolution.

droliprane

Bonjour à tous, je fais avancer un peu la discussion.
Je me suis dit que j'allais introduire un tableau de chaines (les clés de mes rendezvous) que je remplirais au fur et à mesure que les rendez-vous sont ajoutés au planning.
Je ne peux pas me baser sur l'instruction standard planningListeRendezVous, car si je l'invoque depuis ma fenêtre interne FI_TACHE, c'est que l'objet rendezVous est déjà associé au planning.
J'ai donc ce tableau de chaines, tab_taches, qui est global à mon projet, que je teste dans le code d'initialisation de la fenêtre FI_TACHE. Si ma clé est déjà connue (dans le tableau tab_taches) alors je fais un bête RETOUR :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

PROCÉDURE FI_TACHE( gGclRendezVous est un agRendezVous dynamique )   SI TableauCherche(FEN_START.tab_taches, tcLinéairePremier, taskid) > 0 ALORS RETOUR FIN TableauAjoute(FEN_START.tab_taches, taskid) ... LIB_CONTENU = "blabla" LIB_CONTENU..CouleurFond = "une couleur qui dépend de la famille de la tâche" // je ne détaille pas comment je récupère la couleur, c'est sans intérêt ici // .... // suite du la mise en forme du rendez-vous // widgets sens interdit, engrenage qui matérialise un besoin de réglage de la machine, etc...

---

Le comportement est maintenant le suivant :
à la première alimentation du planning, le code d'initialisation de FI_TACHE s'exécute bien pour chaque objet rendez-vous du planning
mais ensuite, dès que j'interagis avec le planning (sélection d'un rdv, redimensionnement de la fenêtre, ...) cela déclenche de façon automatisée un recalcul du visuel du ou des rdv concernés. Et même si j'ai maintenant ce "court-circuitage" du code d'initialisation si le rdv est connu dans tab_taches, le visuel du rendez-vous change quand même et prend les apparences du tout dernier rendezvous ajouté au planning.

Exemple :

premier chargement, vue sur 1 mois (notez le rendez vous tout à la fin, qui est en fond rouge, ce n'est pas flagrant comme ça mais faites moi confiance, ils sont chargés par ordre de la date de début, c'est bien le dernier ajouté visuellement) :

https://i.postimg.cc/qRFC2h3M/1.png

clic sur des rendez-vous au hasard (il prennent le fond rouge, le contenu, les widgets, du dernier rendez-vous qui s'est servi de FI_TACHE) :

https://i.postimg.cc/7ZCPTsN7/2.png

redimensionnement de la fenêtre, tous les rdv deviennent rouge, prennent le même contenu :

https://i.postimg.cc/14hBcYqt/3.png

passage en mode 3 mois, de nouveaux rendez-vous apparaissent, le système ne calcule le visuel que de ceux qu'il découvre et qui ne sont pas déjà dans le tableau global tab_taches, les autres sont tous devenus rouges :

https://i.postimg.cc/hGQGHSZf/4.png

à nouveau je m'amuse à cliquer sur certains rendez-vous, cela déclenche leur "redessin", et ils passent en vert, comme celui qui est actuellement le plus à droite...

https://i.postimg.cc/sxqjn5j1/5.png

J'ai comme l'impression que la fenêtre interne FI_TACHE qui sert de support pour le visuel des rendez-vous n'est pas "propre" à chaque instance de rendez-vous, elle a comme une sorte de "mémoire" de ses dernières propriétés affectées, et elle les reproduit par défaut dans un traitement graphique automatique sur lequel on a pas la main, lors de chaque redessin d'un rendez-vous.

J'ai conscience que je décris un truc bien tordu, et que vous risquez de pas être nombreux à pouvoir m'aider, mais j'ai tenté d'expliquer au mieux mon soucis, qui est bien gênant pour mon projet. Je pourrais laisser le programme redessiner systématiquement tous les rendez-vous, mais c'est réellement anti-performant, si je veux améliorer l'ergonomie et la vitesse, je dois pouvoir contrôler les objets à redessiner.

Merci par avance à ceux qui auront lu et essayé de comprendre.

droliprane

Bonjour Droliprane,

J'ai bien compris ton souci de ré-affichage. Je l'avais déjà subi (surtout quand la machine est peu performante).. avec le champ agenda. Comme le rafraichissement n'était pas aussi intense que le tien, j'avais dit aux utilisateurs que les pc étant de plus puissant, le clignotement serait trop rapide pour vraiment les importuner. En même temps, il y avait max 10 ressources et peu de rdv par ressource. ;)

Avec toi, on rentre dans un autre monde...

En fait, comme tu l'as exprimé, il fait un "re-dessin" quand même et comme il doit y avoir une variable mal initialisée, les couleurs ne sont plus les bonnes.

J'ai bien une idée, mais je ne sais pas si c'est possible (et peu coûteux en temps/ressources) : copier la FI RDV dans la fenêtre du planning (=FI modèle). Modifier la FI RDV en mettant juste une image dedans. Pour chaque nouveau rdv, afficher les infos dans la FI modèle et créer une image de ça (je ne sais pas encore comment faire, mais avec une API rect, peut-être que ça pourrait aller). Stocker l'id de ton rdv dans un tableau associatif / ou dans ton tableau de chaines.

Livré sans aucune garantie :mrgreen:

C'est vraiment pas con en effet !

C'est sûr que si je ne veux pas me voir changer en temps réel dans un miroir, rien de tel que de coller dessus une photo où je suis encore jeune et beau ^^

Après, je serai vraisemblablement confronté au problème d'une image qui aura été capturée dans un format qui serait fixe, et qui subirait la taille variable du rendez-vous (en largeur essentiellement).

Je vais réfléchir à ton idée.

Merci pour cette piste

Pour la largeur, avec l'ancrage, ça devrait le faire.

Je pense que si l'utilisateur veut voir le détail du rdv, il double-clique dessus (et ça ouvre une fenêtre "fiche").

Citation:

---

Envoyé par frenchsting

Pour la largeur, avec l'ancrage, ça devrait le faire.

Je pense que si l'utilisateur veut voir le détail du rdv, il double-clique dessus (et ça ouvre une fenêtre "fiche").

---

hélas non, mon client il veut tout plein d'infos déjà visibles sur la tâche, sans devoir ouvrir une popup.
J'ai déjà une bulle, mais il faut quand même un certain nombre de pictogrammes d'alerte, nécessité d'anticiper un réglage machine, retard d'avancement OF, etc...

Et quand j'y pense c'est un problème rien qu'à cause du texte (N°OF, Ref Produit, Ref Plan), si j'étire une image à 200% de sa largeur ça risque de pas passer inaperçu :aie:

Salut drolipane

Figure toi que je me retrouve aussi dans le même problème la lenteur est énorme

Va s'avoir pourquoi le code d'initialisation de la FI est non stop appelée...

Citation:

---

Envoyé par droliprane

hélas non, mon client il veut tout plein d'infos déjà visibles sur la tâche, sans devoir ouvrir une popup.
J'ai déjà une bulle, mais il faut quand même un certain nombre de pictogrammes d'alerte, nécessité d'anticiper un réglage machine, retard d'avancement OF, etc...

Et quand j'y pense c'est un problème rien qu'à cause du texte (N°OF, Ref Produit, Ref Plan), si j'étire une image à 200% de sa largeur ça risque de pas passer inaperçu :aie:

---

Hello,

Comme le sujet vient de remonter grâce à mous97, j'ai repensé à un truc que j'ai fait il y a quelques temps : utiliser une fenêtre flottante en lieu et place de la bulle d'aide. Ca permet de faire une fiche avec tes images bien placées (normalement, tu peux le faire avec une bulle mais c'est plutôt sport).

Salut à tous les deux,

j'apprécie que le sujet concerne finalement quelques personnes, je me sens moins seul ^^

L'idée d'une fenêtre ou d'une bulle, qui nécessiterait une action de l'utilisateur pour "révéler" les différentes informations contenues dans la tâche, ne sera pas satisfaisante en ce qui me concerne.

J'ai besoin que la vue globale montre les différents pictogrammes sur chaque objet rdv.

Je retourne le truc dans tous les sens, j'ai presque envie de refaire tout mon projet de zéro dans un autre framework.


droliprane

J'te comprend je sèche aussi j'ai même essayé de fouiner dans les api windows

Je reviens juste sur un point qui est un peu anecdotique.
Tu fais un TableauCherche() pour savoir s'il faut redessiner la fenêtre.
J'aurais mis dans ma fenêtre interne une variable 'RedessinInutile' de type booléen, et ainsi tout se passe dans la fenêtre interne : Tu mets cette variable à Vrai à la fin de ta procédure d'affichage. Et tu la repasses à Faux quand c'est nécessaire, comme pour revenir au fonctionnement standard.
Plus besoin de ce TableauCherche().
Mais logiquement, ça ne va rien changer à tes problèmes.