Bonsoir,
J'ai développé une "grosse" application qui tourne bien même en HF :')
Le seul "hic" est lié à une fenêtre qui prend un temps fou à s'ouvrir.
Les codes de Déclaration globale se font très rapidemement, les codes situés
dans le traitement d'initialisation aussi (cela consiste en un
hlitrecherchepremier puis un fichierversécran ..sous forme d'une procédure).
Le problème est situé entre les deux ! Cela met plus de 15 secondes entre la
fin des déclaration globales et le démarrage effectif de la lecture du code
de mon traitement d'initialisation. :-@
J'ai même poussé le vice à mettre tout mon code d'initialisation dans le
traitement de déclalation global de la fenêtre. Cela traîne toujours au même
endroit: au moment d'entamer le traitement d'initialisation alors que dans ce
cas là il n'y a plus de code ! :'(
J'en déduit que le logiciel perd du temps lors de l'initialisation des
champs...
Il est vrai qu'il y a 5 à 6 combo (chacunes remplies par une requête
ou un fichier HF), une 10 aine de champs de saisie et 5 à 6 interrupteur?
Alors ? Trop de champs, de combo ? Autre problème ?
Cela est étonnant alors qu'habituellement c'est la lecture des fichiers qui
est lente ....)
Par ailleurs j'ai beaucoups d'autres fenêtres qui s'affiche très vite.
Avez-vous déjà connu ce problème ?
Merci pour votre aide
Bonsoir,
J'ai développé une "grosse" application qui tourne bien même en HF :')
Le seul "hic" est lié à une fenêtre qui prend un temps fou à s'ouvrir.
Les codes de Déclaration globale se font très rapidemement, les codes situés
dans le traitement d'initialisation aussi (cela consiste en un
hlitrecherchepremier puis un fichierversécran ..sous forme d'une procédure).
Le problème est situé entre les deux ! Cela met plus de 15 secondes entre la
fin des déclaration globales et le démarrage effectif de la lecture du code
de mon traitement d'initialisation. :-@
J'ai même poussé le vice à mettre tout mon code d'initialisation dans le
traitement de déclalation global de la fenêtre. Cela traîne toujours au même
endroit: au moment d'entamer le traitement d'initialisation alors que dans ce
cas là il n'y a plus de code ! :'(
J'en déduit que le logiciel perd du temps lors de l'initialisation des
champs...
Il est vrai qu'il y a 5 à 6 combo (chacunes remplies par une requête
ou un fichier HF), une 10 aine de champs de saisie et 5 à 6 interrupteur?
Alors ? Trop de champs, de combo ? Autre problème ?
Cela est étonnant alors qu'habituellement c'est la lecture des fichiers qui
est lente ....)
Par ailleurs j'ai beaucoups d'autres fenêtres qui s'affiche très vite.
Avez-vous déjà connu ce problème ?
Merci pour votre aide
Bonsoir,
J'ai développé une "grosse" application qui tourne bien même en HF :')
Le seul "hic" est lié à une fenêtre qui prend un temps fou à s'ouvrir.
Les codes de Déclaration globale se font très rapidemement, les codes situés
dans le traitement d'initialisation aussi (cela consiste en un
hlitrecherchepremier puis un fichierversécran ..sous forme d'une procédure).
Le problème est situé entre les deux ! Cela met plus de 15 secondes entre la
fin des déclaration globales et le démarrage effectif de la lecture du code
de mon traitement d'initialisation. :-@
J'ai même poussé le vice à mettre tout mon code d'initialisation dans le
traitement de déclalation global de la fenêtre. Cela traîne toujours au même
endroit: au moment d'entamer le traitement d'initialisation alors que dans ce
cas là il n'y a plus de code ! :'(
J'en déduit que le logiciel perd du temps lors de l'initialisation des
champs...
Il est vrai qu'il y a 5 à 6 combo (chacunes remplies par une requête
ou un fichier HF), une 10 aine de champs de saisie et 5 à 6 interrupteur?
Alors ? Trop de champs, de combo ? Autre problème ?
Cela est étonnant alors qu'habituellement c'est la lecture des fichiers qui
est lente ....)
Par ailleurs j'ai beaucoups d'autres fenêtres qui s'affiche très vite.
Avez-vous déjà connu ce problème ?
Merci pour votre aide
Bonsoir,
J'ai développé une "grosse" application qui tourne bien même en HF :')
Le seul "hic" est lié à une fenêtre qui prend un temps fou à s'ouvrir.
Les codes de Déclaration globale se font très rapidemement, les codes
situés dans le traitement d'initialisation aussi (cela consiste en un
hlitrecherchepremier puis un fichierversécran ..sous forme d'une
procédure). Le problème est situé entre les deux ! Cela met plus de 15
secondes entre la fin des déclaration globales et le démarrage effectif
de la lecture du code de mon traitement d'initialisation. :-@
J'ai même poussé le vice à mettre tout mon code d'initialisation dans
le traitement de déclalation global de la fenêtre. Cela traîne toujours
au même endroit: au moment d'entamer le traitement d'initialisation
alors que dans ce cas là il n'y a plus de code ! :'(
J'en déduit que le logiciel perd du temps lors de l'initialisation des
champs...Il est vrai qu'il y a 5 à 6 combo (chacunes remplies par une
requête ou un fichier HF), une 10 aine de champs de saisie et 5 à 6
interrupteur? Alors ? Trop de champs, de combo ? Autre problème ?
Cela est étonnant alors qu'habituellement c'est la lecture des fichiers
qui est lente ....)
Par ailleurs j'ai beaucoups d'autres fenêtres qui s'affiche très vite.
Avez-vous déjà connu ce problème ?
Merci pour votre aide
Bonsoir,
J'ai développé une "grosse" application qui tourne bien même en HF :')
Le seul "hic" est lié à une fenêtre qui prend un temps fou à s'ouvrir.
Les codes de Déclaration globale se font très rapidemement, les codes
situés dans le traitement d'initialisation aussi (cela consiste en un
hlitrecherchepremier puis un fichierversécran ..sous forme d'une
procédure). Le problème est situé entre les deux ! Cela met plus de 15
secondes entre la fin des déclaration globales et le démarrage effectif
de la lecture du code de mon traitement d'initialisation. :-@
J'ai même poussé le vice à mettre tout mon code d'initialisation dans
le traitement de déclalation global de la fenêtre. Cela traîne toujours
au même endroit: au moment d'entamer le traitement d'initialisation
alors que dans ce cas là il n'y a plus de code ! :'(
J'en déduit que le logiciel perd du temps lors de l'initialisation des
champs...Il est vrai qu'il y a 5 à 6 combo (chacunes remplies par une
requête ou un fichier HF), une 10 aine de champs de saisie et 5 à 6
interrupteur? Alors ? Trop de champs, de combo ? Autre problème ?
Cela est étonnant alors qu'habituellement c'est la lecture des fichiers
qui est lente ....)
Par ailleurs j'ai beaucoups d'autres fenêtres qui s'affiche très vite.
Avez-vous déjà connu ce problème ?
Merci pour votre aide
Bonsoir,
J'ai développé une "grosse" application qui tourne bien même en HF :')
Le seul "hic" est lié à une fenêtre qui prend un temps fou à s'ouvrir.
Les codes de Déclaration globale se font très rapidemement, les codes
situés dans le traitement d'initialisation aussi (cela consiste en un
hlitrecherchepremier puis un fichierversécran ..sous forme d'une
procédure). Le problème est situé entre les deux ! Cela met plus de 15
secondes entre la fin des déclaration globales et le démarrage effectif
de la lecture du code de mon traitement d'initialisation. :-@
J'ai même poussé le vice à mettre tout mon code d'initialisation dans
le traitement de déclalation global de la fenêtre. Cela traîne toujours
au même endroit: au moment d'entamer le traitement d'initialisation
alors que dans ce cas là il n'y a plus de code ! :'(
J'en déduit que le logiciel perd du temps lors de l'initialisation des
champs...Il est vrai qu'il y a 5 à 6 combo (chacunes remplies par une
requête ou un fichier HF), une 10 aine de champs de saisie et 5 à 6
interrupteur? Alors ? Trop de champs, de combo ? Autre problème ?
Cela est étonnant alors qu'habituellement c'est la lecture des fichiers
qui est lente ....)
Par ailleurs j'ai beaucoups d'autres fenêtres qui s'affiche très vite.
Avez-vous déjà connu ce problème ?
Merci pour votre aide
Bonsoir,
J'ai développé une "grosse" application qui tourne bien même en HF :')
Le seul "hic" est lié à une fenêtre qui prend un temps fou à s'ouvrir.
Les codes de Déclaration globale se font très rapidemement, les codes
situés dans le traitement d'initialisation aussi (cela consiste en un
hlitrecherchepremier puis un fichierversécran ..sous forme d'une
procédure). Le problème est situé entre les deux ! Cela met plus de 15
secondes entre la fin des déclaration globales et le démarrage effectif
de la lecture du code de mon traitement d'initialisation. :-@
J'ai même poussé le vice à mettre tout mon code d'initialisation dans
le traitement de déclalation global de la fenêtre. Cela traîne toujours
au même endroit: au moment d'entamer le traitement d'initialisation
alors que dans ce cas là il n'y a plus de code ! :'(
J'en déduit que le logiciel perd du temps lors de l'initialisation des
champs...Il est vrai qu'il y a 5 à 6 combo (chacunes remplies par une
requête ou un fichier HF), une 10 aine de champs de saisie et 5 à 6
interrupteur? Alors ? Trop de champs, de combo ? Autre problème ?
Cela est étonnant alors qu'habituellement c'est la lecture des fichiers
qui est lente ....)
Par ailleurs j'ai beaucoups d'autres fenêtres qui s'affiche très vite.
Avez-vous déjà connu ce problème ?
Merci pour votre aide
--
Remove (nospam) from my Email.
Dr J-M des Grottes - HIS-Etterbeek-Ixelles - Nephrology - Belgium
Bonsoir,
J'ai développé une "grosse" application qui tourne bien même en HF :')
Le seul "hic" est lié à une fenêtre qui prend un temps fou à s'ouvrir.
Les codes de Déclaration globale se font très rapidemement, les codes
situés dans le traitement d'initialisation aussi (cela consiste en un
hlitrecherchepremier puis un fichierversécran ..sous forme d'une
procédure). Le problème est situé entre les deux ! Cela met plus de 15
secondes entre la fin des déclaration globales et le démarrage effectif
de la lecture du code de mon traitement d'initialisation. :-@
J'ai même poussé le vice à mettre tout mon code d'initialisation dans
le traitement de déclalation global de la fenêtre. Cela traîne toujours
au même endroit: au moment d'entamer le traitement d'initialisation
alors que dans ce cas là il n'y a plus de code ! :'(
J'en déduit que le logiciel perd du temps lors de l'initialisation des
champs...Il est vrai qu'il y a 5 à 6 combo (chacunes remplies par une
requête ou un fichier HF), une 10 aine de champs de saisie et 5 à 6
interrupteur? Alors ? Trop de champs, de combo ? Autre problème ?
Cela est étonnant alors qu'habituellement c'est la lecture des fichiers
qui est lente ....)
Par ailleurs j'ai beaucoups d'autres fenêtres qui s'affiche très vite.
Avez-vous déjà connu ce problème ?
Merci pour votre aide
--
Remove (nospam) from my Email.
Dr J-M des Grottes - HIS-Etterbeek-Ixelles - Nephrology - Belgium
Bonsoir,
J'ai développé une "grosse" application qui tourne bien même en HF :')
Le seul "hic" est lié à une fenêtre qui prend un temps fou à s'ouvrir.
Les codes de Déclaration globale se font très rapidemement, les codes
situés dans le traitement d'initialisation aussi (cela consiste en un
hlitrecherchepremier puis un fichierversécran ..sous forme d'une
procédure). Le problème est situé entre les deux ! Cela met plus de 15
secondes entre la fin des déclaration globales et le démarrage effectif
de la lecture du code de mon traitement d'initialisation. :-@
J'ai même poussé le vice à mettre tout mon code d'initialisation dans
le traitement de déclalation global de la fenêtre. Cela traîne toujours
au même endroit: au moment d'entamer le traitement d'initialisation
alors que dans ce cas là il n'y a plus de code ! :'(
J'en déduit que le logiciel perd du temps lors de l'initialisation des
champs...Il est vrai qu'il y a 5 à 6 combo (chacunes remplies par une
requête ou un fichier HF), une 10 aine de champs de saisie et 5 à 6
interrupteur? Alors ? Trop de champs, de combo ? Autre problème ?
Cela est étonnant alors qu'habituellement c'est la lecture des fichiers
qui est lente ....)
Par ailleurs j'ai beaucoups d'autres fenêtres qui s'affiche très vite.
Avez-vous déjà connu ce problème ?
Merci pour votre aide
--
Remove (nospam) from my Email.
Dr J-M des Grottes - HIS-Etterbeek-Ixelles - Nephrology - Belgium
Bonsoir,
J'ai développé une "grosse" application qui tourne bien même en HF :')
Le seul "hic" est lié à une fenêtre qui prend un temps fou à s'ouvrir.
Les codes de Déclaration globale se font très rapidemement, les codes
situés dans le traitement d'initialisation aussi (cela consiste en un
hlitrecherchepremier puis un fichierversécran ..sous forme d'une
procédure). Le problème est situé entre les deux ! Cela met plus de 15
secondes entre la fin des déclaration globales et le démarrage effectif
de la lecture du code de mon traitement d'initialisation. :-@
J'ai même poussé le vice à mettre tout mon code d'initialisation dans
le traitement de déclalation global de la fenêtre. Cela traîne toujours
au même endroit: au moment d'entamer le traitement d'initialisation
alors que dans ce cas là il n'y a plus de code ! :'(
J'en déduit que le logiciel perd du temps lors de l'initialisation des
champs...Il est vrai qu'il y a 5 à 6 combo (chacunes remplies par une
requête ou un fichier HF), une 10 aine de champs de saisie et 5 à 6
interrupteur? Alors ? Trop de champs, de combo ? Autre problème ?
Cela est étonnant alors qu'habituellement c'est la lecture des fichiers
qui est lente ....)
Par ailleurs j'ai beaucoups d'autres fenêtres qui s'affiche très vite.
Avez-vous déjà connu ce problème ?
Merci pour votre aide
Bonsoir,
J'ai développé une "grosse" application qui tourne bien même en HF :')
Le seul "hic" est lié à une fenêtre qui prend un temps fou à s'ouvrir.
Les codes de Déclaration globale se font très rapidemement, les codes
situés dans le traitement d'initialisation aussi (cela consiste en un
hlitrecherchepremier puis un fichierversécran ..sous forme d'une
procédure). Le problème est situé entre les deux ! Cela met plus de 15
secondes entre la fin des déclaration globales et le démarrage effectif
de la lecture du code de mon traitement d'initialisation. :-@
J'ai même poussé le vice à mettre tout mon code d'initialisation dans
le traitement de déclalation global de la fenêtre. Cela traîne toujours
au même endroit: au moment d'entamer le traitement d'initialisation
alors que dans ce cas là il n'y a plus de code ! :'(
J'en déduit que le logiciel perd du temps lors de l'initialisation des
champs...Il est vrai qu'il y a 5 à 6 combo (chacunes remplies par une
requête ou un fichier HF), une 10 aine de champs de saisie et 5 à 6
interrupteur? Alors ? Trop de champs, de combo ? Autre problème ?
Cela est étonnant alors qu'habituellement c'est la lecture des fichiers
qui est lente ....)
Par ailleurs j'ai beaucoups d'autres fenêtres qui s'affiche très vite.
Avez-vous déjà connu ce problème ?
Merci pour votre aide
Bonsoir,
J'ai développé une "grosse" application qui tourne bien même en HF :')
Le seul "hic" est lié à une fenêtre qui prend un temps fou à s'ouvrir.
Les codes de Déclaration globale se font très rapidemement, les codes
situés dans le traitement d'initialisation aussi (cela consiste en un
hlitrecherchepremier puis un fichierversécran ..sous forme d'une
procédure). Le problème est situé entre les deux ! Cela met plus de 15
secondes entre la fin des déclaration globales et le démarrage effectif
de la lecture du code de mon traitement d'initialisation. :-@
J'ai même poussé le vice à mettre tout mon code d'initialisation dans
le traitement de déclalation global de la fenêtre. Cela traîne toujours
au même endroit: au moment d'entamer le traitement d'initialisation
alors que dans ce cas là il n'y a plus de code ! :'(
J'en déduit que le logiciel perd du temps lors de l'initialisation des
champs...Il est vrai qu'il y a 5 à 6 combo (chacunes remplies par une
requête ou un fichier HF), une 10 aine de champs de saisie et 5 à 6
interrupteur? Alors ? Trop de champs, de combo ? Autre problème ?
Cela est étonnant alors qu'habituellement c'est la lecture des fichiers
qui est lente ....)
Par ailleurs j'ai beaucoups d'autres fenêtres qui s'affiche très vite.
Avez-vous déjà connu ce problème ?
Merci pour votre aide
J-M des Grottes <jmdg(nospam)@easynet.be> wrote in message
news:...Bonsoir,
J'ai développé une "grosse" application qui tourne bien même en HF :')
Le seul "hic" est lié à une fenêtre qui prend un temps fou à s'ouvrir.
Les codes de Déclaration globale se font très rapidemement, les codes
situés dans le traitement d'initialisation aussi (cela consiste en un
hlitrecherchepremier puis un fichierversécran ..sous forme d'une
procédure). Le problème est situé entre les deux ! Cela met plus de 15
secondes entre la fin des déclaration globales et le démarrage effectif
de la lecture du code de mon traitement d'initialisation. :-@
J'ai même poussé le vice à mettre tout mon code d'initialisation dans
le traitement de déclalation global de la fenêtre. Cela traîne toujours
au même endroit: au moment d'entamer le traitement d'initialisation
alors que dans ce cas là il n'y a plus de code ! :'(
J'en déduit que le logiciel perd du temps lors de l'initialisation des
champs...Il est vrai qu'il y a 5 à 6 combo (chacunes remplies par une
requête ou un fichier HF), une 10 aine de champs de saisie et 5 à 6
interrupteur? Alors ? Trop de champs, de combo ? Autre problème ?
Cela est étonnant alors qu'habituellement c'est la lecture des fichiers
qui est lente ....)
Par ailleurs j'ai beaucoups d'autres fenêtres qui s'affiche très vite.
Avez-vous déjà connu ce problème ?
Merci pour votre aide
Bonjour!
Il est fort probable que ce soit une initialisation de champs qui te
prenne du temps, comme une requête un peu complexe dans une table par
exemple. L'initialisation des champs ce faisant au moment de
l'initialisation de la fenêtre (avant ou après... je ne sais plus...)
la fenêtre met forcément du temps à apparaître dans ce cas.
J'ai eu ce problème sur une fenêtre qui affiche 8 tables différentes
synchronisées, comme les tables sont soit filtrées ou utilisent des
requêtes paramètrées, si je ne saute pas ces requêtes à l'ouverture de
la fenêtre (contrôlé par la propriété 'ouverture'), celle ci met un
temps insuportable à s'afficher.
Pour sauter ces requêtes je met simplement dans le code
d'initialisation des champs concernés:
Si ouverture alors retour
ensuite je déclenche les initialisation des tables que quand
l'utilisateur demande son affichage (en passant par un champ onglet
pour ma part). De cette manière l'affichage est parfaitement
acceptable.
Ci celà peut aider...
BON DEV!
J-M des Grottes <jmdg(nospam)@easynet.be> wrote in message
news:<mn.a04b7d46f784af2b.9842@easynet.be>...
Bonsoir,
J'ai développé une "grosse" application qui tourne bien même en HF :')
Le seul "hic" est lié à une fenêtre qui prend un temps fou à s'ouvrir.
Les codes de Déclaration globale se font très rapidemement, les codes
situés dans le traitement d'initialisation aussi (cela consiste en un
hlitrecherchepremier puis un fichierversécran ..sous forme d'une
procédure). Le problème est situé entre les deux ! Cela met plus de 15
secondes entre la fin des déclaration globales et le démarrage effectif
de la lecture du code de mon traitement d'initialisation. :-@
J'ai même poussé le vice à mettre tout mon code d'initialisation dans
le traitement de déclalation global de la fenêtre. Cela traîne toujours
au même endroit: au moment d'entamer le traitement d'initialisation
alors que dans ce cas là il n'y a plus de code ! :'(
J'en déduit que le logiciel perd du temps lors de l'initialisation des
champs...Il est vrai qu'il y a 5 à 6 combo (chacunes remplies par une
requête ou un fichier HF), une 10 aine de champs de saisie et 5 à 6
interrupteur? Alors ? Trop de champs, de combo ? Autre problème ?
Cela est étonnant alors qu'habituellement c'est la lecture des fichiers
qui est lente ....)
Par ailleurs j'ai beaucoups d'autres fenêtres qui s'affiche très vite.
Avez-vous déjà connu ce problème ?
Merci pour votre aide
Bonjour!
Il est fort probable que ce soit une initialisation de champs qui te
prenne du temps, comme une requête un peu complexe dans une table par
exemple. L'initialisation des champs ce faisant au moment de
l'initialisation de la fenêtre (avant ou après... je ne sais plus...)
la fenêtre met forcément du temps à apparaître dans ce cas.
J'ai eu ce problème sur une fenêtre qui affiche 8 tables différentes
synchronisées, comme les tables sont soit filtrées ou utilisent des
requêtes paramètrées, si je ne saute pas ces requêtes à l'ouverture de
la fenêtre (contrôlé par la propriété 'ouverture'), celle ci met un
temps insuportable à s'afficher.
Pour sauter ces requêtes je met simplement dans le code
d'initialisation des champs concernés:
Si ouverture alors retour
ensuite je déclenche les initialisation des tables que quand
l'utilisateur demande son affichage (en passant par un champ onglet
pour ma part). De cette manière l'affichage est parfaitement
acceptable.
Ci celà peut aider...
BON DEV!
J-M des Grottes <jmdg(nospam)@easynet.be> wrote in message
news:...Bonsoir,
J'ai développé une "grosse" application qui tourne bien même en HF :')
Le seul "hic" est lié à une fenêtre qui prend un temps fou à s'ouvrir.
Les codes de Déclaration globale se font très rapidemement, les codes
situés dans le traitement d'initialisation aussi (cela consiste en un
hlitrecherchepremier puis un fichierversécran ..sous forme d'une
procédure). Le problème est situé entre les deux ! Cela met plus de 15
secondes entre la fin des déclaration globales et le démarrage effectif
de la lecture du code de mon traitement d'initialisation. :-@
J'ai même poussé le vice à mettre tout mon code d'initialisation dans
le traitement de déclalation global de la fenêtre. Cela traîne toujours
au même endroit: au moment d'entamer le traitement d'initialisation
alors que dans ce cas là il n'y a plus de code ! :'(
J'en déduit que le logiciel perd du temps lors de l'initialisation des
champs...Il est vrai qu'il y a 5 à 6 combo (chacunes remplies par une
requête ou un fichier HF), une 10 aine de champs de saisie et 5 à 6
interrupteur? Alors ? Trop de champs, de combo ? Autre problème ?
Cela est étonnant alors qu'habituellement c'est la lecture des fichiers
qui est lente ....)
Par ailleurs j'ai beaucoups d'autres fenêtres qui s'affiche très vite.
Avez-vous déjà connu ce problème ?
Merci pour votre aide
Bonjour!
Il est fort probable que ce soit une initialisation de champs qui te
prenne du temps, comme une requête un peu complexe dans une table par
exemple. L'initialisation des champs ce faisant au moment de
l'initialisation de la fenêtre (avant ou après... je ne sais plus...)
la fenêtre met forcément du temps à apparaître dans ce cas.
J'ai eu ce problème sur une fenêtre qui affiche 8 tables différentes
synchronisées, comme les tables sont soit filtrées ou utilisent des
requêtes paramètrées, si je ne saute pas ces requêtes à l'ouverture de
la fenêtre (contrôlé par la propriété 'ouverture'), celle ci met un
temps insuportable à s'afficher.
Pour sauter ces requêtes je met simplement dans le code
d'initialisation des champs concernés:
Si ouverture alors retour
ensuite je déclenche les initialisation des tables que quand
l'utilisateur demande son affichage (en passant par un champ onglet
pour ma part). De cette manière l'affichage est parfaitement
acceptable.
Ci celà peut aider...
BON DEV!
J-M des Grottes <jmdg(nospam)@easynet.be> wrote in message
news:...Bonsoir,
J'ai développé une "grosse" application qui tourne bien même en HF :')
Le seul "hic" est lié à une fenêtre qui prend un temps fou à s'ouvrir.
Les codes de Déclaration globale se font très rapidemement, les codes
situés dans le traitement d'initialisation aussi (cela consiste en un
hlitrecherchepremier puis un fichierversécran ..sous forme d'une
procédure). Le problème est situé entre les deux ! Cela met plus de 15
secondes entre la fin des déclaration globales et le démarrage effectif
de la lecture du code de mon traitement d'initialisation. :-@
J'ai même poussé le vice à mettre tout mon code d'initialisation dans
le traitement de déclalation global de la fenêtre. Cela traîne toujours
au même endroit: au moment d'entamer le traitement d'initialisation
alors que dans ce cas là il n'y a plus de code ! :'(
J'en déduit que le logiciel perd du temps lors de l'initialisation des
champs...Il est vrai qu'il y a 5 à 6 combo (chacunes remplies par une
requête ou un fichier HF), une 10 aine de champs de saisie et 5 à 6
interrupteur? Alors ? Trop de champs, de combo ? Autre problème ?
Cela est étonnant alors qu'habituellement c'est la lecture des fichiers
qui est lente ....)
Par ailleurs j'ai beaucoups d'autres fenêtres qui s'affiche très vite.
Avez-vous déjà connu ce problème ?
Merci pour votre aide
Bonjour!
Il est fort probable que ce soit une initialisation de champs qui te
prenne du temps, comme une requête un peu complexe dans une table par
exemple. L'initialisation des champs ce faisant au moment de
l'initialisation de la fenêtre (avant ou après... je ne sais plus...)
la fenêtre met forcément du temps à apparaître dans ce cas.
J'ai eu ce problème sur une fenêtre qui affiche 8 tables différentes
synchronisées, comme les tables sont soit filtrées ou utilisent des
requêtes paramètrées, si je ne saute pas ces requêtes à l'ouverture de
la fenêtre (contrôlé par la propriété 'ouverture'), celle ci met un
temps insuportable à s'afficher.
Pour sauter ces requêtes je met simplement dans le code
d'initialisation des champs concernés:
Si ouverture alors retour
ensuite je déclenche les initialisation des tables que quand
l'utilisateur demande son affichage (en passant par un champ onglet
pour ma part). De cette manière l'affichage est parfaitement
acceptable.
Ci celà peut aider...
BON DEV!
J-M des Grottes <jmdg(nospam)@easynet.be> wrote in message
news:<mn.a04b7d46f784af2b.9842@easynet.be>...
Bonsoir,
J'ai développé une "grosse" application qui tourne bien même en HF :')
Le seul "hic" est lié à une fenêtre qui prend un temps fou à s'ouvrir.
Les codes de Déclaration globale se font très rapidemement, les codes
situés dans le traitement d'initialisation aussi (cela consiste en un
hlitrecherchepremier puis un fichierversécran ..sous forme d'une
procédure). Le problème est situé entre les deux ! Cela met plus de 15
secondes entre la fin des déclaration globales et le démarrage effectif
de la lecture du code de mon traitement d'initialisation. :-@
J'ai même poussé le vice à mettre tout mon code d'initialisation dans
le traitement de déclalation global de la fenêtre. Cela traîne toujours
au même endroit: au moment d'entamer le traitement d'initialisation
alors que dans ce cas là il n'y a plus de code ! :'(
J'en déduit que le logiciel perd du temps lors de l'initialisation des
champs...Il est vrai qu'il y a 5 à 6 combo (chacunes remplies par une
requête ou un fichier HF), une 10 aine de champs de saisie et 5 à 6
interrupteur? Alors ? Trop de champs, de combo ? Autre problème ?
Cela est étonnant alors qu'habituellement c'est la lecture des fichiers
qui est lente ....)
Par ailleurs j'ai beaucoups d'autres fenêtres qui s'affiche très vite.
Avez-vous déjà connu ce problème ?
Merci pour votre aide
Bonjour!
Il est fort probable que ce soit une initialisation de champs qui te
prenne du temps, comme une requête un peu complexe dans une table par
exemple. L'initialisation des champs ce faisant au moment de
l'initialisation de la fenêtre (avant ou après... je ne sais plus...)
la fenêtre met forcément du temps à apparaître dans ce cas.
J'ai eu ce problème sur une fenêtre qui affiche 8 tables différentes
synchronisées, comme les tables sont soit filtrées ou utilisent des
requêtes paramètrées, si je ne saute pas ces requêtes à l'ouverture de
la fenêtre (contrôlé par la propriété 'ouverture'), celle ci met un
temps insuportable à s'afficher.
Pour sauter ces requêtes je met simplement dans le code
d'initialisation des champs concernés:
Si ouverture alors retour
ensuite je déclenche les initialisation des tables que quand
l'utilisateur demande son affichage (en passant par un champ onglet
pour ma part). De cette manière l'affichage est parfaitement
acceptable.
Ci celà peut aider...
BON DEV!
J-M des Grottes <jmdg(nospam)@easynet.be> wrote in message
news:...Bonsoir,
J'ai développé une "grosse" application qui tourne bien même en HF :')
Le seul "hic" est lié à une fenêtre qui prend un temps fou à s'ouvrir.
Les codes de Déclaration globale se font très rapidemement, les codes
situés dans le traitement d'initialisation aussi (cela consiste en un
hlitrecherchepremier puis un fichierversécran ..sous forme d'une
procédure). Le problème est situé entre les deux ! Cela met plus de 15
secondes entre la fin des déclaration globales et le démarrage effectif
de la lecture du code de mon traitement d'initialisation. :-@
J'ai même poussé le vice à mettre tout mon code d'initialisation dans
le traitement de déclalation global de la fenêtre. Cela traîne toujours
au même endroit: au moment d'entamer le traitement d'initialisation
alors que dans ce cas là il n'y a plus de code ! :'(
J'en déduit que le logiciel perd du temps lors de l'initialisation des
champs...Il est vrai qu'il y a 5 à 6 combo (chacunes remplies par une
requête ou un fichier HF), une 10 aine de champs de saisie et 5 à 6
interrupteur? Alors ? Trop de champs, de combo ? Autre problème ?
Cela est étonnant alors qu'habituellement c'est la lecture des fichiers
qui est lente ....)
Par ailleurs j'ai beaucoups d'autres fenêtres qui s'affiche très vite.
Avez-vous déjà connu ce problème ?
Merci pour votre aide
Bonjour!
Il est fort probable que ce soit une initialisation de champs qui te
prenne du temps, comme une requête un peu complexe dans une table par
exemple. L'initialisation des champs ce faisant au moment de
l'initialisation de la fenêtre (avant ou après... je ne sais plus...)
la fenêtre met forcément du temps à apparaître dans ce cas.
J'ai eu ce problème sur une fenêtre qui affiche 8 tables différentes
synchronisées, comme les tables sont soit filtrées ou utilisent des
requêtes paramètrées, si je ne saute pas ces requêtes à l'ouverture de
la fenêtre (contrôlé par la propriété 'ouverture'), celle ci met un
temps insuportable à s'afficher.
Pour sauter ces requêtes je met simplement dans le code
d'initialisation des champs concernés:
Si ouverture alors retour
ensuite je déclenche les initialisation des tables que quand
l'utilisateur demande son affichage (en passant par un champ onglet
pour ma part). De cette manière l'affichage est parfaitement
acceptable.
Ci celà peut aider...
BON DEV!
