[WD15] Lenteur de fermeture de fenêtre si un Alias est utilisé
4 réponses
Gilles
Bonjour,
sans espoir, je me demande si quelqu'un d'entre vous a subi ce bug
(visiblement un utilisateur avait le même problème en v14 l'an passé
dans le forum d'en face).
J'ai une appli MDI qui fonctionnait parfaitement en v11.
Migrée en v15, certaines fenêtre mettent de 2 à 30 secondes à se
fermer.
Et il ne se passe rien d'autre, c'est sur le "ferme" que ça bloque.
J'ai remarqué à l'aide du post précédent que c'est l'utilisation d'un
Alias qui provoque cette lenteur.
Si le MDIOuvre est fait sans alias, la fille se ferme instantanément.
En revanche, s'il y a un alias, ca peut durer jusqu'à 30 secondes!!
(Et c'est aléatoire, la même fiche peut se fermer en 2 secondes ou en
30... mais jamais instantanément)
Je leur ai écris. C'est pas si simple à isoler, en fait après tests plus poussés, ca ne se produit que lorsqu'il y a eu accès aux données (en l'occurrence ici avec accès natif MySQL)
Il suffit que j'ai une table fichier connecté à du MySQL, et le fait d'ajouter l'alias provoque le bug.
Sans données dans la fenêtre, ça fonctionne.
Je n'ai pas poussé le vice jusqu'à vérifier que ça le faisait sur HF...
Alex a formulé la demande :
Isoles une fenêtre et envoies la au support.
Alex
Je leur ai écris.
C'est pas si simple à isoler, en fait après tests plus poussés, ca ne
se produit que lorsqu'il y a eu accès aux données (en l'occurrence ici
avec accès natif MySQL)
Il suffit que j'ai une table fichier connecté à du MySQL, et le fait
d'ajouter l'alias provoque le bug.
Sans données dans la fenêtre, ça fonctionne.
Je n'ai pas poussé le vice jusqu'à vérifier que ça le faisait sur HF...
Je leur ai écris. C'est pas si simple à isoler, en fait après tests plus poussés, ca ne se produit que lorsqu'il y a eu accès aux données (en l'occurrence ici avec accès natif MySQL)
Il suffit que j'ai une table fichier connecté à du MySQL, et le fait d'ajouter l'alias provoque le bug.
Sans données dans la fenêtre, ça fonctionne.
Je n'ai pas poussé le vice jusqu'à vérifier que ça le faisait sur HF...
Gilles
Gilles a utilisé son clavier pour écrire :
Bonjour,
sans espoir, je me demande si quelqu'un d'entre vous a subi ce bug (visiblement un utilisateur avait le même problème en v14 l'an passé dans le forum d'en face).
J'ai fini par isoler le problème.
Il existe avec ou sans Alias, mais avec Alias, c'est juste 100 fois pire.
En fait, c'est simplement le fait d'utiliser un InitParametre avec fichier .INI qui fait partir la V15 en vrille!
Au moment où une fenêtre un peu chargée est fermée, Windev sauvegarde tout (position de la fenêtre, des contrôles etc...).
hé bien en .ini, Windev met jusqu'à 30 secondes à générer le .ini (il y a visiblement un gros gros souci dans le code de gstion du .ini de Windev 15)
En remplaçant par un InitParametre en fichier XML, tout redevient instantané!
Cas bien particulier mais qui peut rendre cinglé ;)
Gilles a utilisé son clavier pour écrire :
Bonjour,
sans espoir, je me demande si quelqu'un d'entre vous a subi ce bug
(visiblement un utilisateur avait le même problème en v14 l'an passé dans le
forum d'en face).
J'ai fini par isoler le problème.
Il existe avec ou sans Alias, mais avec Alias, c'est juste 100 fois
pire.
En fait, c'est simplement le fait d'utiliser un InitParametre avec
fichier .INI qui fait partir la V15 en vrille!
Au moment où une fenêtre un peu chargée est fermée, Windev sauvegarde
tout (position de la fenêtre, des contrôles etc...).
hé bien en .ini, Windev met jusqu'à 30 secondes à générer le .ini (il y
a visiblement un gros gros souci dans le code de gstion du .ini de
Windev 15)
En remplaçant par un InitParametre en fichier XML, tout redevient
instantané!
Cas bien particulier mais qui peut rendre cinglé ;)
sans espoir, je me demande si quelqu'un d'entre vous a subi ce bug (visiblement un utilisateur avait le même problème en v14 l'an passé dans le forum d'en face).
J'ai fini par isoler le problème.
Il existe avec ou sans Alias, mais avec Alias, c'est juste 100 fois pire.
En fait, c'est simplement le fait d'utiliser un InitParametre avec fichier .INI qui fait partir la V15 en vrille!
Au moment où une fenêtre un peu chargée est fermée, Windev sauvegarde tout (position de la fenêtre, des contrôles etc...).
hé bien en .ini, Windev met jusqu'à 30 secondes à générer le .ini (il y a visiblement un gros gros souci dans le code de gstion du .ini de Windev 15)
En remplaçant par un InitParametre en fichier XML, tout redevient instantané!
Cas bien particulier mais qui peut rendre cinglé ;)
Pascal F
Gilles a formulé la demande :
Gilles a utilisé son clavier pour écrire :
Bonjour,
sans espoir, je me demande si quelqu'un d'entre vous a subi ce bug (visiblement un utilisateur avait le même problème en v14 l'an passé dans le forum d'en face).
J'ai fini par isoler le problème.
Il existe avec ou sans Alias, mais avec Alias, c'est juste 100 fois pire.
En fait, c'est simplement le fait d'utiliser un InitParametre avec fichier .INI qui fait partir la V15 en vrille!
Au moment où une fenêtre un peu chargée est fermée, Windev sauvegarde tout (position de la fenêtre, des contrôles etc...).
hé bien en .ini, Windev met jusqu'à 30 secondes à générer le .ini (il y a visiblement un gros gros souci dans le code de gstion du .ini de Windev 15)
En remplaçant par un InitParametre en fichier XML, tout redevient instantané!
Cas bien particulier mais qui peut rendre cinglé ;)
Merci de l'info. J'ai le meme problème en WD12. J'avais effectivement commencé par faire un fichier XML, mais en WD12 dans certains cas, le fichier généré ne pouvait être relu. Ayant planifié le passage des mes projet en WD15 pour la semaine prochaine, je vais en profiter pour repasser a un fichier XML. Merci encore pour la soluce.
-- Pascal
Ne garder que le prénom pour me joindre
Gilles a formulé la demande :
Gilles a utilisé son clavier pour écrire :
Bonjour,
sans espoir, je me demande si quelqu'un d'entre vous a subi ce bug
(visiblement un utilisateur avait le même problème en v14 l'an passé dans
le forum d'en face).
J'ai fini par isoler le problème.
Il existe avec ou sans Alias, mais avec Alias, c'est juste 100 fois pire.
En fait, c'est simplement le fait d'utiliser un InitParametre avec fichier
.INI qui fait partir la V15 en vrille!
Au moment où une fenêtre un peu chargée est fermée, Windev sauvegarde tout
(position de la fenêtre, des contrôles etc...).
hé bien en .ini, Windev met jusqu'à 30 secondes à générer le .ini (il y a
visiblement un gros gros souci dans le code de gstion du .ini de Windev 15)
En remplaçant par un InitParametre en fichier XML, tout redevient instantané!
Cas bien particulier mais qui peut rendre cinglé ;)
Merci de l'info. J'ai le meme problème en WD12. J'avais effectivement
commencé par faire un fichier XML, mais en WD12 dans certains cas, le
fichier généré ne pouvait être relu. Ayant planifié le passage des mes
projet en WD15 pour la semaine prochaine, je vais en profiter pour
repasser a un fichier XML.
Merci encore pour la soluce.
--
Pascal
N0.pascal.SPAM@efpe.biz
Ne garder que le prénom pour me joindre
sans espoir, je me demande si quelqu'un d'entre vous a subi ce bug (visiblement un utilisateur avait le même problème en v14 l'an passé dans le forum d'en face).
J'ai fini par isoler le problème.
Il existe avec ou sans Alias, mais avec Alias, c'est juste 100 fois pire.
En fait, c'est simplement le fait d'utiliser un InitParametre avec fichier .INI qui fait partir la V15 en vrille!
Au moment où une fenêtre un peu chargée est fermée, Windev sauvegarde tout (position de la fenêtre, des contrôles etc...).
hé bien en .ini, Windev met jusqu'à 30 secondes à générer le .ini (il y a visiblement un gros gros souci dans le code de gstion du .ini de Windev 15)
En remplaçant par un InitParametre en fichier XML, tout redevient instantané!
Cas bien particulier mais qui peut rendre cinglé ;)
Merci de l'info. J'ai le meme problème en WD12. J'avais effectivement commencé par faire un fichier XML, mais en WD12 dans certains cas, le fichier généré ne pouvait être relu. Ayant planifié le passage des mes projet en WD15 pour la semaine prochaine, je vais en profiter pour repasser a un fichier XML. Merci encore pour la soluce.
