Discussion :

[pompomthebest]

Bonjour,

J'ai une fenêtre avec 2 plans.

Un plan ( N°1) contenant un champ planning avec environ 200 taches dans le planning.

Un plan ( N°2) qui est vide.

Lorsque j'arrive sur mon application, j'arrive sur le plan 1 et mon planning se charge très bien.
Si je vais sur le plan 2 puis que je reviens sur le Plan 1 avec cette ligne de code MaFenetre..plan = 1, cela met environ 2 secondes. Je ne comprends pas pourquoi car mon planning est déjà rempli et que je ne le rafraîchi pas.

J'ai donc mis ce code la pour vérifier :

ChronoDébut(1)
MaFenêtre..Plan = 1
Trace(ChronoFin(1))

En effet mon trace me renvoi 2000 ms (2s).

Apparemment, Windev repasse dans le code de déclaration de la fenêtre interne "FI_WindevRDV_Planning" qui est appelé pour chaque rendez-vous du planning.
Donc si l'on fait un "PLANNING..visible = vrai" ou "MaFenêtre..Plan = 1", cela repasse dans le code de déclaration de la fenêtre interne pour chaque rendez vous affichés.( si 200 rendez-vous alors cela est long...)

Quelqu'un sait comment éviter ce chargement long et inutile ?


Merci d'avance

Romain

[laurent30s]

Ton planning, tu le remplis comment ?
Par programmation ou avec une requête ?

[pompomthebest]

Bonjour,

Je le rempli par programmation avec une requête SQL dans mon code.
Le planning n'est pas relié à un fichier...

Voici un résumé de mon code pour le remplir :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
sSql = [
	SELECT *
        FROM MaTable
]
 
HExécuteRequêteSQL(Gb_Fic_Planning,hRequêteDéfaut,sSql)
 
 
HLitPremier(Gb_Fic_Planning)
TANTQUE PAS HEnDehors(Gb_Fic_Planning)
 
    //Mon code d'ajout dans le planning
 
    Hlitsuivant(Gb_Fic_Planning)
FIN

[mail.spam]

Bonjour,

Si tu utilise l'analyseur de performance tu devrai trouver d'où ça vient.
Tu as peut-être du code dans la prise de focus?

[pompomthebest]

Avec l'analyseur de performance il m'indique que ce code

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

MaFenêtre..Plan = 1

met 2000 ms.

Si je fais un pas à pas avec le debugeur, je vois que lorsque j'arrive sur ce code

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

MaFenêtre..Plan = 1

il m'envoi dans la déclaration globale de ma fenêtre interne "FI_WindevRDV_Planning"

J'ai pas du tout de code dans le traitement prise de focus du planning.


Est ce un bug de Windev ?

Quelqu'un peut essayé de le reproduire svp ?
(Il faut un champ planning sur une fenêtre avec 2 plan + une fenêtre interne dans le champ planning pour la visualisation d'un rendez vous ( onglet général du champ) + 200 rendez vous pour s'apercevoir de la perte de temps.)

Merci d'avance de vos conseils et de votre aide. Je suis vraiment bien bloqué.

[laurent30s]

Je le rempli par programmation avec une requête SQL dans mon code.
Le planning n'est pas relié à un fichier...

En fait mon questionnement c'est est que quand tu reviens sur le plan la requête est rejouée ?
Si c'est le cas, comme le montre ton code, c'est normal que l'affichage du planning soit actualisé...

Normalement en utilisant l'analyseur de performance comme le préconise sylvain tu devrais savoir où passe le temps...

Si la requête est rejouée et que tu n'a pas la possibilités de l'éviter, peut-être qu'en jouant sur AffichageActif avant et après la boucle de remplissage. J'ai pas testé avec un champ planning mais je sais qu'avec un champ table qui a beaucoup de lignes le gain de temps peut être conséquent.
D'autre part l'option hSansRafraîchir dans un HLitPremier() peut aussi apporter un gain de temps.

Ce qui donne dans ton code

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
sSql = [
	SELECT *
        FROM MaTable
]
 
HExécuteRequêteSQL(Gb_Fic_Planning,hRequêteDéfaut,sSql)
 
TonPlanning..AffichageActif = Faux
HLitPremier(Gb_Fic_Planning,hSansRafraîchir)
TANTQUE PAS HEnDehors(Gb_Fic_Planning)
 
    //Mon code d'ajout dans le planning
 
    Hlitsuivant(Gb_Fic_Planning)
