HLitBloque a des longueurs sur des enregistrement "bloqués" ??
8 réponses
deg
(copie d'un message passé sur forum officiel pcsoft, au cas z'où)
Bonjour,
débutant en windev, je lis ce forum depuis qqes temps et ai fait
quelques
recherches dans les archives mais sans vraiment trouver de réponses à
mon
problème.
L'état des lieu:
un programme tournant en windev5.5 et utilisant un RAD "RADTabHF" pour
gérer des blocages d'enregistrement. N'étant point le concepteur
originel
de cette fenêtre je vais essayer de donner un max de renseignement
(enfin
ceux que j'ai trouvé ;) ).
Le programme utilise donc les méthodes de la classe RADTabHF générée
par
Windev automatiquement. Sur entrée dans chaque ligne de la table
lisant le
fichier "CLIENT" (nom fictif), une méthode RADTab:BloqueLigne() est
lancée.
Dans cette méthode la fonction HLitBloque est utilisée et dans le cas
où
l'enregistrement est effectivement bloqué cette fonction met un temps
assez
important à s'exécuter... Sur mon fichier de test tout petit, jusqu'à
40
secondes environ !! (alors que c'est immédiat si l'enregistrement
n'est pas
bloqué). Chez des clients, avec un fichier bcp plus conséquent c'est
tellement long qu'ils ont en général le réflexe "ctrl+alt+suppr" en
pensant
que l'appli est plantée...
Une idée sur ce qui peut entrainer un temps aussi long d'exécution de
cette
fonction HLitBloque ??
Merci beaucoup, à votre dispo pour renseignements complémentaires....
Stépha
à+
--
deg
corrigez mon adresse pour me répondre par mail
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
titou44
deg a émis l'idée suivante :
(copie d'un message passé sur forum officiel pcsoft, au cas z'où)
Bonjour,
débutant en windev, je lis ce forum depuis qqes temps et ai fait quelques recherches dans les archives mais sans vraiment trouver de réponses à mon problème.
L'état des lieu: un programme tournant en windev5.5 et utilisant un RAD "RADTabHF" pour gérer des blocages d'enregistrement. N'étant point le concepteur originel de cette fenêtre je vais essayer de donner un max de renseignement (enfin ceux que j'ai trouvé ;) ). Le programme utilise donc les méthodes de la classe RADTabHF générée par Windev automatiquement. Sur entrée dans chaque ligne de la table lisant le fichier "CLIENT" (nom fictif), une méthode RADTab:BloqueLigne() est lancée. Dans cette méthode la fonction HLitBloque est utilisée et dans le cas où l'enregistrement est effectivement bloqué cette fonction met un temps assez important à s'exécuter... Sur mon fichier de test tout petit, jusqu'à 40 secondes environ !! (alors que c'est immédiat si l'enregistrement n'est pas bloqué). Chez des clients, avec un fichier bcp plus conséquent c'est tellement long qu'ils ont en général le réflexe "ctrl+alt+suppr" en pensant que l'appli est plantée...
Une idée sur ce qui peut entrainer un temps aussi long d'exécution de cette fonction HLitBloque ??
Merci beaucoup, à votre dispo pour renseignements complémentaires....
Stépha
à+
bonsoir
j'ai crisé moi aussi il y a longtemps. maintenant je gère les blocages "à la main". voir le code de mes fonctions dans un fil précédent "bloquer un enregistement"
et moralité : ne pas faire confiance au RAD.
cdt
titou44 (marreduspam) @freesurf.fr
-- Ceci est une signature automatique de MesNews. Site : http://mesnews.no-ip.com
deg a émis l'idée suivante :
(copie d'un message passé sur forum officiel pcsoft, au cas z'où)
Bonjour,
débutant en windev, je lis ce forum depuis qqes temps et ai fait
quelques
recherches dans les archives mais sans vraiment trouver de réponses à
mon
problème.
L'état des lieu:
un programme tournant en windev5.5 et utilisant un RAD "RADTabHF" pour
gérer des blocages d'enregistrement. N'étant point le concepteur
originel
de cette fenêtre je vais essayer de donner un max de renseignement
(enfin
ceux que j'ai trouvé ;) ).
Le programme utilise donc les méthodes de la classe RADTabHF générée
par
Windev automatiquement. Sur entrée dans chaque ligne de la table
lisant le
fichier "CLIENT" (nom fictif), une méthode RADTab:BloqueLigne() est
lancée.
Dans cette méthode la fonction HLitBloque est utilisée et dans le cas
où
l'enregistrement est effectivement bloqué cette fonction met un temps
assez
important à s'exécuter... Sur mon fichier de test tout petit, jusqu'à
40
secondes environ !! (alors que c'est immédiat si l'enregistrement
n'est pas
bloqué). Chez des clients, avec un fichier bcp plus conséquent c'est
tellement long qu'ils ont en général le réflexe "ctrl+alt+suppr" en
pensant
que l'appli est plantée...
Une idée sur ce qui peut entrainer un temps aussi long d'exécution de
cette
fonction HLitBloque ??
Merci beaucoup, à votre dispo pour renseignements complémentaires....
Stépha
à+
bonsoir
j'ai crisé moi aussi il y a longtemps.
maintenant je gère les blocages "à la main".
voir le code de mes fonctions dans un fil précédent "bloquer un
enregistement"
et moralité : ne pas faire confiance au RAD.
cdt
titou44 (marreduspam) @freesurf.fr
--
Ceci est une signature automatique de MesNews.
Site : http://mesnews.no-ip.com
(copie d'un message passé sur forum officiel pcsoft, au cas z'où)
Bonjour,
débutant en windev, je lis ce forum depuis qqes temps et ai fait quelques recherches dans les archives mais sans vraiment trouver de réponses à mon problème.
L'état des lieu: un programme tournant en windev5.5 et utilisant un RAD "RADTabHF" pour gérer des blocages d'enregistrement. N'étant point le concepteur originel de cette fenêtre je vais essayer de donner un max de renseignement (enfin ceux que j'ai trouvé ;) ). Le programme utilise donc les méthodes de la classe RADTabHF générée par Windev automatiquement. Sur entrée dans chaque ligne de la table lisant le fichier "CLIENT" (nom fictif), une méthode RADTab:BloqueLigne() est lancée. Dans cette méthode la fonction HLitBloque est utilisée et dans le cas où l'enregistrement est effectivement bloqué cette fonction met un temps assez important à s'exécuter... Sur mon fichier de test tout petit, jusqu'à 40 secondes environ !! (alors que c'est immédiat si l'enregistrement n'est pas bloqué). Chez des clients, avec un fichier bcp plus conséquent c'est tellement long qu'ils ont en général le réflexe "ctrl+alt+suppr" en pensant que l'appli est plantée...
Une idée sur ce qui peut entrainer un temps aussi long d'exécution de cette fonction HLitBloque ??
Merci beaucoup, à votre dispo pour renseignements complémentaires....
Stépha
à+
bonsoir
j'ai crisé moi aussi il y a longtemps. maintenant je gère les blocages "à la main". voir le code de mes fonctions dans un fil précédent "bloquer un enregistement"
et moralité : ne pas faire confiance au RAD.
cdt
titou44 (marreduspam) @freesurf.fr
-- Ceci est une signature automatique de MesNews. Site : http://mesnews.no-ip.com
Deg
Bonjour,
Merci titou44,
Le Mon, 11 Apr 2005 22:20:00 +0200, titou44 a écrit :
deg a émis l'idée suivante :
(copie d'un message passé sur forum officiel pcsoft, au cas z'où)
Bonjour,
débutant en windev, je lis ce forum depuis qqes temps et ai fait Stépha
bonsoir
j'ai crisé moi aussi il y a longtemps. maintenant je gère les blocages "à la main". voir le code de mes fonctions dans un fil précédent "bloquer un enregistement"
aïe, donc y'a pas de solution simple et élégante pour corriger juste ce petit problème sans gérer complètement les blocages autrement en gardant le code actuel ?
Bonjour,
Merci titou44,
Le Mon, 11 Apr 2005 22:20:00 +0200, titou44 a écrit :
deg a émis l'idée suivante :
(copie d'un message passé sur forum officiel pcsoft, au cas z'où)
Bonjour,
débutant en windev, je lis ce forum depuis qqes temps et ai fait
Stépha
bonsoir
j'ai crisé moi aussi il y a longtemps.
maintenant je gère les blocages "à la main".
voir le code de mes fonctions dans un fil précédent "bloquer un
enregistement"
aïe, donc y'a pas de solution simple et élégante pour corriger juste ce
petit problème sans gérer complètement les blocages autrement en gardant le
code actuel ?
Le Mon, 11 Apr 2005 22:20:00 +0200, titou44 a écrit :
deg a émis l'idée suivante :
(copie d'un message passé sur forum officiel pcsoft, au cas z'où)
Bonjour,
débutant en windev, je lis ce forum depuis qqes temps et ai fait Stépha
bonsoir
j'ai crisé moi aussi il y a longtemps. maintenant je gère les blocages "à la main". voir le code de mes fonctions dans un fil précédent "bloquer un enregistement"
aïe, donc y'a pas de solution simple et élégante pour corriger juste ce petit problème sans gérer complètement les blocages autrement en gardant le code actuel ?
Jean Cougnaud
Bonjour,
Peut-être modifier la valeur de h.NbEssais ? Je crois que par défaut elle est égale à 20 en WD5.5 et 50 en WD7.5.
Sa réaction dépend du réseau et des charges de travail des postes. Il est donc difficile de dire : il faut mettre telle ou telle valeur pour avoir une attente de telle ou telle durée.
Dans nos projets nous avions mis sa valeur dans un fichier de paramètres et nous pouvions le peaufiner selon la configuration du client.
Tu peux peut-être tester différentes valeurs et voir leur réaction ? Regardes l'aide sur h.nbessais pour avoir toutes les infos car cela dépend aussi du mode de blocage défini dans le projet.
Cordialement
Jean Cougnaud http://www.jean-cougnaud.com
"deg" a écrit dans le message de news:
(copie d'un message passé sur forum officiel pcsoft, au cas z'où)
Bonjour,
débutant en windev, je lis ce forum depuis qqes temps et ai fait quelques recherches dans les archives mais sans vraiment trouver de réponses à mon problème.
L'état des lieu: un programme tournant en windev5.5 et utilisant un RAD "RADTabHF" pour gérer des blocages d'enregistrement. N'étant point le concepteur originel de cette fenêtre je vais essayer de donner un max de renseignement (enfin ceux que j'ai trouvé ;) ). Le programme utilise donc les méthodes de la classe RADTabHF générée par Windev automatiquement. Sur entrée dans chaque ligne de la table lisant le fichier "CLIENT" (nom fictif), une méthode RADTab:BloqueLigne() est lancée. Dans cette méthode la fonction HLitBloque est utilisée et dans le cas où l'enregistrement est effectivement bloqué cette fonction met un temps assez important à s'exécuter... Sur mon fichier de test tout petit, jusqu'à 40 secondes environ !! (alors que c'est immédiat si l'enregistrement n'est pas bloqué). Chez des clients, avec un fichier bcp plus conséquent c'est tellement long qu'ils ont en général le réflexe "ctrl+alt+suppr" en pensant que l'appli est plantée...
Une idée sur ce qui peut entrainer un temps aussi long d'exécution de cette fonction HLitBloque ??
Merci beaucoup, à votre dispo pour renseignements complémentaires....
Stépha
à+
-- deg corrigez mon adresse pour me répondre par mail
Bonjour,
Peut-être modifier la valeur de h.NbEssais ?
Je crois que par défaut elle est égale à 20 en WD5.5 et 50 en WD7.5.
Sa réaction dépend du réseau et des charges de travail des postes. Il est
donc difficile de dire : il faut mettre telle ou telle valeur pour avoir une
attente de telle ou telle durée.
Dans nos projets nous avions mis sa valeur dans un fichier de paramètres et
nous pouvions le peaufiner selon la configuration du client.
Tu peux peut-être tester différentes valeurs et voir leur réaction ?
Regardes l'aide sur h.nbessais pour avoir toutes les infos car cela dépend
aussi du mode de blocage défini dans le projet.
Cordialement
Jean Cougnaud
http://www.jean-cougnaud.com
"deg" <degnews_@yahoo.fr> a écrit dans le message de
news:ordl515fjq7p7vtcgpkdu2sor7n9nuisgi@4ax.com...
(copie d'un message passé sur forum officiel pcsoft, au cas z'où)
Bonjour,
débutant en windev, je lis ce forum depuis qqes temps et ai fait
quelques
recherches dans les archives mais sans vraiment trouver de réponses à
mon
problème.
L'état des lieu:
un programme tournant en windev5.5 et utilisant un RAD "RADTabHF" pour
gérer des blocages d'enregistrement. N'étant point le concepteur
originel
de cette fenêtre je vais essayer de donner un max de renseignement
(enfin
ceux que j'ai trouvé ;) ).
Le programme utilise donc les méthodes de la classe RADTabHF générée
par
Windev automatiquement. Sur entrée dans chaque ligne de la table
lisant le
fichier "CLIENT" (nom fictif), une méthode RADTab:BloqueLigne() est
lancée.
Dans cette méthode la fonction HLitBloque est utilisée et dans le cas
où
l'enregistrement est effectivement bloqué cette fonction met un temps
assez
important à s'exécuter... Sur mon fichier de test tout petit, jusqu'à
40
secondes environ !! (alors que c'est immédiat si l'enregistrement
n'est pas
bloqué). Chez des clients, avec un fichier bcp plus conséquent c'est
tellement long qu'ils ont en général le réflexe "ctrl+alt+suppr" en
pensant
que l'appli est plantée...
Une idée sur ce qui peut entrainer un temps aussi long d'exécution de
cette
fonction HLitBloque ??
Merci beaucoup, à votre dispo pour renseignements complémentaires....
Stépha
à+
--
deg
corrigez mon adresse pour me répondre par mail
Peut-être modifier la valeur de h.NbEssais ? Je crois que par défaut elle est égale à 20 en WD5.5 et 50 en WD7.5.
Sa réaction dépend du réseau et des charges de travail des postes. Il est donc difficile de dire : il faut mettre telle ou telle valeur pour avoir une attente de telle ou telle durée.
Dans nos projets nous avions mis sa valeur dans un fichier de paramètres et nous pouvions le peaufiner selon la configuration du client.
Tu peux peut-être tester différentes valeurs et voir leur réaction ? Regardes l'aide sur h.nbessais pour avoir toutes les infos car cela dépend aussi du mode de blocage défini dans le projet.
Cordialement
Jean Cougnaud http://www.jean-cougnaud.com
"deg" a écrit dans le message de news:
(copie d'un message passé sur forum officiel pcsoft, au cas z'où)
Bonjour,
débutant en windev, je lis ce forum depuis qqes temps et ai fait quelques recherches dans les archives mais sans vraiment trouver de réponses à mon problème.
L'état des lieu: un programme tournant en windev5.5 et utilisant un RAD "RADTabHF" pour gérer des blocages d'enregistrement. N'étant point le concepteur originel de cette fenêtre je vais essayer de donner un max de renseignement (enfin ceux que j'ai trouvé ;) ). Le programme utilise donc les méthodes de la classe RADTabHF générée par Windev automatiquement. Sur entrée dans chaque ligne de la table lisant le fichier "CLIENT" (nom fictif), une méthode RADTab:BloqueLigne() est lancée. Dans cette méthode la fonction HLitBloque est utilisée et dans le cas où l'enregistrement est effectivement bloqué cette fonction met un temps assez important à s'exécuter... Sur mon fichier de test tout petit, jusqu'à 40 secondes environ !! (alors que c'est immédiat si l'enregistrement n'est pas bloqué). Chez des clients, avec un fichier bcp plus conséquent c'est tellement long qu'ils ont en général le réflexe "ctrl+alt+suppr" en pensant que l'appli est plantée...
Une idée sur ce qui peut entrainer un temps aussi long d'exécution de cette fonction HLitBloque ??
Merci beaucoup, à votre dispo pour renseignements complémentaires....
Stépha
à+
-- deg corrigez mon adresse pour me répondre par mail
Jean Cougnaud
Bon, je ne sais pas où est parti mon message. Je le reposte
Peut-être modifier la valeur de h.NbEssais ? Je crois que par défaut elle est égale à 20 en WD5.5 et 50 en WD7.5.
Sa réaction dépend du réseau et des charges de travail des postes. Il est donc difficile de dire : il faut mettre telle ou telle valeur pour avoir une attente de telle ou telle durée.
Dans nos projets nous avions mis sa valeur dans un fichier de paramètres et nous pouvions le peaufiner selon la configuration du client.
Tu peux peut-être tester différentes valeurs et voir leur réaction ? Regardes l'aide sur h.nbessais pour avoir toutes les infos car cela dépend aussi du mode de blocage défini dans le projet.
(copie d'un message passé sur forum officiel pcsoft, au cas z'où)
Bonjour,
débutant en windev, je lis ce forum depuis qqes temps et ai fait quelques recherches dans les archives mais sans vraiment trouver de réponses à mon problème.
L'état des lieu: un programme tournant en windev5.5 et utilisant un RAD "RADTabHF" pour gérer des blocages d'enregistrement. N'étant point le concepteur originel de cette fenêtre je vais essayer de donner un max de renseignement (enfin ceux que j'ai trouvé ;) ). Le programme utilise donc les méthodes de la classe RADTabHF générée par Windev automatiquement. Sur entrée dans chaque ligne de la table lisant le fichier "CLIENT" (nom fictif), une méthode RADTab:BloqueLigne() est lancée. Dans cette méthode la fonction HLitBloque est utilisée et dans le cas où l'enregistrement est effectivement bloqué cette fonction met un temps assez important à s'exécuter... Sur mon fichier de test tout petit, jusqu'à 40 secondes environ !! (alors que c'est immédiat si l'enregistrement n'est pas bloqué). Chez des clients, avec un fichier bcp plus conséquent c'est tellement long qu'ils ont en général le réflexe "ctrl+alt+suppr" en pensant que l'appli est plantée...
Une idée sur ce qui peut entrainer un temps aussi long d'exécution de cette fonction HLitBloque ??
Merci beaucoup, à votre dispo pour renseignements complémentaires....
Stépha
à+
-- deg corrigez mon adresse pour me répondre par mail
Bon, je ne sais pas où est parti mon message. Je le reposte
Peut-être modifier la valeur de h.NbEssais ?
Je crois que par défaut elle est égale à 20 en WD5.5 et 50 en WD7.5.
Sa réaction dépend du réseau et des charges de travail des postes. Il est
donc difficile de dire : il faut mettre telle ou telle valeur pour avoir une
attente de telle ou telle durée.
Dans nos projets nous avions mis sa valeur dans un fichier de paramètres et
nous pouvions le peaufiner selon la configuration du client.
Tu peux peut-être tester différentes valeurs et voir leur réaction ?
Regardes l'aide sur h.nbessais pour avoir toutes les infos car cela dépend
aussi du mode de blocage défini dans le projet.
"deg" <degnews_@yahoo.fr> a écrit dans le message de
news:ordl515fjq7p7vtcgpkdu2sor7n9nuisgi@4ax.com...
(copie d'un message passé sur forum officiel pcsoft, au cas z'où)
Bonjour,
débutant en windev, je lis ce forum depuis qqes temps et ai fait
quelques
recherches dans les archives mais sans vraiment trouver de réponses à
mon
problème.
L'état des lieu:
un programme tournant en windev5.5 et utilisant un RAD "RADTabHF" pour
gérer des blocages d'enregistrement. N'étant point le concepteur
originel
de cette fenêtre je vais essayer de donner un max de renseignement
(enfin
ceux que j'ai trouvé ;) ).
Le programme utilise donc les méthodes de la classe RADTabHF générée
par
Windev automatiquement. Sur entrée dans chaque ligne de la table
lisant le
fichier "CLIENT" (nom fictif), une méthode RADTab:BloqueLigne() est
lancée.
Dans cette méthode la fonction HLitBloque est utilisée et dans le cas
où
l'enregistrement est effectivement bloqué cette fonction met un temps
assez
important à s'exécuter... Sur mon fichier de test tout petit, jusqu'à
40
secondes environ !! (alors que c'est immédiat si l'enregistrement
n'est pas
bloqué). Chez des clients, avec un fichier bcp plus conséquent c'est
tellement long qu'ils ont en général le réflexe "ctrl+alt+suppr" en
pensant
que l'appli est plantée...
Une idée sur ce qui peut entrainer un temps aussi long d'exécution de
cette
fonction HLitBloque ??
Merci beaucoup, à votre dispo pour renseignements complémentaires....
Stépha
à+
--
deg
corrigez mon adresse pour me répondre par mail
Peut-être modifier la valeur de h.NbEssais ? Je crois que par défaut elle est égale à 20 en WD5.5 et 50 en WD7.5.
Sa réaction dépend du réseau et des charges de travail des postes. Il est donc difficile de dire : il faut mettre telle ou telle valeur pour avoir une attente de telle ou telle durée.
Dans nos projets nous avions mis sa valeur dans un fichier de paramètres et nous pouvions le peaufiner selon la configuration du client.
Tu peux peut-être tester différentes valeurs et voir leur réaction ? Regardes l'aide sur h.nbessais pour avoir toutes les infos car cela dépend aussi du mode de blocage défini dans le projet.
(copie d'un message passé sur forum officiel pcsoft, au cas z'où)
Bonjour,
débutant en windev, je lis ce forum depuis qqes temps et ai fait quelques recherches dans les archives mais sans vraiment trouver de réponses à mon problème.
L'état des lieu: un programme tournant en windev5.5 et utilisant un RAD "RADTabHF" pour gérer des blocages d'enregistrement. N'étant point le concepteur originel de cette fenêtre je vais essayer de donner un max de renseignement (enfin ceux que j'ai trouvé ;) ). Le programme utilise donc les méthodes de la classe RADTabHF générée par Windev automatiquement. Sur entrée dans chaque ligne de la table lisant le fichier "CLIENT" (nom fictif), une méthode RADTab:BloqueLigne() est lancée. Dans cette méthode la fonction HLitBloque est utilisée et dans le cas où l'enregistrement est effectivement bloqué cette fonction met un temps assez important à s'exécuter... Sur mon fichier de test tout petit, jusqu'à 40 secondes environ !! (alors que c'est immédiat si l'enregistrement n'est pas bloqué). Chez des clients, avec un fichier bcp plus conséquent c'est tellement long qu'ils ont en général le réflexe "ctrl+alt+suppr" en pensant que l'appli est plantée...
Une idée sur ce qui peut entrainer un temps aussi long d'exécution de cette fonction HLitBloque ??
Merci beaucoup, à votre dispo pour renseignements complémentaires....
Stépha
à+
-- deg corrigez mon adresse pour me répondre par mail
Deg
Le Tue, 12 Apr 2005 09:25:40 +0200, Jean Cougnaud a écrit :
Bonjour,
Peut-être modifier la valeur de h.NbEssais ? Je crois que par défaut elle est égale à 20 en WD5.5 et 50 en WD7.5.
j'avais essayé ça en effet, mais sans aucun effet visible (j'ai toujours pas compris d'ailleurs pourquoi)... j'avais mis 5 pour voir...
merci pour ta réponse.
-- Deg ôter le caractère superflu avant l'arobase de mon adresse si vous souhaitez m'écrire en privé.
Le Tue, 12 Apr 2005 09:25:40 +0200, Jean Cougnaud a écrit :
Bonjour,
Peut-être modifier la valeur de h.NbEssais ?
Je crois que par défaut elle est égale à 20 en WD5.5 et 50 en WD7.5.
j'avais essayé ça en effet, mais sans aucun effet visible (j'ai toujours
pas compris d'ailleurs pourquoi)... j'avais mis 5 pour voir...
merci pour ta réponse.
--
Deg
ôter le caractère superflu avant l'arobase de mon adresse si vous souhaitez
m'écrire en privé.
Le Tue, 12 Apr 2005 09:25:40 +0200, Jean Cougnaud a écrit :
Bonjour,
Peut-être modifier la valeur de h.NbEssais ? Je crois que par défaut elle est égale à 20 en WD5.5 et 50 en WD7.5.
j'avais essayé ça en effet, mais sans aucun effet visible (j'ai toujours pas compris d'ailleurs pourquoi)... j'avais mis 5 pour voir...
merci pour ta réponse.
-- Deg ôter le caractère superflu avant l'arobase de mon adresse si vous souhaitez m'écrire en privé.
Deg
Le Tue, 12 Apr 2005 11:51:27 +0200, Deg a écrit :
Le Tue, 12 Apr 2005 09:25:40 +0200, Jean Cougnaud a écrit :
Bonjour,
Peut-être modifier la valeur de h.NbEssais ? Je crois que par défaut elle est égale à 20 en WD5.5 et 50 en WD7.5.
j'avais essayé ça en effet, mais sans aucun effet visible (j'ai toujours pas compris d'ailleurs pourquoi)... j'avais mis 5 pour voir...
merci pour ta réponse.
bon ben en fait si y'a de l'idée à suivre par ici ! en fait y'a une variable RADTabHF:NbEssais qui existe mais qui apparement n'est pas vraiment utilisée !!! Si on utilise H.NbEssais à la place ça va tout de suite mieux !
Quel pourrait être l'inconvénient éventuel en baissant ce H.NbEssais à 5 par exemple (car je vois que dans le programme que je modifie il est mis à pas mal d'endroit à 50 ou plus ??)...
Merci bcp
-- Deg ôter le caractère superflu avant l'arobase de mon adresse si vous souhaitez m'écrire en privé.
Le Tue, 12 Apr 2005 11:51:27 +0200, Deg a écrit :
Le Tue, 12 Apr 2005 09:25:40 +0200, Jean Cougnaud a écrit :
Bonjour,
Peut-être modifier la valeur de h.NbEssais ?
Je crois que par défaut elle est égale à 20 en WD5.5 et 50 en WD7.5.
j'avais essayé ça en effet, mais sans aucun effet visible (j'ai toujours
pas compris d'ailleurs pourquoi)... j'avais mis 5 pour voir...
merci pour ta réponse.
bon ben en fait si y'a de l'idée à suivre par ici ! en fait y'a une
variable RADTabHF:NbEssais qui existe mais qui apparement n'est pas
vraiment utilisée !!!
Si on utilise H.NbEssais à la place ça va tout de suite mieux !
Quel pourrait être l'inconvénient éventuel en baissant ce H.NbEssais à 5
par exemple (car je vois que dans le programme que je modifie il est mis à
pas mal d'endroit à 50 ou plus ??)...
Merci bcp
--
Deg
ôter le caractère superflu avant l'arobase de mon adresse si vous souhaitez
m'écrire en privé.
Le Tue, 12 Apr 2005 09:25:40 +0200, Jean Cougnaud a écrit :
Bonjour,
Peut-être modifier la valeur de h.NbEssais ? Je crois que par défaut elle est égale à 20 en WD5.5 et 50 en WD7.5.
j'avais essayé ça en effet, mais sans aucun effet visible (j'ai toujours pas compris d'ailleurs pourquoi)... j'avais mis 5 pour voir...
merci pour ta réponse.
bon ben en fait si y'a de l'idée à suivre par ici ! en fait y'a une variable RADTabHF:NbEssais qui existe mais qui apparement n'est pas vraiment utilisée !!! Si on utilise H.NbEssais à la place ça va tout de suite mieux !
Quel pourrait être l'inconvénient éventuel en baissant ce H.NbEssais à 5 par exemple (car je vois que dans le programme que je modifie il est mis à pas mal d'endroit à 50 ou plus ??)...
Merci bcp
-- Deg ôter le caractère superflu avant l'arobase de mon adresse si vous souhaitez m'écrire en privé.
Jean Cougnaud
Bonsoir,
Tu as vu qu'il sert à répéter la fonction de blocage. Si tu mets trop grand ton programme est bloqué trop longtemps.
Par contre, si tu mets trop court et que l'enregistrement est débloqué par un autre poste juste après ta lecture, tu auras eu le message comme quoi l'enregistrement est bloqué.
Tout dépend de la réaction que tu veux avoir et si elle est bien gérée par le programme.
Par contre l'avoir plusieurs fois dans son programme ne me semble pas très correct. Nous on le met dans le code d'initialisation du projet et c'est tout.
Il faudrait vraiment avoir des traitements spéciaux pour avoir à le changer.
Fais des essais en mettant 5 et tu verras ce que cela donne mais je me demande si sur le poste contenant les fichiers de données cela fonctionnerait mais sur les postes en réseau ce ne serait pas un peu trop court ...
Cordialement
Jean Cougnaud http://www.jean-cougnaud.com
"Deg" a écrit dans le message de news:
Le Tue, 12 Apr 2005 11:51:27 +0200, Deg a écrit :
> Le Tue, 12 Apr 2005 09:25:40 +0200, Jean Cougnaud a écrit : > >> Bonjour, >> >> Peut-être modifier la valeur de h.NbEssais ? >> Je crois que par défaut elle est égale à 20 en WD5.5 et 50 en WD7.5. > > j'avais essayé ça en effet, mais sans aucun effet visible (j'ai toujours > pas compris d'ailleurs pourquoi)... j'avais mis 5 pour voir... > > merci pour ta réponse.
bon ben en fait si y'a de l'idée à suivre par ici ! en fait y'a une variable RADTabHF:NbEssais qui existe mais qui apparement n'est pas vraiment utilisée !!! Si on utilise H.NbEssais à la place ça va tout de suite mieux !
Quel pourrait être l'inconvénient éventuel en baissant ce H.NbEssais à 5 par exemple (car je vois que dans le programme que je modifie il est mis à pas mal d'endroit à 50 ou plus ??)...
Merci bcp
-- Deg ôter le caractère superflu avant l'arobase de mon adresse si vous
souhaitez
m'écrire en privé.
Bonsoir,
Tu as vu qu'il sert à répéter la fonction de blocage. Si tu mets trop grand
ton programme est bloqué trop longtemps.
Par contre, si tu mets trop court et que l'enregistrement est débloqué par
un autre poste juste après ta lecture, tu auras eu le message comme quoi
l'enregistrement est bloqué.
Tout dépend de la réaction que tu veux avoir et si elle est bien gérée par
le programme.
Par contre l'avoir plusieurs fois dans son programme ne me semble pas très
correct. Nous on le met dans le code d'initialisation du projet et c'est
tout.
Il faudrait vraiment avoir des traitements spéciaux pour avoir à le changer.
Fais des essais en mettant 5 et tu verras ce que cela donne mais je me
demande si sur le poste contenant les fichiers de données cela
fonctionnerait mais sur les postes en réseau ce ne serait pas un peu trop
court ...
Cordialement
Jean Cougnaud
http://www.jean-cougnaud.com
"Deg" <degnews_@yahoo.fr> a écrit dans le message de
news:1639o6ibln8fg.1bstetz2wj9jp.dlg@40tude.net...
Le Tue, 12 Apr 2005 11:51:27 +0200, Deg a écrit :
> Le Tue, 12 Apr 2005 09:25:40 +0200, Jean Cougnaud a écrit :
>
>> Bonjour,
>>
>> Peut-être modifier la valeur de h.NbEssais ?
>> Je crois que par défaut elle est égale à 20 en WD5.5 et 50 en WD7.5.
>
> j'avais essayé ça en effet, mais sans aucun effet visible (j'ai toujours
> pas compris d'ailleurs pourquoi)... j'avais mis 5 pour voir...
>
> merci pour ta réponse.
bon ben en fait si y'a de l'idée à suivre par ici ! en fait y'a une
variable RADTabHF:NbEssais qui existe mais qui apparement n'est pas
vraiment utilisée !!!
Si on utilise H.NbEssais à la place ça va tout de suite mieux !
Quel pourrait être l'inconvénient éventuel en baissant ce H.NbEssais à 5
par exemple (car je vois que dans le programme que je modifie il est mis à
pas mal d'endroit à 50 ou plus ??)...
Merci bcp
--
Deg
ôter le caractère superflu avant l'arobase de mon adresse si vous
Tu as vu qu'il sert à répéter la fonction de blocage. Si tu mets trop grand ton programme est bloqué trop longtemps.
Par contre, si tu mets trop court et que l'enregistrement est débloqué par un autre poste juste après ta lecture, tu auras eu le message comme quoi l'enregistrement est bloqué.
Tout dépend de la réaction que tu veux avoir et si elle est bien gérée par le programme.
Par contre l'avoir plusieurs fois dans son programme ne me semble pas très correct. Nous on le met dans le code d'initialisation du projet et c'est tout.
Il faudrait vraiment avoir des traitements spéciaux pour avoir à le changer.
Fais des essais en mettant 5 et tu verras ce que cela donne mais je me demande si sur le poste contenant les fichiers de données cela fonctionnerait mais sur les postes en réseau ce ne serait pas un peu trop court ...
Cordialement
Jean Cougnaud http://www.jean-cougnaud.com
"Deg" a écrit dans le message de news:
Le Tue, 12 Apr 2005 11:51:27 +0200, Deg a écrit :
> Le Tue, 12 Apr 2005 09:25:40 +0200, Jean Cougnaud a écrit : > >> Bonjour, >> >> Peut-être modifier la valeur de h.NbEssais ? >> Je crois que par défaut elle est égale à 20 en WD5.5 et 50 en WD7.5. > > j'avais essayé ça en effet, mais sans aucun effet visible (j'ai toujours > pas compris d'ailleurs pourquoi)... j'avais mis 5 pour voir... > > merci pour ta réponse.
bon ben en fait si y'a de l'idée à suivre par ici ! en fait y'a une variable RADTabHF:NbEssais qui existe mais qui apparement n'est pas vraiment utilisée !!! Si on utilise H.NbEssais à la place ça va tout de suite mieux !
Quel pourrait être l'inconvénient éventuel en baissant ce H.NbEssais à 5 par exemple (car je vois que dans le programme que je modifie il est mis à pas mal d'endroit à 50 ou plus ??)...
Merci bcp
-- Deg ôter le caractère superflu avant l'arobase de mon adresse si vous
souhaitez
m'écrire en privé.
Deg
Le Tue, 12 Apr 2005 21:13:09 +0200, Jean Cougnaud a écrit :
Bonsoir,
Tu as vu qu'il sert à répéter la fonction de blocage. Si tu mets trop grand ton programme est bloqué trop longtemps.
Par contre, si tu mets trop court et que l'enregistrement est débloqué par un autre poste juste après ta lecture, tu auras eu le message comme quoi l'enregistrement est bloqué.
Tout dépend de la réaction que tu veux avoir et si elle est bien gérée par le programme.
je préfère nettement que l'ouverture de la fiche soit bloquée "pour rien" plutôt que le contraire (programme figé pendant un temps trop long... d'autant que visiblement pendant ces tentatives de hlitbloque on perd complètement la main et nos utilisateurs ont la fâcheuse tendance à quitter brutalement en pensant que c'est planté... !
Par contre l'avoir plusieurs fois dans son programme ne me semble pas très correct. Nous on le met dans le code d'initialisation du projet et c'est tout.
en effet, il n'y a maintenant plus qu'un seul h.nbessais à l'initialisation du prog...
quand au RADTabHF:NbEssais, toujours pas compris à quoi ils servaient ! ?? ;)
Fais des essais en mettant 5 et tu verras ce que cela donne mais je me demande si sur le poste contenant les fichiers de données cela fonctionnerait mais sur les postes en réseau ce ne serait pas un peu trop court ...
on a placé à 5 pour tester... sur nos tests ça nous convient... on va faire tester en situation par 2-3 utilisateurs...
merci beaucoup pour toutes ces précisions.
stéphane
Le Tue, 12 Apr 2005 21:13:09 +0200, Jean Cougnaud a écrit :
Bonsoir,
Tu as vu qu'il sert à répéter la fonction de blocage. Si tu mets trop grand
ton programme est bloqué trop longtemps.
Par contre, si tu mets trop court et que l'enregistrement est débloqué par
un autre poste juste après ta lecture, tu auras eu le message comme quoi
l'enregistrement est bloqué.
Tout dépend de la réaction que tu veux avoir et si elle est bien gérée par
le programme.
je préfère nettement que l'ouverture de la fiche soit bloquée "pour rien"
plutôt que le contraire (programme figé pendant un temps trop long...
d'autant que visiblement pendant ces tentatives de hlitbloque on perd
complètement la main et nos utilisateurs ont la fâcheuse tendance à quitter
brutalement en pensant que c'est planté... !
Par contre l'avoir plusieurs fois dans son programme ne me semble pas très
correct. Nous on le met dans le code d'initialisation du projet et c'est
tout.
en effet, il n'y a maintenant plus qu'un seul h.nbessais à l'initialisation
du prog...
quand au RADTabHF:NbEssais, toujours pas compris à quoi ils servaient ! ??
;)
Fais des essais en mettant 5 et tu verras ce que cela donne mais je me
demande si sur le poste contenant les fichiers de données cela
fonctionnerait mais sur les postes en réseau ce ne serait pas un peu trop
court ...
on a placé à 5 pour tester... sur nos tests ça nous convient... on va faire
tester en situation par 2-3 utilisateurs...
Le Tue, 12 Apr 2005 21:13:09 +0200, Jean Cougnaud a écrit :
Bonsoir,
Tu as vu qu'il sert à répéter la fonction de blocage. Si tu mets trop grand ton programme est bloqué trop longtemps.
Par contre, si tu mets trop court et que l'enregistrement est débloqué par un autre poste juste après ta lecture, tu auras eu le message comme quoi l'enregistrement est bloqué.
Tout dépend de la réaction que tu veux avoir et si elle est bien gérée par le programme.
je préfère nettement que l'ouverture de la fiche soit bloquée "pour rien" plutôt que le contraire (programme figé pendant un temps trop long... d'autant que visiblement pendant ces tentatives de hlitbloque on perd complètement la main et nos utilisateurs ont la fâcheuse tendance à quitter brutalement en pensant que c'est planté... !
Par contre l'avoir plusieurs fois dans son programme ne me semble pas très correct. Nous on le met dans le code d'initialisation du projet et c'est tout.
en effet, il n'y a maintenant plus qu'un seul h.nbessais à l'initialisation du prog...
quand au RADTabHF:NbEssais, toujours pas compris à quoi ils servaient ! ?? ;)
Fais des essais en mettant 5 et tu verras ce que cela donne mais je me demande si sur le poste contenant les fichiers de données cela fonctionnerait mais sur les postes en réseau ce ne serait pas un peu trop court ...
on a placé à 5 pour tester... sur nos tests ça nous convient... on va faire tester en situation par 2-3 utilisateurs...
