Je suis confronté à un problème qui dépasse ma maigre intelligence.
Sur un réseau 3 postes ( Terminaux point de vente à base de céleron, 512Mo
ou 1Go de ram, XP Pro, 100Mb/s - TCP/IP) j'ai des ralentissements que je ne
m'explique pas.
Sur l'affichage d'un plan de salle - un champ image sur lequel je viens
dessiner des tables par copie d'une image (dcopieimage) sur l'image
principal qui contient le dessin de la salle, j'ai des ralentissement énorme
sur l'affectation de l'image monimage = "x:\rep_image\table1.png". En
passant par l'analyseur de perf, cette fonction met 42 secondes pour faire
182 affectations. X etant un lecteur réseau sur le poste "serveur". Si je
fais la même chose en copiant les png (chaque image fait 40x80 pixel ....)
en local sur le poste, la même instruction met 340ms pour les 182
affectations.
Dans le même ordre d'idée, un simple tableajoute dans un champ table à 2
colonne (index + valeur) met 7 à 8 secondes pour les 182 tableajoute ...
c'est un peu du n'importe quoi.
Pour couronner le tout, une vue sur un fichier HF qui contient 200
enregistrement met 7 secondes ...
Le problème vient des machines car lorsque je me connecte depuis mon poste
de développement sur le même "serveur" mes résultat sont tout à fait
cohérent par rapport à la taille des fichiers manipulés.
Si l'un d'entre vous avait une piste ... je lui en serais grandement
reconnaissant.
Pour info, j'ai regardé un peu ce qui se passe avec l'analyseur de perf ...
sur ma machine proc1 (core2 duo) à 50% sur le TPV celeron à 100%
Utilisation du réseau ... ne dépasse pas les 3%. Utilisation de la mémoire
physique du PC 50% ( avec 28Mo pour l'exe en question) Nombre d'objet GDI
540, OBJET USER 320 (sachant que l'explorer windows utilise sur ma machine
800+ Objet GDI et 360 Objets User)
Autre information, avec une autre base ( même analyse, données clients
différentes) j'ai des temps qui sont tout à fait normaux par rapport à ce
dont on a l'habitude avec windev. Les fichiers ont été re-indexé, regénéré
(par hcopieenreg sur un fichier neuf), rien n'y fait.
Bah ... j'y ai pensé ... mais comment expliquer que cela fonctionne correctement avec un jeu de fichier et pas avec un autre ? sur la même configuration matérielle ... seul les .fic et .ndx changent.
Albert P.
C'est bien ce que je voulais dire...
-- TT
Merci pour cette piste, mais :-(
Je viens de faire des tests en desactivant les oplocks (sur tous les postes - service lanmanager et MRXSmb ... pas de modification majeures des perfs.
J'ai souvenir qu'a une époque (5.5 sur windows 95/98) on pouvait avec des problèmes avec des applications "lourdes" avec beaucoup de champ, ces limitations sont elles toujours d'actualités en 10-14 sur du XP/Vista ???
Albert P.
Les oplocks sont en principe gérées sur le serveur.
-- TT
[...]
Bah ... j'y ai pensé ... mais comment expliquer que cela fonctionne
correctement avec un jeu de fichier et pas avec un autre ? sur la même
configuration matérielle ... seul les .fic et .ndx changent.
Albert P.
C'est bien ce que je voulais dire...
--
TT
Merci pour cette piste, mais :-(
Je viens de faire des tests en desactivant les oplocks (sur tous les
postes - service lanmanager et MRXSmb ... pas de modification majeures
des
perfs.
J'ai souvenir qu'a une époque (5.5 sur windows 95/98) on pouvait avec des
problèmes avec des applications "lourdes" avec beaucoup de champ, ces
limitations sont elles toujours d'actualités en 10-14 sur du XP/Vista ???
Albert P.
Les oplocks sont en principe gérées sur le serveur.
Bah ... j'y ai pensé ... mais comment expliquer que cela fonctionne correctement avec un jeu de fichier et pas avec un autre ? sur la même configuration matérielle ... seul les .fic et .ndx changent.
Albert P.
C'est bien ce que je voulais dire...
-- TT
Merci pour cette piste, mais :-(
Je viens de faire des tests en desactivant les oplocks (sur tous les postes - service lanmanager et MRXSmb ... pas de modification majeures des perfs.
J'ai souvenir qu'a une époque (5.5 sur windows 95/98) on pouvait avec des problèmes avec des applications "lourdes" avec beaucoup de champ, ces limitations sont elles toujours d'actualités en 10-14 sur du XP/Vista ???
Albert P.
Les oplocks sont en principe gérées sur le serveur.
-- TT
STASZEWSKI André
SAlut Albert
As-tu essayé ça : Sur les postes XP, XP Pro concerné, désactive la gestion des points de restauration. Poste de travail. > Propriétés > Restauration du système Cocher "Désactiver la restauration du système" et appliquer. -- Cordialement, André STASZEWSKI (Gratuit) Photo Visu et Cut Data Radars sur http://pagesperso-orange.fr/mdev/ Pour me contacter, cliquez ici : http://cerbermail.com/?OT0Wnwyzph
"Albert P." a écrit dans le message de news: 4a66ba3c$0$17766$
Bonjour,
Je suis confronté à un problème qui dépasse ma maigre intelligence.
Sur un réseau 3 postes ( Terminaux point de vente à base de céleron, 512Mo ou 1Go de ram, XP Pro, 100Mb/s - TCP/IP) j'ai des ralentissements que je ne m'explique pas.
Sur l'affichage d'un plan de salle - un champ image sur lequel je viens dessiner des tables par copie d'une image (dcopieimage) sur l'image principal qui contient le dessin de la salle, j'ai des ralentissement énorme sur l'affectation de l'image monimage = "x:rep_imagetable1.png". En passant par l'analyseur de perf, cette fonction met 42 secondes pour faire 182 affectations. X etant un lecteur réseau sur le poste "serveur". Si je fais la même chose en copiant les png (chaque image fait 40x80 pixel ....) en local sur le poste, la même instruction met 340ms pour les 182 affectations.
Dans le même ordre d'idée, un simple tableajoute dans un champ table à 2 colonne (index + valeur) met 7 à 8 secondes pour les 182 tableajoute ... c'est un peu du n'importe quoi.
Pour couronner le tout, une vue sur un fichier HF qui contient 200 enregistrement met 7 secondes ...
Le problème vient des machines car lorsque je me connecte depuis mon poste de développement sur le même "serveur" mes résultat sont tout à fait cohérent par rapport à la taille des fichiers manipulés.
Si l'un d'entre vous avait une piste ... je lui en serais grandement reconnaissant.
Pour info, j'ai regardé un peu ce qui se passe avec l'analyseur de perf ... sur ma machine proc1 (core2 duo) à 50% sur le TPV celeron à 100% Utilisation du réseau ... ne dépasse pas les 3%. Utilisation de la mémoire physique du PC 50% ( avec 28Mo pour l'exe en question) Nombre d'objet GDI 540, OBJET USER 320 (sachant que l'explorer windows utilise sur ma machine 800+ Objet GDI et 360 Objets User)
Autre information, avec une autre base ( même analyse, données clients différentes) j'ai des temps qui sont tout à fait normaux par rapport à ce dont on a l'habitude avec windev. Les fichiers ont été re-indexé, regénéré (par hcopieenreg sur un fichier neuf), rien n'y fait.
Merci d'avance pour vos suggestions.
Albert P.
SAlut Albert
As-tu essayé ça :
Sur les postes XP, XP Pro concerné, désactive la gestion des points de
restauration.
Poste de travail. > Propriétés > Restauration du système
Cocher "Désactiver la restauration du système" et appliquer.
--
Cordialement,
André STASZEWSKI
(Gratuit) Photo Visu et Cut Data Radars sur
http://pagesperso-orange.fr/mdev/
Pour me contacter, cliquez ici :
http://cerbermail.com/?OT0Wnwyzph
"Albert P." <Inco@gnito.com> a écrit dans le message de news:
4a66ba3c$0$17766$ba4acef3@news.orange.fr...
Bonjour,
Je suis confronté à un problème qui dépasse ma maigre intelligence.
Sur un réseau 3 postes ( Terminaux point de vente à base de céleron, 512Mo
ou 1Go de ram, XP Pro, 100Mb/s - TCP/IP) j'ai des ralentissements que je
ne m'explique pas.
Sur l'affichage d'un plan de salle - un champ image sur lequel je viens
dessiner des tables par copie d'une image (dcopieimage) sur l'image
principal qui contient le dessin de la salle, j'ai des ralentissement
énorme sur l'affectation de l'image monimage = "x:rep_imagetable1.png".
En passant par l'analyseur de perf, cette fonction met 42 secondes pour
faire 182 affectations. X etant un lecteur réseau sur le poste "serveur".
Si je fais la même chose en copiant les png (chaque image fait 40x80 pixel
....) en local sur le poste, la même instruction met 340ms pour les 182
affectations.
Dans le même ordre d'idée, un simple tableajoute dans un champ table à 2
colonne (index + valeur) met 7 à 8 secondes pour les 182 tableajoute ...
c'est un peu du n'importe quoi.
Pour couronner le tout, une vue sur un fichier HF qui contient 200
enregistrement met 7 secondes ...
Le problème vient des machines car lorsque je me connecte depuis mon poste
de développement sur le même "serveur" mes résultat sont tout à fait
cohérent par rapport à la taille des fichiers manipulés.
Si l'un d'entre vous avait une piste ... je lui en serais grandement
reconnaissant.
Pour info, j'ai regardé un peu ce qui se passe avec l'analyseur de perf
... sur ma machine proc1 (core2 duo) à 50% sur le TPV celeron à 100%
Utilisation du réseau ... ne dépasse pas les 3%. Utilisation de la mémoire
physique du PC 50% ( avec 28Mo pour l'exe en question) Nombre d'objet GDI
540, OBJET USER 320 (sachant que l'explorer windows utilise sur ma machine
800+ Objet GDI et 360 Objets User)
Autre information, avec une autre base ( même analyse, données clients
différentes) j'ai des temps qui sont tout à fait normaux par rapport à ce
dont on a l'habitude avec windev. Les fichiers ont été re-indexé, regénéré
(par hcopieenreg sur un fichier neuf), rien n'y fait.
As-tu essayé ça : Sur les postes XP, XP Pro concerné, désactive la gestion des points de restauration. Poste de travail. > Propriétés > Restauration du système Cocher "Désactiver la restauration du système" et appliquer. -- Cordialement, André STASZEWSKI (Gratuit) Photo Visu et Cut Data Radars sur http://pagesperso-orange.fr/mdev/ Pour me contacter, cliquez ici : http://cerbermail.com/?OT0Wnwyzph
"Albert P." a écrit dans le message de news: 4a66ba3c$0$17766$
Bonjour,
Je suis confronté à un problème qui dépasse ma maigre intelligence.
Sur un réseau 3 postes ( Terminaux point de vente à base de céleron, 512Mo ou 1Go de ram, XP Pro, 100Mb/s - TCP/IP) j'ai des ralentissements que je ne m'explique pas.
Sur l'affichage d'un plan de salle - un champ image sur lequel je viens dessiner des tables par copie d'une image (dcopieimage) sur l'image principal qui contient le dessin de la salle, j'ai des ralentissement énorme sur l'affectation de l'image monimage = "x:rep_imagetable1.png". En passant par l'analyseur de perf, cette fonction met 42 secondes pour faire 182 affectations. X etant un lecteur réseau sur le poste "serveur". Si je fais la même chose en copiant les png (chaque image fait 40x80 pixel ....) en local sur le poste, la même instruction met 340ms pour les 182 affectations.
Dans le même ordre d'idée, un simple tableajoute dans un champ table à 2 colonne (index + valeur) met 7 à 8 secondes pour les 182 tableajoute ... c'est un peu du n'importe quoi.
Pour couronner le tout, une vue sur un fichier HF qui contient 200 enregistrement met 7 secondes ...
Le problème vient des machines car lorsque je me connecte depuis mon poste de développement sur le même "serveur" mes résultat sont tout à fait cohérent par rapport à la taille des fichiers manipulés.
Si l'un d'entre vous avait une piste ... je lui en serais grandement reconnaissant.
Pour info, j'ai regardé un peu ce qui se passe avec l'analyseur de perf ... sur ma machine proc1 (core2 duo) à 50% sur le TPV celeron à 100% Utilisation du réseau ... ne dépasse pas les 3%. Utilisation de la mémoire physique du PC 50% ( avec 28Mo pour l'exe en question) Nombre d'objet GDI 540, OBJET USER 320 (sachant que l'explorer windows utilise sur ma machine 800+ Objet GDI et 360 Objets User)
Autre information, avec une autre base ( même analyse, données clients différentes) j'ai des temps qui sont tout à fait normaux par rapport à ce dont on a l'habitude avec windev. Les fichiers ont été re-indexé, regénéré (par hcopieenreg sur un fichier neuf), rien n'y fait.
Merci d'avance pour vos suggestions.
Albert P.
Albert P.
"news.online.fr" a écrit dans le message de news:
Le Thu, 23 Jul 2009 10:25:38 +0200, Albert P. a écrit:
[...]
-- TT
Merci pour cette piste, mais :-(
Je viens de faire des tests en desactivant les oplocks (sur tous les postes - service lanmanager et MRXSmb ... pas de modification majeures des perfs.
J'ai souvenir qu'a une époque (5.5 sur windows 95/98) on pouvait avec des problèmes avec des applications "lourdes" avec beaucoup de champ, ces limitations sont elles toujours d'actualités en 10-14 sur du XP/Vista ???
Albert P.
Les oplocks se gèrent surtout sur le serveur , pas sur les postes.
-- TT
Salut,
D'apres les recherches que j'ai effecuté (google oplocks + windev) il en ressort qu'effectivement il y'a une clé a rajouter sur le serveur ... mais qu'il y'a une aussi sur les clients ... j'ai de toute façon fait le test avec uniquement le serveur modifié puis serveur et clients ... pas de changements.
A titre informatif, une simple compilation en 14 améliore grandement les perfs ... somme nous victime d'un bug de la 10-12 corrigé en 14 ??? Je poursuis mes tests.
Albert P.
"news.online.fr" <thumain.th@invalid.fr> a écrit dans le message de news:
op.uxir15w5y5mqpu@jbxp.scrim.fr...
Le Thu, 23 Jul 2009 10:25:38 +0200, Albert P. <Inco@gnito.com> a écrit:
[...]
--
TT
Merci pour cette piste, mais :-(
Je viens de faire des tests en desactivant les oplocks (sur tous les
postes - service lanmanager et MRXSmb ... pas de modification majeures
des
perfs.
J'ai souvenir qu'a une époque (5.5 sur windows 95/98) on pouvait avec des
problèmes avec des applications "lourdes" avec beaucoup de champ, ces
limitations sont elles toujours d'actualités en 10-14 sur du XP/Vista ???
Albert P.
Les oplocks se gèrent surtout sur le serveur , pas sur les postes.
--
TT
Salut,
D'apres les recherches que j'ai effecuté (google oplocks + windev) il en
ressort qu'effectivement il y'a une clé a rajouter sur le serveur ... mais
qu'il y'a une aussi sur les clients ... j'ai de toute façon fait le test
avec uniquement le serveur modifié puis serveur et clients ... pas de
changements.
A titre informatif, une simple compilation en 14 améliore grandement les
perfs ... somme nous victime d'un bug de la 10-12 corrigé en 14 ??? Je
poursuis mes tests.
Le Thu, 23 Jul 2009 10:25:38 +0200, Albert P. a écrit:
[...]
-- TT
Merci pour cette piste, mais :-(
Je viens de faire des tests en desactivant les oplocks (sur tous les postes - service lanmanager et MRXSmb ... pas de modification majeures des perfs.
J'ai souvenir qu'a une époque (5.5 sur windows 95/98) on pouvait avec des problèmes avec des applications "lourdes" avec beaucoup de champ, ces limitations sont elles toujours d'actualités en 10-14 sur du XP/Vista ???
Albert P.
Les oplocks se gèrent surtout sur le serveur , pas sur les postes.
-- TT
Salut,
D'apres les recherches que j'ai effecuté (google oplocks + windev) il en ressort qu'effectivement il y'a une clé a rajouter sur le serveur ... mais qu'il y'a une aussi sur les clients ... j'ai de toute façon fait le test avec uniquement le serveur modifié puis serveur et clients ... pas de changements.
A titre informatif, une simple compilation en 14 améliore grandement les perfs ... somme nous victime d'un bug de la 10-12 corrigé en 14 ??? Je poursuis mes tests.
Albert P.
Albert P.
"Albert P." a écrit dans le message de news: 4a66ba3c$0$17766$
Bonjour,
Je suis confronté à un problème qui dépasse ma maigre intelligence.
Sur un réseau 3 postes ( Terminaux point de vente à base de céleron, 512Mo ou 1Go de ram, XP Pro, 100Mb/s - TCP/IP) j'ai des ralentissements que je ne m'explique pas.
Sur l'affichage d'un plan de salle - un champ image sur lequel je viens dessiner des tables par copie d'une image (dcopieimage) sur l'image principal qui contient le dessin de la salle, j'ai des ralentissement énorme sur l'affectation de l'image monimage = "x:rep_imagetable1.png". En passant par l'analyseur de perf, cette fonction met 42 secondes pour faire 182 affectations. X etant un lecteur réseau sur le poste "serveur". Si je fais la même chose en copiant les png (chaque image fait 40x80 pixel ....) en local sur le poste, la même instruction met 340ms pour les 182 affectations.
Dans le même ordre d'idée, un simple tableajoute dans un champ table à 2 colonne (index + valeur) met 7 à 8 secondes pour les 182 tableajoute ... c'est un peu du n'importe quoi.
Pour couronner le tout, une vue sur un fichier HF qui contient 200 enregistrement met 7 secondes ...
Le problème vient des machines car lorsque je me connecte depuis mon poste de développement sur le même "serveur" mes résultat sont tout à fait cohérent par rapport à la taille des fichiers manipulés.
Si l'un d'entre vous avait une piste ... je lui en serais grandement reconnaissant.
Pour info, j'ai regardé un peu ce qui se passe avec l'analyseur de perf ... sur ma machine proc1 (core2 duo) à 50% sur le TPV celeron à 100% Utilisation du réseau ... ne dépasse pas les 3%. Utilisation de la mémoire physique du PC 50% ( avec 28Mo pour l'exe en question) Nombre d'objet GDI 540, OBJET USER 320 (sachant que l'explorer windows utilise sur ma machine 800+ Objet GDI et 360 Objets User)
Autre information, avec une autre base ( même analyse, données clients différentes) j'ai des temps qui sont tout à fait normaux par rapport à ce dont on a l'habitude avec windev. Les fichiers ont été re-indexé, regénéré (par hcopieenreg sur un fichier neuf), rien n'y fait.
Merci d'avance pour vos suggestions.
Albert P.
Bonjour,
Pour clore ce thread, en fait tous mes problèmes étaient liés à la propriété mafenetre..affichageactif = faux.
Mon prédécesseur bloquait l'affichage de la fenêtre mère pour empécher le raffraichissement disgracieux de l'écran ... manque de bol, il ne le réactivait pas avant l'ouverture d'une fenêtre fille (ouvre) comme précisé par Romain PETIT dans la thread [WD10] Timersys. Cette propriété peut avoir des effets de bords assez pénalisant.
Dans mon cas, ce n'était pas le réseau qui était lent ... mais le fait que windows tentait vainement de mettre à jour l'affichage de la fenêtre mère d'ou la lenteur de img = "c:testmonimage.png"
On en apprend tous les jours.
Bon dev à tous,
Albert P.
"Albert P." <Inco@gnito.com> a écrit dans le message de news:
4a66ba3c$0$17766$ba4acef3@news.orange.fr...
Bonjour,
Je suis confronté à un problème qui dépasse ma maigre intelligence.
Sur un réseau 3 postes ( Terminaux point de vente à base de céleron, 512Mo
ou 1Go de ram, XP Pro, 100Mb/s - TCP/IP) j'ai des ralentissements que je
ne m'explique pas.
Sur l'affichage d'un plan de salle - un champ image sur lequel je viens
dessiner des tables par copie d'une image (dcopieimage) sur l'image
principal qui contient le dessin de la salle, j'ai des ralentissement
énorme sur l'affectation de l'image monimage = "x:rep_imagetable1.png".
En passant par l'analyseur de perf, cette fonction met 42 secondes pour
faire 182 affectations. X etant un lecteur réseau sur le poste "serveur".
Si je fais la même chose en copiant les png (chaque image fait 40x80 pixel
....) en local sur le poste, la même instruction met 340ms pour les 182
affectations.
Dans le même ordre d'idée, un simple tableajoute dans un champ table à 2
colonne (index + valeur) met 7 à 8 secondes pour les 182 tableajoute ...
c'est un peu du n'importe quoi.
Pour couronner le tout, une vue sur un fichier HF qui contient 200
enregistrement met 7 secondes ...
Le problème vient des machines car lorsque je me connecte depuis mon poste
de développement sur le même "serveur" mes résultat sont tout à fait
cohérent par rapport à la taille des fichiers manipulés.
Si l'un d'entre vous avait une piste ... je lui en serais grandement
reconnaissant.
Pour info, j'ai regardé un peu ce qui se passe avec l'analyseur de perf
... sur ma machine proc1 (core2 duo) à 50% sur le TPV celeron à 100%
Utilisation du réseau ... ne dépasse pas les 3%. Utilisation de la mémoire
physique du PC 50% ( avec 28Mo pour l'exe en question) Nombre d'objet GDI
540, OBJET USER 320 (sachant que l'explorer windows utilise sur ma machine
800+ Objet GDI et 360 Objets User)
Autre information, avec une autre base ( même analyse, données clients
différentes) j'ai des temps qui sont tout à fait normaux par rapport à ce
dont on a l'habitude avec windev. Les fichiers ont été re-indexé, regénéré
(par hcopieenreg sur un fichier neuf), rien n'y fait.
Merci d'avance pour vos suggestions.
Albert P.
Bonjour,
Pour clore ce thread, en fait tous mes problèmes étaient liés à la propriété
mafenetre..affichageactif = faux.
Mon prédécesseur bloquait l'affichage de la fenêtre mère pour empécher le
raffraichissement disgracieux de l'écran ... manque de bol, il ne le
réactivait pas avant l'ouverture d'une fenêtre fille (ouvre) comme précisé
par Romain PETIT dans la thread [WD10] Timersys. Cette propriété peut avoir
des effets de bords assez pénalisant.
Dans mon cas, ce n'était pas le réseau qui était lent ... mais le fait que
windows tentait vainement de mettre à jour l'affichage de la fenêtre mère
d'ou la lenteur de img = "c:testmonimage.png"
"Albert P." a écrit dans le message de news: 4a66ba3c$0$17766$
Bonjour,
Je suis confronté à un problème qui dépasse ma maigre intelligence.
Sur un réseau 3 postes ( Terminaux point de vente à base de céleron, 512Mo ou 1Go de ram, XP Pro, 100Mb/s - TCP/IP) j'ai des ralentissements que je ne m'explique pas.
Sur l'affichage d'un plan de salle - un champ image sur lequel je viens dessiner des tables par copie d'une image (dcopieimage) sur l'image principal qui contient le dessin de la salle, j'ai des ralentissement énorme sur l'affectation de l'image monimage = "x:rep_imagetable1.png". En passant par l'analyseur de perf, cette fonction met 42 secondes pour faire 182 affectations. X etant un lecteur réseau sur le poste "serveur". Si je fais la même chose en copiant les png (chaque image fait 40x80 pixel ....) en local sur le poste, la même instruction met 340ms pour les 182 affectations.
Dans le même ordre d'idée, un simple tableajoute dans un champ table à 2 colonne (index + valeur) met 7 à 8 secondes pour les 182 tableajoute ... c'est un peu du n'importe quoi.
Pour couronner le tout, une vue sur un fichier HF qui contient 200 enregistrement met 7 secondes ...
Le problème vient des machines car lorsque je me connecte depuis mon poste de développement sur le même "serveur" mes résultat sont tout à fait cohérent par rapport à la taille des fichiers manipulés.
Si l'un d'entre vous avait une piste ... je lui en serais grandement reconnaissant.
Pour info, j'ai regardé un peu ce qui se passe avec l'analyseur de perf ... sur ma machine proc1 (core2 duo) à 50% sur le TPV celeron à 100% Utilisation du réseau ... ne dépasse pas les 3%. Utilisation de la mémoire physique du PC 50% ( avec 28Mo pour l'exe en question) Nombre d'objet GDI 540, OBJET USER 320 (sachant que l'explorer windows utilise sur ma machine 800+ Objet GDI et 360 Objets User)
Autre information, avec une autre base ( même analyse, données clients différentes) j'ai des temps qui sont tout à fait normaux par rapport à ce dont on a l'habitude avec windev. Les fichiers ont été re-indexé, regénéré (par hcopieenreg sur un fichier neuf), rien n'y fait.
Merci d'avance pour vos suggestions.
Albert P.
Bonjour,
Pour clore ce thread, en fait tous mes problèmes étaient liés à la propriété mafenetre..affichageactif = faux.
Mon prédécesseur bloquait l'affichage de la fenêtre mère pour empécher le raffraichissement disgracieux de l'écran ... manque de bol, il ne le réactivait pas avant l'ouverture d'une fenêtre fille (ouvre) comme précisé par Romain PETIT dans la thread [WD10] Timersys. Cette propriété peut avoir des effets de bords assez pénalisant.
Dans mon cas, ce n'était pas le réseau qui était lent ... mais le fait que windows tentait vainement de mettre à jour l'affichage de la fenêtre mère d'ou la lenteur de img = "c:testmonimage.png"
On en apprend tous les jours.
Bon dev à tous,
Albert P.
TT.online.fr
Le Wed, 29 Jul 2009 09:37:14 +0200, Albert P. a écrit:
"Albert P." a écrit dans le message de news: 4a66ba3c$0$17766$
Bonjour,
[...]
Bonjour,
Pour clore ce thread, en fait tous mes problèmes étaient liés à la propriété mafenetre..affichageactif = faux.
Mon prédécesseur bloquait l'affichage de la fenêtre mère pour empécher le raffraichissement disgracieux de l'écran ... manque de bol, il ne le réactivait pas avant l'ouverture d'une fenêtre fille (ouvre) comme précisé par Romain PETIT dans la thread [WD10] Timersys. Cette propriété peut avoir des effets de bords assez pénalisant.
Dans mon cas, ce n'était pas le réseau qui était lent ... mais le fait que windows tentait vainement de mettre à jour l'affichage de la fenêtre mère d'ou la lenteur de img = "c:testmonimage.png"
On en apprend tous les jours.
Bon dev à tous,
Albert P.
Eh beh... bravo!
-- TT
Le Wed, 29 Jul 2009 09:37:14 +0200, Albert P. <Inco@gnito.com> a écrit:
"Albert P." <Inco@gnito.com> a écrit dans le message de news:
4a66ba3c$0$17766$ba4acef3@news.orange.fr...
Bonjour,
[...]
Bonjour,
Pour clore ce thread, en fait tous mes problèmes étaient liés à la
propriété
mafenetre..affichageactif = faux.
Mon prédécesseur bloquait l'affichage de la fenêtre mère pour empécher le
raffraichissement disgracieux de l'écran ... manque de bol, il ne le
réactivait pas avant l'ouverture d'une fenêtre fille (ouvre) comme
précisé
par Romain PETIT dans la thread [WD10] Timersys. Cette propriété peut
avoir
des effets de bords assez pénalisant.
Dans mon cas, ce n'était pas le réseau qui était lent ... mais le fait
que
windows tentait vainement de mettre à jour l'affichage de la fenêtre mère
d'ou la lenteur de img = "c:testmonimage.png"
Le Wed, 29 Jul 2009 09:37:14 +0200, Albert P. a écrit:
"Albert P." a écrit dans le message de news: 4a66ba3c$0$17766$
Bonjour,
[...]
Bonjour,
Pour clore ce thread, en fait tous mes problèmes étaient liés à la propriété mafenetre..affichageactif = faux.
Mon prédécesseur bloquait l'affichage de la fenêtre mère pour empécher le raffraichissement disgracieux de l'écran ... manque de bol, il ne le réactivait pas avant l'ouverture d'une fenêtre fille (ouvre) comme précisé par Romain PETIT dans la thread [WD10] Timersys. Cette propriété peut avoir des effets de bords assez pénalisant.
Dans mon cas, ce n'était pas le réseau qui était lent ... mais le fait que windows tentait vainement de mettre à jour l'affichage de la fenêtre mère d'ou la lenteur de img = "c:testmonimage.png"