FIN
TonPlanning..AffichageActif = Vrai

Ceci dit le mieux est de n'exécuter la requête que si nécessaire...

[pompomthebest]

Merci pour vos réponses.

Non la requête n'est pas rejouée sinon en effet les 2000 ms serai justifié.

C'est justement cela qui me pose problème c'est que c'est vraiment l'appel du plan ou d'un PLANNING..Visible = vrai qui prend 2000 ms. Même l'analyseur de perf m'indique les 2000 ms sur une seule ligne

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

PLANNING..Plan = 1

.

Je trouve cela vraiment bizare ...

[michel.souris]

Je vais pas beaucoup t'aider mais je me souviens avoir eu un gros problème de perf sur un projet où j'utilisais le champs planning...

Je me souviens m'être aperçu que le code d'init des fenêtres internes du planning était exécuté N fois (dans le détails je sais plus pourquoi ni la valeur de N)

Donc pour la reproduction du cas, je te confirme... de mémoire j'avais du bougé le code d'init de ma FI du planning et me la galérer comme un ... voilà !

Par contre j'ai quitté la boite depuis.... donc j'ai plus le projet !

[pompomthebest]

Merci pour cette précision.

En effet cela ne m'avance pas beaucoup mais ça fait toujours plaisir de voir que je ne suis pas le seul à avoir ce problème.

Quelqu'un aurait-il une idée de comment et où déplacer le code de déclaration de la Fenêtre Interne ?

J'ai essayé de mettre un booléen dans le code de déclaration de cette fenêtre pour limiter les déclarations en double mais le temps est toujours long.

J'ai vu que certaines personnes ont eu ce problème sur la fenêtre Interne dans le champ agenda mais pas de solution non plus...

Je prends toutes les idées car j'ai essayé beaucoup de chose mais là je ne vois pas comment faire !!

Merci d'avance et merci à ceux qui essaient de m'aider depuis le début!

[zouzoukha]

Salut

As tu essayé de voir l'ordre d'affichage des champs de ta fenêtre?
Je me rappelle qu'en changeant une fois cet ordre, j'ai réglé un souci de performance à l'ouverture de la fenêtre!

A tenter?

[pompomthebest]

Merci pour votre proposition.

J'ai essayer de changer l'ordre d'affichage mais rien n'y fait...

Je pense vraiment que cela est un bug de Windev?!

J'ai pris l'exemple WD Planning et si je fait un bouton à coter avec

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

PLN_Principal..visible = faux

puis

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

PLN_Principal..visible = vrai

avec un point d’arrêt sur le

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

PLN_Principal..visible = vrai

alors cela fini par passer dans la déclaration globale de la fenêtre interne.

Pouvez-vous faire le test s'il vous plait sur l'exemple ?

Merci d'avance de vos retours.

[laurent30s]

Je viens de faire un test... dans mon cas, après l'exécution de la requête et le remplissage du planning, l'aller retour plan 2 / plan 1 met 1054ms.

juste en faisant

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
PLN_SansNom1..AffichageActif = Faux
MaFenêtre..Plan = 1
PLN_SansNom1..AffichageActif = Vrai

le temps tombe à 11ms (95 fois plus vite !)

Je précise que que le temps que je donne est celui retourné par l'analyseur de performance sur le clic du bouton qui amène sur le plan 1.
Apparemment ça enlève les nombreux appels à la fenêtre interne.

A essayer pour voir si ça améliore ton traitement...

[pompomthebest]

Merci pour ce test. Cela fait plaisir de voir que vous avez essayé mon problème.

Je viens d'essayer votre code.

Malheureusement dans mon cas, cela ne change pas le temps de traitement même dans l'analyseur de performance.

Je dois peut être avoir un autre paramètre qui me bloque ?!

Avez vous fait autre chose de particulier ?

J'ai envoyé ma demande au ST de Pcsoft mais je ne sais s'il pourrons me débloquer. En tout cas je l’espère car je suis vraiment bloqué.

Encore merci pour vos propositions!

[laurent30s]

La propriété ..AffichageActif permet d'optimiser les traitements dans lesquels un ou plusieurs champs doivent être manipulés.
L'affichage du champ est désactivé avant la manipulation et on le réactive juste après.

Sans ça à chaque manipulation il vérifie l'affichage de toutes les manipulations précédentes. Du coup les temps de traitements croissent de façon exponentielles par rapport au nombre d'éléments affichés dans le champ.

