Bonjour,
Comme toute application qui existe depuis longtemps, notre code s'est
allourdi petit a petit ... pour "s'usinagazifier" ... il faut dire que
l'appli a été créé en 5.5 ... avec toutes les mises à jour qui s'imposent
depuis (en 10 pour l'instant) ... et pour prévenir tout débordement, il ne
nous est pas encore possible de recommencer un développement à 0.
J'aurais donc besoin d'un petit retour d'expérience de votre part :
Par exemple, pour une fonction gigantissime de quelques centaines de lignes
(nombreux selons imbriqués) serait-il plus performant d'isoler les codes des
différents cas dans des procedures séparées, la procedure principale ne
contenant que le selon principal et l'appel aux fonctions secondaires ?
Selon choix1
cas 1
30 lignes de code
cas 2
200 lignes de code
cas N
autres cas
fin
ou
Selon choix 1
cas 1 : fonction1()
cas 2 : fonction2()
cas N : fonctionN()
autres cas
fin
De même, notre fenêtre principale contient à l'heure actuelle environ 300
champs (boutons, libellés, tables, ...) cela a t'il un impact sur les
performances et si oui, comment faire pour y remédier ?
Quelles sont les astuces ou réalitées de notre logiciel préféré qui
pourraient m'aider à alleger un peu mon application.
Merci d'avance pour vos avis éclairés.
Albert P.
Bonjour,
Comme toute application qui existe depuis longtemps, notre code s'est
allourdi petit a petit ... pour "s'usinagazifier" ... il faut dire que
l'appli a été créé en 5.5 ... avec toutes les mises à jour qui s'imposent
depuis (en 10 pour l'instant) ... et pour prévenir tout débordement, il ne
nous est pas encore possible de recommencer un développement à 0.
J'aurais donc besoin d'un petit retour d'expérience de votre part :
Par exemple, pour une fonction gigantissime de quelques centaines de lignes
(nombreux selons imbriqués) serait-il plus performant d'isoler les codes des
différents cas dans des procedures séparées, la procedure principale ne
contenant que le selon principal et l'appel aux fonctions secondaires ?
Selon choix1
cas 1
30 lignes de code
cas 2
200 lignes de code
cas N
autres cas
fin
ou
Selon choix 1
cas 1 : fonction1()
cas 2 : fonction2()
cas N : fonctionN()
autres cas
fin
De même, notre fenêtre principale contient à l'heure actuelle environ 300
champs (boutons, libellés, tables, ...) cela a t'il un impact sur les
performances et si oui, comment faire pour y remédier ?
Quelles sont les astuces ou réalitées de notre logiciel préféré qui
pourraient m'aider à alleger un peu mon application.
Merci d'avance pour vos avis éclairés.
Albert P.
Bonjour,
Comme toute application qui existe depuis longtemps, notre code s'est
allourdi petit a petit ... pour "s'usinagazifier" ... il faut dire que
l'appli a été créé en 5.5 ... avec toutes les mises à jour qui s'imposent
depuis (en 10 pour l'instant) ... et pour prévenir tout débordement, il ne
nous est pas encore possible de recommencer un développement à 0.
J'aurais donc besoin d'un petit retour d'expérience de votre part :
Par exemple, pour une fonction gigantissime de quelques centaines de lignes
(nombreux selons imbriqués) serait-il plus performant d'isoler les codes des
différents cas dans des procedures séparées, la procedure principale ne
contenant que le selon principal et l'appel aux fonctions secondaires ?
Selon choix1
cas 1
30 lignes de code
cas 2
200 lignes de code
cas N
autres cas
fin
ou
Selon choix 1
cas 1 : fonction1()
cas 2 : fonction2()
cas N : fonctionN()
autres cas
fin
De même, notre fenêtre principale contient à l'heure actuelle environ 300
champs (boutons, libellés, tables, ...) cela a t'il un impact sur les
performances et si oui, comment faire pour y remédier ?
Quelles sont les astuces ou réalitées de notre logiciel préféré qui
pourraient m'aider à alleger un peu mon application.
Merci d'avance pour vos avis éclairés.
Albert P.
Bonjour,
Comme toute application qui existe depuis longtemps, notre code s'est
allourdi petit a petit ... pour "s'usinagazifier" ... il faut dire que
l'appli a été créé en 5.5 ... avec toutes les mises à jour qui s'imposent
depuis (en 10 pour l'instant) ... et pour prévenir tout débordement, il ne
nous est pas encore possible de recommencer un développement à 0.
J'aurais donc besoin d'un petit retour d'expérience de votre part :
Par exemple, pour une fonction gigantissime de quelques centaines de lignes
(nombreux selons imbriqués) serait-il plus performant d'isoler les codes des
différents cas dans des procedures séparées, la procedure principale ne
contenant que le selon principal et l'appel aux fonctions secondaires ?
Selon choix1
cas 1
30 lignes de code
cas 2
200 lignes de code
cas N
autres cas
fin
ou
Selon choix 1
cas 1 : fonction1()
cas 2 : fonction2()
cas N : fonctionN()
autres cas
fin
De même, notre fenêtre principale contient à l'heure actuelle environ 300
champs (boutons, libellés, tables, ...) cela a t'il un impact sur les
performances et si oui, comment faire pour y remédier ?
Quelles sont les astuces ou réalitées de notre logiciel préféré qui
pourraient m'aider à alleger un peu mon application.
Merci d'avance pour vos avis éclairés.
Albert P.
Bonjour,
Comme toute application qui existe depuis longtemps, notre code s'est
allourdi petit a petit ... pour "s'usinagazifier" ... il faut dire que
l'appli a été créé en 5.5 ... avec toutes les mises à jour qui s'imposent
depuis (en 10 pour l'instant) ... et pour prévenir tout débordement, il ne
nous est pas encore possible de recommencer un développement à 0.
J'aurais donc besoin d'un petit retour d'expérience de votre part :
Par exemple, pour une fonction gigantissime de quelques centaines de lignes
(nombreux selons imbriqués) serait-il plus performant d'isoler les codes des
différents cas dans des procedures séparées, la procedure principale ne
contenant que le selon principal et l'appel aux fonctions secondaires ?
Selon choix1
cas 1
30 lignes de code
cas 2
200 lignes de code
cas N
autres cas
fin
ou
Selon choix 1
cas 1 : fonction1()
cas 2 : fonction2()
cas N : fonctionN()
autres cas
fin
De même, notre fenêtre principale contient à l'heure actuelle environ 300
champs (boutons, libellés, tables, ...) cela a t'il un impact sur les
performances et si oui, comment faire pour y remédier ?
Quelles sont les astuces ou réalitées de notre logiciel préféré qui
pourraient m'aider à alleger un peu mon application.
Merci d'avance pour vos avis éclairés.
Albert P.
Bonjour,
Comme toute application qui existe depuis longtemps, notre code s'est
allourdi petit a petit ... pour "s'usinagazifier" ... il faut dire que
l'appli a été créé en 5.5 ... avec toutes les mises à jour qui s'imposent
depuis (en 10 pour l'instant) ... et pour prévenir tout débordement, il ne
nous est pas encore possible de recommencer un développement à 0.
J'aurais donc besoin d'un petit retour d'expérience de votre part :
Par exemple, pour une fonction gigantissime de quelques centaines de lignes
(nombreux selons imbriqués) serait-il plus performant d'isoler les codes des
différents cas dans des procedures séparées, la procedure principale ne
contenant que le selon principal et l'appel aux fonctions secondaires ?
Selon choix1
cas 1
30 lignes de code
cas 2
200 lignes de code
cas N
autres cas
fin
ou
Selon choix 1
cas 1 : fonction1()
cas 2 : fonction2()
cas N : fonctionN()
autres cas
fin
De même, notre fenêtre principale contient à l'heure actuelle environ 300
champs (boutons, libellés, tables, ...) cela a t'il un impact sur les
performances et si oui, comment faire pour y remédier ?
Quelles sont les astuces ou réalitées de notre logiciel préféré qui
pourraient m'aider à alleger un peu mon application.
Merci d'avance pour vos avis éclairés.
Albert P.
Albert P. a couché sur son écran :Bonjour,
Comme toute application qui existe depuis longtemps, notre code s'est
allourdi petit a petit ... pour "s'usinagazifier" ... il faut dire que
l'appli a été créé en 5.5 ... avec toutes les mises à jour qui s'imposent
depuis (en 10 pour l'instant) ... et pour prévenir tout débordement, il
ne nous est pas encore possible de recommencer un développement à 0.
J'aurais donc besoin d'un petit retour d'expérience de votre part :
Par exemple, pour une fonction gigantissime de quelques centaines de
lignes (nombreux selons imbriqués) serait-il plus performant d'isoler les
codes des différents cas dans des procedures séparées, la procedure
principale ne contenant que le selon principal et l'appel aux fonctions
secondaires ?
Selon choix1
cas 1
30 lignes de code
cas 2
200 lignes de code
cas N
autres cas
fin
ou
Selon choix 1
cas 1 : fonction1()
cas 2 : fonction2()
cas N : fonctionN()
autres cas
fin
De même, notre fenêtre principale contient à l'heure actuelle environ 300
champs (boutons, libellés, tables, ...) cela a t'il un impact sur les
performances et si oui, comment faire pour y remédier ?
Quelles sont les astuces ou réalitées de notre logiciel préféré qui
pourraient m'aider à alleger un peu mon application.
Merci d'avance pour vos avis éclairés.
Albert P.
bonsoir
pour la maintenance il n'y pa pas photo.
même dans le code principal, j'aime avoir une succession de fonctions
trait1()
trait2()
...
cela oblige à structurer le code.
concernant la fenêtre, quand il y a trop de champs, j'utilise les onglets.
très pratique pour l'utilisateur !
cdt
titou44 chez freesurf.fr
Albert P. a couché sur son écran :
Bonjour,
Comme toute application qui existe depuis longtemps, notre code s'est
allourdi petit a petit ... pour "s'usinagazifier" ... il faut dire que
l'appli a été créé en 5.5 ... avec toutes les mises à jour qui s'imposent
depuis (en 10 pour l'instant) ... et pour prévenir tout débordement, il
ne nous est pas encore possible de recommencer un développement à 0.
J'aurais donc besoin d'un petit retour d'expérience de votre part :
Par exemple, pour une fonction gigantissime de quelques centaines de
lignes (nombreux selons imbriqués) serait-il plus performant d'isoler les
codes des différents cas dans des procedures séparées, la procedure
principale ne contenant que le selon principal et l'appel aux fonctions
secondaires ?
Selon choix1
cas 1
30 lignes de code
cas 2
200 lignes de code
cas N
autres cas
fin
ou
Selon choix 1
cas 1 : fonction1()
cas 2 : fonction2()
cas N : fonctionN()
autres cas
fin
De même, notre fenêtre principale contient à l'heure actuelle environ 300
champs (boutons, libellés, tables, ...) cela a t'il un impact sur les
performances et si oui, comment faire pour y remédier ?
Quelles sont les astuces ou réalitées de notre logiciel préféré qui
pourraient m'aider à alleger un peu mon application.
Merci d'avance pour vos avis éclairés.
Albert P.
bonsoir
pour la maintenance il n'y pa pas photo.
même dans le code principal, j'aime avoir une succession de fonctions
trait1()
trait2()
...
cela oblige à structurer le code.
concernant la fenêtre, quand il y a trop de champs, j'utilise les onglets.
très pratique pour l'utilisateur !
cdt
titou44 chez freesurf.fr
Albert P. a couché sur son écran :Bonjour,
Comme toute application qui existe depuis longtemps, notre code s'est
allourdi petit a petit ... pour "s'usinagazifier" ... il faut dire que
l'appli a été créé en 5.5 ... avec toutes les mises à jour qui s'imposent
depuis (en 10 pour l'instant) ... et pour prévenir tout débordement, il
ne nous est pas encore possible de recommencer un développement à 0.
J'aurais donc besoin d'un petit retour d'expérience de votre part :
Par exemple, pour une fonction gigantissime de quelques centaines de
lignes (nombreux selons imbriqués) serait-il plus performant d'isoler les
codes des différents cas dans des procedures séparées, la procedure
principale ne contenant que le selon principal et l'appel aux fonctions
secondaires ?
Selon choix1
cas 1
30 lignes de code
cas 2
200 lignes de code
cas N
autres cas
fin
ou
Selon choix 1
cas 1 : fonction1()
cas 2 : fonction2()
cas N : fonctionN()
autres cas
fin
De même, notre fenêtre principale contient à l'heure actuelle environ 300
champs (boutons, libellés, tables, ...) cela a t'il un impact sur les
performances et si oui, comment faire pour y remédier ?
Quelles sont les astuces ou réalitées de notre logiciel préféré qui
pourraient m'aider à alleger un peu mon application.
Merci d'avance pour vos avis éclairés.
Albert P.
bonsoir
pour la maintenance il n'y pa pas photo.
même dans le code principal, j'aime avoir une succession de fonctions
trait1()
trait2()
...
cela oblige à structurer le code.
concernant la fenêtre, quand il y a trop de champs, j'utilise les onglets.
très pratique pour l'utilisateur !
cdt
titou44 chez freesurf.fr
Bonjour,
"titou44" a écrit dans le message de news:Albert P. a couché sur son écran :Bonjour,
Comme toute application qui existe depuis longtemps, notre code s'est
allourdi petit a petit ... pour "s'usinagazifier" ... il faut dire que
l'appli a été créé en 5.5 ... avec toutes les mises à jour qui s'imposent
depuis (en 10 pour l'instant) ... et pour prévenir tout débordement, il ne
nous est pas encore possible de recommencer un développement à 0.
J'aurais donc besoin d'un petit retour d'expérience de votre part :
Par exemple, pour une fonction gigantissime de quelques centaines de
lignes (nombreux selons imbriqués) serait-il plus performant d'isoler les
codes des différents cas dans des procedures séparées, la procedure
principale ne contenant que le selon principal et l'appel aux fonctions
secondaires ?
Selon choix1
cas 1
30 lignes de code
cas 2
200 lignes de code
cas N
autres cas
fin
ou
Selon choix 1
cas 1 : fonction1()
cas 2 : fonction2()
cas N : fonctionN()
autres cas
fin
De même, notre fenêtre principale contient à l'heure actuelle environ 300
champs (boutons, libellés, tables, ...) cela a t'il un impact sur les
performances et si oui, comment faire pour y remédier ?
Quelles sont les astuces ou réalitées de notre logiciel préféré qui
pourraient m'aider à alleger un peu mon application.
Merci d'avance pour vos avis éclairés.
Albert P.
bonsoir
pour la maintenance il n'y pa pas photo.
même dans le code principal, j'aime avoir une succession de fonctions
trait1()
trait2()
...
cela oblige à structurer le code.
concernant la fenêtre, quand il y a trop de champs, j'utilise les onglets.
très pratique pour l'utilisateur !
Oui mais pour le temps d'initialisation, ça ne change rien, car les champs
s'initialisent quand même dans les volets inactifs.
Cas du remplissage d'un combo par exemple...
Bonjour,
"titou44" <titou44pasdespam@freesurf.fr> a écrit dans le message de news:
mn.8cb37d94d95b1e84.63086@freesurf.fr...
Albert P. a couché sur son écran :
Bonjour,
Comme toute application qui existe depuis longtemps, notre code s'est
allourdi petit a petit ... pour "s'usinagazifier" ... il faut dire que
l'appli a été créé en 5.5 ... avec toutes les mises à jour qui s'imposent
depuis (en 10 pour l'instant) ... et pour prévenir tout débordement, il ne
nous est pas encore possible de recommencer un développement à 0.
J'aurais donc besoin d'un petit retour d'expérience de votre part :
Par exemple, pour une fonction gigantissime de quelques centaines de
lignes (nombreux selons imbriqués) serait-il plus performant d'isoler les
codes des différents cas dans des procedures séparées, la procedure
principale ne contenant que le selon principal et l'appel aux fonctions
secondaires ?
Selon choix1
cas 1
30 lignes de code
cas 2
200 lignes de code
cas N
autres cas
fin
ou
Selon choix 1
cas 1 : fonction1()
cas 2 : fonction2()
cas N : fonctionN()
autres cas
fin
De même, notre fenêtre principale contient à l'heure actuelle environ 300
champs (boutons, libellés, tables, ...) cela a t'il un impact sur les
performances et si oui, comment faire pour y remédier ?
Quelles sont les astuces ou réalitées de notre logiciel préféré qui
pourraient m'aider à alleger un peu mon application.
Merci d'avance pour vos avis éclairés.
Albert P.
bonsoir
pour la maintenance il n'y pa pas photo.
même dans le code principal, j'aime avoir une succession de fonctions
trait1()
trait2()
...
cela oblige à structurer le code.
concernant la fenêtre, quand il y a trop de champs, j'utilise les onglets.
très pratique pour l'utilisateur !
Oui mais pour le temps d'initialisation, ça ne change rien, car les champs
s'initialisent quand même dans les volets inactifs.
Cas du remplissage d'un combo par exemple...
Bonjour,
"titou44" a écrit dans le message de news:Albert P. a couché sur son écran :Bonjour,
Comme toute application qui existe depuis longtemps, notre code s'est
allourdi petit a petit ... pour "s'usinagazifier" ... il faut dire que
l'appli a été créé en 5.5 ... avec toutes les mises à jour qui s'imposent
depuis (en 10 pour l'instant) ... et pour prévenir tout débordement, il ne
nous est pas encore possible de recommencer un développement à 0.
J'aurais donc besoin d'un petit retour d'expérience de votre part :
Par exemple, pour une fonction gigantissime de quelques centaines de
lignes (nombreux selons imbriqués) serait-il plus performant d'isoler les
codes des différents cas dans des procedures séparées, la procedure
principale ne contenant que le selon principal et l'appel aux fonctions
secondaires ?
Selon choix1
cas 1
30 lignes de code
cas 2
200 lignes de code
cas N
autres cas
fin
ou
Selon choix 1
cas 1 : fonction1()
cas 2 : fonction2()
cas N : fonctionN()
autres cas
fin
De même, notre fenêtre principale contient à l'heure actuelle environ 300
champs (boutons, libellés, tables, ...) cela a t'il un impact sur les
performances et si oui, comment faire pour y remédier ?
Quelles sont les astuces ou réalitées de notre logiciel préféré qui
pourraient m'aider à alleger un peu mon application.
Merci d'avance pour vos avis éclairés.
Albert P.
bonsoir
pour la maintenance il n'y pa pas photo.
même dans le code principal, j'aime avoir une succession de fonctions
trait1()
trait2()
...
cela oblige à structurer le code.
concernant la fenêtre, quand il y a trop de champs, j'utilise les onglets.
très pratique pour l'utilisateur !
Oui mais pour le temps d'initialisation, ça ne change rien, car les champs
s'initialisent quand même dans les volets inactifs.
Cas du remplissage d'un combo par exemple...
Bonjour,
Comme toute application qui existe depuis longtemps, notre code s'est
allourdi petit a petit ... pour "s'usinagazifier" ... il faut dire que
l'appli a été créé en 5.5 ... avec toutes les mises à jour qui s'imposent
depuis (en 10 pour l'instant) ... et pour prévenir tout débordement, il ne
nous est pas encore possible de recommencer un développement à 0.
J'aurais donc besoin d'un petit retour d'expérience de votre part :
Par exemple, pour une fonction gigantissime de quelques centaines de lignes
(nombreux selons imbriqués) serait-il plus performant d'isoler les codes des
différents cas dans des procedures séparées, la procedure principale ne
contenant que le selon principal et l'appel aux fonctions secondaires ?
Selon choix1
cas 1
30 lignes de code
cas 2
200 lignes de code
cas N
autres cas
fin
ou
Selon choix 1
cas 1 : fonction1()
cas 2 : fonction2()
cas N : fonctionN()
autres cas
fin
De même, notre fenêtre principale contient à l'heure actuelle environ 300
champs (boutons, libellés, tables, ...) cela a t'il un impact sur les
performances et si oui, comment faire pour y remédier ?
Bonjour,
Comme toute application qui existe depuis longtemps, notre code s'est
allourdi petit a petit ... pour "s'usinagazifier" ... il faut dire que
l'appli a été créé en 5.5 ... avec toutes les mises à jour qui s'imposent
depuis (en 10 pour l'instant) ... et pour prévenir tout débordement, il ne
nous est pas encore possible de recommencer un développement à 0.
J'aurais donc besoin d'un petit retour d'expérience de votre part :
Par exemple, pour une fonction gigantissime de quelques centaines de lignes
(nombreux selons imbriqués) serait-il plus performant d'isoler les codes des
différents cas dans des procedures séparées, la procedure principale ne
contenant que le selon principal et l'appel aux fonctions secondaires ?
Selon choix1
cas 1
30 lignes de code
cas 2
200 lignes de code
cas N
autres cas
fin
ou
Selon choix 1
cas 1 : fonction1()
cas 2 : fonction2()
cas N : fonctionN()
autres cas
fin
De même, notre fenêtre principale contient à l'heure actuelle environ 300
champs (boutons, libellés, tables, ...) cela a t'il un impact sur les
performances et si oui, comment faire pour y remédier ?
Bonjour,
Comme toute application qui existe depuis longtemps, notre code s'est
allourdi petit a petit ... pour "s'usinagazifier" ... il faut dire que
l'appli a été créé en 5.5 ... avec toutes les mises à jour qui s'imposent
depuis (en 10 pour l'instant) ... et pour prévenir tout débordement, il ne
nous est pas encore possible de recommencer un développement à 0.
J'aurais donc besoin d'un petit retour d'expérience de votre part :
Par exemple, pour une fonction gigantissime de quelques centaines de lignes
(nombreux selons imbriqués) serait-il plus performant d'isoler les codes des
différents cas dans des procedures séparées, la procedure principale ne
contenant que le selon principal et l'appel aux fonctions secondaires ?
Selon choix1
cas 1
30 lignes de code
cas 2
200 lignes de code
cas N
autres cas
fin
ou
Selon choix 1
cas 1 : fonction1()
cas 2 : fonction2()
cas N : fonctionN()
autres cas
fin
De même, notre fenêtre principale contient à l'heure actuelle environ 300
champs (boutons, libellés, tables, ...) cela a t'il un impact sur les
performances et si oui, comment faire pour y remédier ?
Bonjour à tous.
Pour résumer, une grosse procédure ou plusieurs petites, mis à part pour de
questions de maintenance, pas de différence ... ou alors tellement minime que
l'analyseur de performance ne permet pas de les détecter.
Une question néanmoins, avez vous trouver des solutions pour optimiser les
phases d'ouverture et de fermeture de fenêtres ... j'ai régulièrement pour
l'ouverture d'une fenêtre (ouvre normal) le "traitement interne au moteur
d'exécution" qui prends 284ms ... c'est peu pourrait-on dire, mais le
résultat à l'écran donne une impression de lenteur (surtout avec les
problèmes de raffraichissement écran que l'on connait avec windev).
Des solutions ... pour avoir des ouvertures / fermetures de fenêtres plus
réactives ?
Albert P.
Bonjour à tous.
Pour résumer, une grosse procédure ou plusieurs petites, mis à part pour de
questions de maintenance, pas de différence ... ou alors tellement minime que
l'analyseur de performance ne permet pas de les détecter.
Une question néanmoins, avez vous trouver des solutions pour optimiser les
phases d'ouverture et de fermeture de fenêtres ... j'ai régulièrement pour
l'ouverture d'une fenêtre (ouvre normal) le "traitement interne au moteur
d'exécution" qui prends 284ms ... c'est peu pourrait-on dire, mais le
résultat à l'écran donne une impression de lenteur (surtout avec les
problèmes de raffraichissement écran que l'on connait avec windev).
Des solutions ... pour avoir des ouvertures / fermetures de fenêtres plus
réactives ?
Albert P.
Bonjour à tous.
Pour résumer, une grosse procédure ou plusieurs petites, mis à part pour de
questions de maintenance, pas de différence ... ou alors tellement minime que
l'analyseur de performance ne permet pas de les détecter.
Une question néanmoins, avez vous trouver des solutions pour optimiser les
phases d'ouverture et de fermeture de fenêtres ... j'ai régulièrement pour
l'ouverture d'une fenêtre (ouvre normal) le "traitement interne au moteur
d'exécution" qui prends 284ms ... c'est peu pourrait-on dire, mais le
résultat à l'écran donne une impression de lenteur (surtout avec les
problèmes de raffraichissement écran que l'on connait avec windev).
Des solutions ... pour avoir des ouvertures / fermetures de fenêtres plus
réactives ?
Albert P.
Albert P. avait écrit le 22/04/2009 :Bonjour à tous.
Pour résumer, une grosse procédure ou plusieurs petites, mis à part pour
de questions de maintenance, pas de différence ... ou alors tellement
minime que l'analyseur de performance ne permet pas de les détecter.
Une question néanmoins, avez vous trouver des solutions pour optimiser
les phases d'ouverture et de fermeture de fenêtres ... j'ai régulièrement
pour l'ouverture d'une fenêtre (ouvre normal) le "traitement interne au
moteur d'exécution" qui prends 284ms ... c'est peu pourrait-on dire, mais
le résultat à l'écran donne une impression de lenteur (surtout avec les
problèmes de raffraichissement écran que l'on connait avec windev).
Des solutions ... pour avoir des ouvertures / fermetures de fenêtres plus
réactives ?
Albert P.
Des caracs particulières à tes fenêtres ?
Code d'init lourd, multitude de champs, plusieurs tables avec des requêtes
lourdes ?
++
Albert P. avait écrit le 22/04/2009 :
Bonjour à tous.
Pour résumer, une grosse procédure ou plusieurs petites, mis à part pour
de questions de maintenance, pas de différence ... ou alors tellement
minime que l'analyseur de performance ne permet pas de les détecter.
Une question néanmoins, avez vous trouver des solutions pour optimiser
les phases d'ouverture et de fermeture de fenêtres ... j'ai régulièrement
pour l'ouverture d'une fenêtre (ouvre normal) le "traitement interne au
moteur d'exécution" qui prends 284ms ... c'est peu pourrait-on dire, mais
le résultat à l'écran donne une impression de lenteur (surtout avec les
problèmes de raffraichissement écran que l'on connait avec windev).
Des solutions ... pour avoir des ouvertures / fermetures de fenêtres plus
réactives ?
Albert P.
Des caracs particulières à tes fenêtres ?
Code d'init lourd, multitude de champs, plusieurs tables avec des requêtes
lourdes ?
++
Albert P. avait écrit le 22/04/2009 :Bonjour à tous.
Pour résumer, une grosse procédure ou plusieurs petites, mis à part pour
de questions de maintenance, pas de différence ... ou alors tellement
minime que l'analyseur de performance ne permet pas de les détecter.
Une question néanmoins, avez vous trouver des solutions pour optimiser
les phases d'ouverture et de fermeture de fenêtres ... j'ai régulièrement
pour l'ouverture d'une fenêtre (ouvre normal) le "traitement interne au
moteur d'exécution" qui prends 284ms ... c'est peu pourrait-on dire, mais
le résultat à l'écran donne une impression de lenteur (surtout avec les
problèmes de raffraichissement écran que l'on connait avec windev).
Des solutions ... pour avoir des ouvertures / fermetures de fenêtres plus
réactives ?
Albert P.
Des caracs particulières à tes fenêtres ?
Code d'init lourd, multitude de champs, plusieurs tables avec des requêtes
lourdes ?
++
"BrnWrk" a écrit dans le message de news:Albert P. avait écrit le 22/04/2009 :Bonjour à tous.
Pour résumer, une grosse procédure ou plusieurs petites, mis à part pour
de questions de maintenance, pas de différence ... ou alors tellement
minime que l'analyseur de performance ne permet pas de les détecter.
Une question néanmoins, avez vous trouver des solutions pour optimiser
les phases d'ouverture et de fermeture de fenêtres ... j'ai régulièrement
pour l'ouverture d'une fenêtre (ouvre normal) le "traitement interne au
moteur d'exécution" qui prends 284ms ... c'est peu pourrait-on dire, mais
le résultat à l'écran donne une impression de lenteur (surtout avec les
problèmes de raffraichissement écran que l'on connait avec windev).
Des solutions ... pour avoir des ouvertures / fermetures de fenêtres plus
réactives ?
Albert P.
Des caracs particulières à tes fenêtres ?
Code d'init lourd, multitude de champs, plusieurs tables avec des requêtes
lourdes ?
++
Salut,
Pas particulièrement, cela se produit même pour des fenêtres "info" c'est à
dire : 1 champ libellé + 1 bouton fermer. Lors de la fermeture de cette
fenêtre "info", le raffraichissement de la fenêtre appellante se fait par
morceaux ...
Les machines sur lesquelles le phénomène se produit ne sont bien sur pas
très puissante (carte graphique de base, mémoire minimale) ... mais c'est
quand même troublant car cela ne se produit qu'avec des Executables générés
avec windev.
Albert P.
"BrnWrk" <administrator@huh.com> a écrit dans le message de news:
mn.b2297d943c1d8745.85589@huh.com...
Albert P. avait écrit le 22/04/2009 :
Bonjour à tous.
Pour résumer, une grosse procédure ou plusieurs petites, mis à part pour
de questions de maintenance, pas de différence ... ou alors tellement
minime que l'analyseur de performance ne permet pas de les détecter.
Une question néanmoins, avez vous trouver des solutions pour optimiser
les phases d'ouverture et de fermeture de fenêtres ... j'ai régulièrement
pour l'ouverture d'une fenêtre (ouvre normal) le "traitement interne au
moteur d'exécution" qui prends 284ms ... c'est peu pourrait-on dire, mais
le résultat à l'écran donne une impression de lenteur (surtout avec les
problèmes de raffraichissement écran que l'on connait avec windev).
Des solutions ... pour avoir des ouvertures / fermetures de fenêtres plus
réactives ?
Albert P.
Des caracs particulières à tes fenêtres ?
Code d'init lourd, multitude de champs, plusieurs tables avec des requêtes
lourdes ?
++
Salut,
Pas particulièrement, cela se produit même pour des fenêtres "info" c'est à
dire : 1 champ libellé + 1 bouton fermer. Lors de la fermeture de cette
fenêtre "info", le raffraichissement de la fenêtre appellante se fait par
morceaux ...
Les machines sur lesquelles le phénomène se produit ne sont bien sur pas
très puissante (carte graphique de base, mémoire minimale) ... mais c'est
quand même troublant car cela ne se produit qu'avec des Executables générés
avec windev.
Albert P.
"BrnWrk" a écrit dans le message de news:Albert P. avait écrit le 22/04/2009 :Bonjour à tous.
Pour résumer, une grosse procédure ou plusieurs petites, mis à part pour
de questions de maintenance, pas de différence ... ou alors tellement
minime que l'analyseur de performance ne permet pas de les détecter.
Une question néanmoins, avez vous trouver des solutions pour optimiser
les phases d'ouverture et de fermeture de fenêtres ... j'ai régulièrement
pour l'ouverture d'une fenêtre (ouvre normal) le "traitement interne au
moteur d'exécution" qui prends 284ms ... c'est peu pourrait-on dire, mais
le résultat à l'écran donne une impression de lenteur (surtout avec les
problèmes de raffraichissement écran que l'on connait avec windev).
Des solutions ... pour avoir des ouvertures / fermetures de fenêtres plus
réactives ?
Albert P.
Des caracs particulières à tes fenêtres ?
Code d'init lourd, multitude de champs, plusieurs tables avec des requêtes
lourdes ?
++
Salut,
Pas particulièrement, cela se produit même pour des fenêtres "info" c'est à
dire : 1 champ libellé + 1 bouton fermer. Lors de la fermeture de cette
fenêtre "info", le raffraichissement de la fenêtre appellante se fait par
morceaux ...
Les machines sur lesquelles le phénomène se produit ne sont bien sur pas
très puissante (carte graphique de base, mémoire minimale) ... mais c'est
quand même troublant car cela ne se produit qu'avec des Executables générés
avec windev.
Albert P.