Pour en revenir au test que j'ai fait

J'ai une requête qui me retourne les 3000 premiers enregistrements (avec une DateHeureDebut et une DateHeureFin + quelques autres rubriques)

Dans la fenêtre sur le plan 1
- 1 planning PLN_SansNom1 qui utilise une fenêtre interne pour les rendez vous FI_WinDevVueRDV et que je rempli par programmation

Sur le plan 0, 3 boutons :
- BTN_RempliPlanning :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
MonRDV est un RendezVous
HExécuteRequête(REQ_RDV)
HLitPremier(REQ_RDV,hSansRafraîchir)
TANTQUE PAS HEnDehors(REQ_RDV)
	MonRDV..Contenu   = REQ_RDV.RDV_id
	MonRDV..DateDébut = REQ_RDV.RDV_DateHeureDebut
	MonRDV..DateFin   = REQ_RDV.RDV_DateHeureFin
	MonRDV..Ressource = REQ_RDV.RDV_Description
	PlanningAjouteRendezVous(PLN_SansNom1,MonRDV)	
	HLitSuivant(REQ_RDV)
FIN

- BTN_Plan1

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
PLN_SansNom1..AffichageActif = Faux
FEN_Principale..Plan = 1
PLN_SansNom1..AffichageActif = Vrai

- BTN_Plan2

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

FEN_Principale..Plan = 2

Protocole de test
- je lance le test en passant par l'analyseur de performance
- je clique sur bouton remplir le planning
- puis sur le bouton pour passer sur le plan 2
- puis sur le bouton pour revenir sur le plan 2
- puis je ferme

Peut être que tu y trouveras une différence avec ce que tu fais et qui pourra t'aider...

[pompomthebest]

Bonsoir,

Merci de toutes ces précisions.

Je suis en train de tester cela dans un nouveau projet vierge. Avec votre exemple précis.

Je vous tiens au courant dès que mon test est terminé.

[iceuponfire]

Je déterre ce topic, car le problème subsiste toujours en version 21.

Oui le ..affichageactif permet de gagner un peu de temps lors de l'affichage du planning cependant ce qui est très surprenant c'est que lorsqu'on utilise l’ascenseur windev repasse dans le code de déclaration globale de la fenêtre FI_WindevVueRDV à chaque affichage du RDV. Amusez-vous via l'analyseur de performance à afficher un planning avec beaucoup de RDV et ressources, puis faire bouger l'ascenseur, vous aller voir le nombre de parcours de la déclaration globale de FI_WinDevVueRDV est hallucinant.

Le temps de traitement serait acceptable individuellement mais la somme de l'ensemble du temps d'affichage introduit des petites lenteurs dans le champ planning qui rend vraiment le truc désagréable à utiliser, en tout cas dès qu'il faut scroller.

Je n'ai pas trouvé de solutions pour éviter que windev repasse à chaque affichage dans le code de déclaration globale de la fenêtre FI_WindevVueRDV. Si quelqu'un a une astuce je suis prenneur.

[ShigotoShigoto]

Je déterre ce topic, car le problème subsiste toujours en version 21.

Pareil. Windev 25, le problème subsiste et aucun espoir d'amélioration. Le champ planning est inutilisable au delà d'un certain nombre de rendez-vous, et cela depuis plus de 7 ans!

J'imagine que les cas réels d'utilisation sont rares et se limitent à un faible volume de données. Quelle tristesse...

[padbrain]

Bonjour,

Voici une suggestion pour l'utilisation des fenêtres internes afin de p-e éviter ce pb.

Le remplissage par programmation du champ planning devra être fait dans l'évènement "Demande de mise à jour de l'affichage" avec une gestion du rafraichissement comme suit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
//     Ceci est la déclaration globale de la fenêtre interne
PROCEDURE MyWindow()
 
let gbInitializedWindow = false

puis dans l'évènement "Demande de mise à jour de l'affichage"

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
PROCEDURE refresh(pExplicitRequest is boolean = false)
 
gbInitializedWindow = pExplicitRequest ? false ELSE gbInitializedWindow
 
IF NOT gbInitializedWindow
     fillPlanningControl()
     gbInitializedWindow = true
END

fillPlanningControl() étant la procédure permettant de remplir le planning.

De manière générale, j'initialise tous les champs contenus dans une fenêtre interne dans cette procédure refresh() dont je peux contrôler l'exécution.

hth,
Padbrain