Je demande ici l'opinion de tous les habitués de la chose... Prenons un
cas qui m'intéresse : une fenêtre contenant plusieurs combo et zones
d'affichage qui, lors de l'initialisation de chacun de ces champs,
exécutent des requêtes vers un serveur SQL distant pour obtenir les
données à afficher.
Ces données sont (pour les combos) le contenu de tables (Identifiant +
Description) ou encore (pour les zones d'affichage) des statistiques et
compteurs (récupérés à l'aide de requête SUM, COUNT, etc).
L'exécution de ma fenêtre me donne un temps d'attente d'environ 3
secondes avant de permettre la saisie (le temps que chaque champ
s'initialise, séquentiellement).
Une idée géniale (jusqu'à preuve du contraire :D) m'est alors venue :
pourquoi ne pas lancer toutes ces opérations dans des threads
secondaires (non bloquants) dans l'initialisation du projet ! Alors, je
devrais sauver quelques précieuses secondes dans l'exécution...
Des commentaires, points à surveiller, astuces, propos diffamatoires
(non, peut-être pas !) seront les bienvenus car je débute avec la
gestion des threads et désire ne pas passer quelques heures à tomber
dans les pièges à con.
L'exécution de ma fenêtre me donne un temps d'attente d'environ 3 secondes avant de permettre la saisie (le temps que chaque champ s'initialise, séquentiellement).
C'est fou ce qu'on peut en faire comme chose en 3 secondes !!! ;-) - Allumer une cigarette - Faire craquer ses doigts - Bailler un bon coup ... -- Cordialement, André STASZEWSKI Photo Visu version 3.0 dispo sur www.PlaneteDev.fr.st Contact ; Cliquez sur ce lien : http://cerbermail.com/?OT0Wnwyzph
Yanick Charland wrote:
L'exécution de ma fenêtre me donne un temps d'attente d'environ 3
secondes avant de permettre la saisie (le temps que chaque champ
s'initialise, séquentiellement).
C'est fou ce qu'on peut en faire comme chose en 3 secondes !!! ;-)
- Allumer une cigarette
- Faire craquer ses doigts
- Bailler un bon coup
...
--
Cordialement,
André STASZEWSKI
Photo Visu version 3.0 dispo sur www.PlaneteDev.fr.st
Contact ; Cliquez sur ce lien : http://cerbermail.com/?OT0Wnwyzph
L'exécution de ma fenêtre me donne un temps d'attente d'environ 3 secondes avant de permettre la saisie (le temps que chaque champ s'initialise, séquentiellement).
C'est fou ce qu'on peut en faire comme chose en 3 secondes !!! ;-) - Allumer une cigarette - Faire craquer ses doigts - Bailler un bon coup ... -- Cordialement, André STASZEWSKI Photo Visu version 3.0 dispo sur www.PlaneteDev.fr.st Contact ; Cliquez sur ce lien : http://cerbermail.com/?OT0Wnwyzph
Antoine
Attention simplement a ne pas accéder a un objet de ta fenetre depuis le thread secondaire (vois la doc). Si tu n'effectues que des traitements sur les fichiers Hyper File, pas de probleme.
Antoine
Yanick Charland wrote:
Bonjour,
Je demande ici l'opinion de tous les habitués de la chose... Prenons un cas qui m'intéresse : une fenêtre contenant plusieurs combo et zones d'affichage qui, lors de l'initialisation de chacun de ces champs, exécutent des requêtes vers un serveur SQL distant pour obtenir les données à afficher.
Ces données sont (pour les combos) le contenu de tables (Identifiant + Description) ou encore (pour les zones d'affichage) des statistiques et compteurs (récupérés à l'aide de requête SUM, COUNT, etc).
L'exécution de ma fenêtre me donne un temps d'attente d'environ 3 secondes avant de permettre la saisie (le temps que chaque champ s'initialise, séquentiellement).
Une idée géniale (jusqu'à preuve du contraire :D) m'est alors venue : pourquoi ne pas lancer toutes ces opérations dans des threads secondaires (non bloquants) dans l'initialisation du projet ! Alors, je devrais sauver quelques précieuses secondes dans l'exécution...
Des commentaires, points à surveiller, astuces, propos diffamatoires (non, peut-être pas !) seront les bienvenus car je débute avec la gestion des threads et désire ne pas passer quelques heures à tomber dans les pièges à con.
Merci bien et au plaisir de vous lire !
Attention simplement a ne pas accéder a un objet de ta fenetre depuis le
thread secondaire (vois la doc). Si tu n'effectues que des traitements sur
les fichiers Hyper File, pas de probleme.
Antoine
Yanick Charland wrote:
Bonjour,
Je demande ici l'opinion de tous les habitués de la chose... Prenons
un cas qui m'intéresse : une fenêtre contenant plusieurs combo et
zones d'affichage qui, lors de l'initialisation de chacun de ces
champs, exécutent des requêtes vers un serveur SQL distant pour
obtenir les données à afficher.
Ces données sont (pour les combos) le contenu de tables (Identifiant +
Description) ou encore (pour les zones d'affichage) des statistiques
et compteurs (récupérés à l'aide de requête SUM, COUNT, etc).
L'exécution de ma fenêtre me donne un temps d'attente d'environ 3
secondes avant de permettre la saisie (le temps que chaque champ
s'initialise, séquentiellement).
Une idée géniale (jusqu'à preuve du contraire :D) m'est alors venue :
pourquoi ne pas lancer toutes ces opérations dans des threads
secondaires (non bloquants) dans l'initialisation du projet ! Alors,
je devrais sauver quelques précieuses secondes dans l'exécution...
Des commentaires, points à surveiller, astuces, propos diffamatoires
(non, peut-être pas !) seront les bienvenus car je débute avec la
gestion des threads et désire ne pas passer quelques heures à tomber
dans les pièges à con.
Attention simplement a ne pas accéder a un objet de ta fenetre depuis le thread secondaire (vois la doc). Si tu n'effectues que des traitements sur les fichiers Hyper File, pas de probleme.
Antoine
Yanick Charland wrote:
Bonjour,
Je demande ici l'opinion de tous les habitués de la chose... Prenons un cas qui m'intéresse : une fenêtre contenant plusieurs combo et zones d'affichage qui, lors de l'initialisation de chacun de ces champs, exécutent des requêtes vers un serveur SQL distant pour obtenir les données à afficher.
Ces données sont (pour les combos) le contenu de tables (Identifiant + Description) ou encore (pour les zones d'affichage) des statistiques et compteurs (récupérés à l'aide de requête SUM, COUNT, etc).
L'exécution de ma fenêtre me donne un temps d'attente d'environ 3 secondes avant de permettre la saisie (le temps que chaque champ s'initialise, séquentiellement).
Une idée géniale (jusqu'à preuve du contraire :D) m'est alors venue : pourquoi ne pas lancer toutes ces opérations dans des threads secondaires (non bloquants) dans l'initialisation du projet ! Alors, je devrais sauver quelques précieuses secondes dans l'exécution...
Des commentaires, points à surveiller, astuces, propos diffamatoires (non, peut-être pas !) seront les bienvenus car je débute avec la gestion des threads et désire ne pas passer quelques heures à tomber dans les pièges à con.
Merci bien et au plaisir de vous lire !
mat
STASZEWSKI André wrote:
Yanick Charland wrote:
L'exécution de ma fenêtre me donne un temps d'attente d'environ 3 secondes avant de permettre la saisie (le temps que chaque champ s'initialise, séquentiellement).
C'est fou ce qu'on peut en faire comme chose en 3 secondes !!! ;-) - Allumer une cigarette - Faire craquer ses doigts - Bailler un bon coup ...
Bonjour,
C'est très vrai, mais aussi relatif. J'ai une fenêtre dont je n'arrive pas a diminuer l'ouverture en dessous des trois secondes en local, donc il faut à peu près doubler pour un réseau standard. Je fais partie des gens qui n'aiment pas attendre plus de 5 secondes pour qu'une fenêtre s'ouvre...
Essayant les recommendations pour initier les requêtes dans un thread sous wd 7.5 avec HExecuteRequête lancé dans les déclarations globales de la fenêtre, le programme se plantait tout de suite car il attendait que les les objets tel qu'une combo soit initier avant l'ouverture de la fenêtre. Puisque un thread serait une bonne solution pour une telle tâche et que j'ai peut-être commis des erreurs, j'aimerais bien savoir s'il y a manière de le faire correctement: qu'est qu'il faut mettre où pour que ça marche?
Merci Mat
STASZEWSKI André wrote:
Yanick Charland wrote:
L'exécution de ma fenêtre me donne un temps d'attente d'environ 3
secondes avant de permettre la saisie (le temps que chaque champ
s'initialise, séquentiellement).
C'est fou ce qu'on peut en faire comme chose en 3 secondes !!! ;-)
- Allumer une cigarette
- Faire craquer ses doigts
- Bailler un bon coup
...
Bonjour,
C'est très vrai, mais aussi relatif. J'ai une fenêtre dont je n'arrive
pas a diminuer l'ouverture en dessous des trois secondes en local, donc
il faut à peu près doubler pour un réseau standard. Je fais partie des
gens qui n'aiment pas attendre plus de 5 secondes pour qu'une fenêtre
s'ouvre...
Essayant les recommendations pour initier les requêtes dans un thread
sous wd 7.5 avec HExecuteRequête lancé dans les déclarations globales de
la fenêtre, le programme se plantait tout de suite car il attendait que
les les objets tel qu'une combo soit initier avant l'ouverture de la
fenêtre. Puisque un thread serait une bonne solution pour une telle
tâche et que j'ai peut-être commis des erreurs, j'aimerais bien savoir
s'il y a manière de le faire correctement: qu'est qu'il faut mettre où
pour que ça marche?
L'exécution de ma fenêtre me donne un temps d'attente d'environ 3 secondes avant de permettre la saisie (le temps que chaque champ s'initialise, séquentiellement).
C'est fou ce qu'on peut en faire comme chose en 3 secondes !!! ;-) - Allumer une cigarette - Faire craquer ses doigts - Bailler un bon coup ...
Bonjour,
C'est très vrai, mais aussi relatif. J'ai une fenêtre dont je n'arrive pas a diminuer l'ouverture en dessous des trois secondes en local, donc il faut à peu près doubler pour un réseau standard. Je fais partie des gens qui n'aiment pas attendre plus de 5 secondes pour qu'une fenêtre s'ouvre...
Essayant les recommendations pour initier les requêtes dans un thread sous wd 7.5 avec HExecuteRequête lancé dans les déclarations globales de la fenêtre, le programme se plantait tout de suite car il attendait que les les objets tel qu'une combo soit initier avant l'ouverture de la fenêtre. Puisque un thread serait une bonne solution pour une telle tâche et que j'ai peut-être commis des erreurs, j'aimerais bien savoir s'il y a manière de le faire correctement: qu'est qu'il faut mettre où pour que ça marche?
Merci Mat
Yanick Charland
STASZEWSKI André a couché sur son écran :
C'est fou ce qu'on peut en faire comme chose en 3 secondes !!! ;-) - Allumer une cigarette - Faire craquer ses doigts - Bailler un bon coup ...
Les trois secondes ne me causent pas de problème, j'ai oublié de spécifier : ce temps pourrait me convenir s'il était le même partout. Ici, avec un lien fibre optique, trois secondes c'est bien normal. Dans les installations chez mes "clients" (des bibliothèques scolaires), les liens avec le serveur SQL vont de lien fibre à accès ADSL 128K. Dans ce dernier cas, les temps d'attente SONT problématiques et dépassent largement les trois secondes requises pour tes solutions !
Et en plus, on n'a pas le droit de fumer dans les écoles, alors ta soluce ne tient pas B-)
C'est fou ce qu'on peut en faire comme chose en 3 secondes !!! ;-)
- Allumer une cigarette
- Faire craquer ses doigts
- Bailler un bon coup
...
Les trois secondes ne me causent pas de problème, j'ai oublié de
spécifier : ce temps pourrait me convenir s'il était le même partout.
Ici, avec un lien fibre optique, trois secondes c'est bien normal. Dans
les installations chez mes "clients" (des bibliothèques scolaires), les
liens avec le serveur SQL vont de lien fibre à accès ADSL 128K. Dans ce
dernier cas, les temps d'attente SONT problématiques et dépassent
largement les trois secondes requises pour tes solutions !
Et en plus, on n'a pas le droit de fumer dans les écoles, alors ta
soluce ne tient pas B-)
C'est fou ce qu'on peut en faire comme chose en 3 secondes !!! ;-) - Allumer une cigarette - Faire craquer ses doigts - Bailler un bon coup ...
Les trois secondes ne me causent pas de problème, j'ai oublié de spécifier : ce temps pourrait me convenir s'il était le même partout. Ici, avec un lien fibre optique, trois secondes c'est bien normal. Dans les installations chez mes "clients" (des bibliothèques scolaires), les liens avec le serveur SQL vont de lien fibre à accès ADSL 128K. Dans ce dernier cas, les temps d'attente SONT problématiques et dépassent largement les trois secondes requises pour tes solutions !
Et en plus, on n'a pas le droit de fumer dans les écoles, alors ta soluce ne tient pas B-)
Attention simplement a ne pas accéder a un objet de ta fenetre depuis le thread secondaire (vois la doc). Si tu n'effectues que des traitements sur les fichiers Hyper File, pas de probleme.
Bonsoir Antoine,
Peux-tu préciser, stp? Chez moi cela ne fonctionne pas. L'ouverture de la fenêtre ou l'entrée dans une combo alimenté par une requête, et exécuté dans le thread, fait planter le programme puisque la fenêtre ne trouve pas la source de donnée. Je n'ai mis du code que dans deux endroits:
Déclaration globale de la fenêtre --------------------------------- ThreadExecute("NomThread",threadNormal,"NomProcédure")
Procédure locale de la fenêtre "NomProcédure" --------------------------------------------- HExecuteQuery(NomRequête1,hQueryDefault) HExecuteQuery(NomRequête2,hQueryDefault) etc
Merci Mat
Antoine wrote:
Attention simplement a ne pas accéder a un objet de ta fenetre depuis le
thread secondaire (vois la doc). Si tu n'effectues que des traitements sur
les fichiers Hyper File, pas de probleme.
Bonsoir Antoine,
Peux-tu préciser, stp? Chez moi cela ne fonctionne pas. L'ouverture de
la fenêtre ou l'entrée dans une combo alimenté par une requête, et
exécuté dans le thread, fait planter le programme puisque la fenêtre ne
trouve pas la source de donnée. Je n'ai mis du code que dans deux endroits:
Déclaration globale de la fenêtre
---------------------------------
ThreadExecute("NomThread",threadNormal,"NomProcédure")
Procédure locale de la fenêtre "NomProcédure"
---------------------------------------------
HExecuteQuery(NomRequête1,hQueryDefault)
HExecuteQuery(NomRequête2,hQueryDefault)
etc
Attention simplement a ne pas accéder a un objet de ta fenetre depuis le thread secondaire (vois la doc). Si tu n'effectues que des traitements sur les fichiers Hyper File, pas de probleme.
Bonsoir Antoine,
Peux-tu préciser, stp? Chez moi cela ne fonctionne pas. L'ouverture de la fenêtre ou l'entrée dans une combo alimenté par une requête, et exécuté dans le thread, fait planter le programme puisque la fenêtre ne trouve pas la source de donnée. Je n'ai mis du code que dans deux endroits:
Déclaration globale de la fenêtre --------------------------------- ThreadExecute("NomThread",threadNormal,"NomProcédure")
Procédure locale de la fenêtre "NomProcédure" --------------------------------------------- HExecuteQuery(NomRequête1,hQueryDefault) HExecuteQuery(NomRequête2,hQueryDefault) etc
Merci Mat
Romain PETIT
Antoine a exposé le 22/08/2004 :
Yanick Charland wrote:
Une idée géniale (jusqu'à preuve du contraire :D) m'est alors venue : pourquoi ne pas lancer toutes ces opérations dans des threads secondaires (non bloquants) dans l'initialisation du projet ! Alors, je devrais sauver quelques précieuses secondes dans l'exécution...
Attention simplement a ne pas accéder a un objet de ta fenetre depuis le thread secondaire (vois la doc). Si tu n'effectues que des traitements sur les fichiers Hyper File, pas de probleme.
Hum hum, comment fait-il alors pour initialiser ses champs dans un thread secondaire sans accéder à des objets de la fenêtre ?
A+
-- Romain PETIT http://cerbermail.com/?IJmancZl88 (cliquez sur le lien ci-dessus pour me contacter en privé)
Antoine a exposé le 22/08/2004 :
Yanick Charland wrote:
Une idée géniale (jusqu'à preuve du contraire :D) m'est alors venue :
pourquoi ne pas lancer toutes ces opérations dans des threads
secondaires (non bloquants) dans l'initialisation du projet ! Alors,
je devrais sauver quelques précieuses secondes dans l'exécution...
Attention simplement a ne pas accéder a un objet de ta fenetre depuis le
thread secondaire (vois la doc). Si tu n'effectues que des traitements sur
les fichiers Hyper File, pas de probleme.
Hum hum, comment fait-il alors pour initialiser ses champs dans un
thread secondaire sans accéder à des objets de la fenêtre ?
A+
--
Romain PETIT
http://cerbermail.com/?IJmancZl88
(cliquez sur le lien ci-dessus pour me contacter en privé)
Une idée géniale (jusqu'à preuve du contraire :D) m'est alors venue : pourquoi ne pas lancer toutes ces opérations dans des threads secondaires (non bloquants) dans l'initialisation du projet ! Alors, je devrais sauver quelques précieuses secondes dans l'exécution...
Attention simplement a ne pas accéder a un objet de ta fenetre depuis le thread secondaire (vois la doc). Si tu n'effectues que des traitements sur les fichiers Hyper File, pas de probleme.
Hum hum, comment fait-il alors pour initialiser ses champs dans un thread secondaire sans accéder à des objets de la fenêtre ?
A+
-- Romain PETIT http://cerbermail.com/?IJmancZl88 (cliquez sur le lien ci-dessus pour me contacter en privé)
Romain PETIT
Le 22/08/2004, Antoine a supposé :
Attention simplement a ne pas accéder a un objet de ta fenetre depuis le thread secondaire (vois la doc). Si tu n'effectues que des traitements sur les fichiers Hyper File, pas de probleme.
La doc en WD7.5 ne précise pas cette limitation de ne pas accéder aux champs via un thread secondaire. C'est précisé en WD8 ?
A+
-- Romain PETIT http://cerbermail.com/?IJmancZl88 (cliquez sur le lien ci-dessus pour me contacter en privé)
Le 22/08/2004, Antoine a supposé :
Attention simplement a ne pas accéder a un objet de ta fenetre depuis le
thread secondaire (vois la doc). Si tu n'effectues que des traitements sur
les fichiers Hyper File, pas de probleme.
La doc en WD7.5 ne précise pas cette limitation de ne pas accéder aux
champs via un thread secondaire.
C'est précisé en WD8 ?
A+
--
Romain PETIT
http://cerbermail.com/?IJmancZl88
(cliquez sur le lien ci-dessus pour me contacter en privé)
Attention simplement a ne pas accéder a un objet de ta fenetre depuis le thread secondaire (vois la doc). Si tu n'effectues que des traitements sur les fichiers Hyper File, pas de probleme.
La doc en WD7.5 ne précise pas cette limitation de ne pas accéder aux champs via un thread secondaire. C'est précisé en WD8 ?
A+
-- Romain PETIT http://cerbermail.com/?IJmancZl88 (cliquez sur le lien ci-dessus pour me contacter en privé)
Antoine
Romain PETIT wrote:
Le 22/08/2004, Antoine a supposé :
Attention simplement a ne pas accéder a un objet de ta fenetre depuis le thread secondaire (vois la doc). Si tu n'effectues que des traitements sur les fichiers Hyper File, pas de probleme.
La doc en WD7.5 ne précise pas cette limitation de ne pas accéder aux champs via un thread secondaire. C'est précisé en WD8 ?
A+
Tu trouveras des infos dans la doc des thread sur le lien "Gérer l'ouverture d'une fenêtre dans un thread secondaire". Cet exemple est valable pour l'ouvertur de fenetre mais qussi pou lma mise à jour de champs. Le principe est inclus d'apres la doc dans l'exemple "WD8 Messagerie instantanée".
Antoine
Romain PETIT wrote:
Le 22/08/2004, Antoine a supposé :
Attention simplement a ne pas accéder a un objet de ta fenetre
depuis le thread secondaire (vois la doc). Si tu n'effectues que des
traitements sur les fichiers Hyper File, pas de probleme.
La doc en WD7.5 ne précise pas cette limitation de ne pas accéder aux
champs via un thread secondaire.
C'est précisé en WD8 ?
A+
Tu trouveras des infos dans la doc des thread sur le lien "Gérer l'ouverture
d'une fenêtre dans un thread secondaire". Cet exemple est valable pour
l'ouvertur de fenetre mais qussi pou lma mise à jour de champs.
Le principe est inclus d'apres la doc dans l'exemple "WD8 Messagerie
instantanée".
Attention simplement a ne pas accéder a un objet de ta fenetre depuis le thread secondaire (vois la doc). Si tu n'effectues que des traitements sur les fichiers Hyper File, pas de probleme.
La doc en WD7.5 ne précise pas cette limitation de ne pas accéder aux champs via un thread secondaire. C'est précisé en WD8 ?
A+
Tu trouveras des infos dans la doc des thread sur le lien "Gérer l'ouverture d'une fenêtre dans un thread secondaire". Cet exemple est valable pour l'ouvertur de fenetre mais qussi pou lma mise à jour de champs. Le principe est inclus d'apres la doc dans l'exemple "WD8 Messagerie instantanée".
Antoine
Yanick Charland
Antoine a exprimé avec précision :
Romain PETIT wrote:
Le 22/08/2004, Antoine a supposé :
Attention simplement a ne pas accéder a un objet de ta fenetre depuis le thread secondaire (vois la doc). Si tu n'effectues que des traitements sur les fichiers Hyper File, pas de probleme.
Jusqu'à présent, seul la commande FichierVersTableMémoire cause un problème lorsqu'exécuté dans un thread secondaire... sinon, aucun problème à remplir les champs d'une fenêtre de manière simultanée.
En passant, les tests réalisés jusqu'ici me donnent satisfaction. J'en arrive donc à la conclusion que c'était pas une si mauvaise idée que j'ai eue et qu'il n'y a pas trop de danger à l'utiliser (si j'en crois le peu de points à vérifier qui ont été soulevés).
Attention simplement a ne pas accéder a un objet de ta fenetre
depuis le thread secondaire (vois la doc). Si tu n'effectues que des
traitements sur les fichiers Hyper File, pas de probleme.
Jusqu'à présent, seul la commande FichierVersTableMémoire cause un
problème lorsqu'exécuté dans un thread secondaire... sinon, aucun
problème à remplir les champs d'une fenêtre de manière simultanée.
En passant, les tests réalisés jusqu'ici me donnent satisfaction. J'en
arrive donc à la conclusion que c'était pas une si mauvaise idée que
j'ai eue et qu'il n'y a pas trop de danger à l'utiliser (si j'en crois
le peu de points à vérifier qui ont été soulevés).
Attention simplement a ne pas accéder a un objet de ta fenetre depuis le thread secondaire (vois la doc). Si tu n'effectues que des traitements sur les fichiers Hyper File, pas de probleme.
Jusqu'à présent, seul la commande FichierVersTableMémoire cause un problème lorsqu'exécuté dans un thread secondaire... sinon, aucun problème à remplir les champs d'une fenêtre de manière simultanée.
En passant, les tests réalisés jusqu'ici me donnent satisfaction. J'en arrive donc à la conclusion que c'était pas une si mauvaise idée que j'ai eue et qu'il n'y a pas trop de danger à l'utiliser (si j'en crois le peu de points à vérifier qui ont été soulevés).
Jusqu'à présent, seul la commande FichierVersTableMémoire cause un problème lorsqu'exécuté dans un thread secondaire... sinon, aucun problème à remplir les champs d'une fenêtre de manière simultanée.
En passant, les tests réalisés jusqu'ici me donnent satisfaction. J'en arrive donc à la conclusion que c'était pas une si mauvaise idée que j'ai eue et qu'il n'y a pas trop de danger à l'utiliser (si j'en crois le peu de points à vérifier qui ont été soulevés).
Bonjour Yannick,
Je fais la même chose et n'ai aucun problème avec des combos remplis par programmation. Pourtant je n'arrive pas à remplir des combos alimentés par une requête car Windev dans le thread principal réclame la non-existence du fichier sql... Comment tu fais, stp? Merci d'avance. Mat
Yanick Charland wrote:
Jusqu'à présent, seul la commande FichierVersTableMémoire cause un
problème lorsqu'exécuté dans un thread secondaire... sinon, aucun
problème à remplir les champs d'une fenêtre de manière simultanée.
En passant, les tests réalisés jusqu'ici me donnent satisfaction. J'en
arrive donc à la conclusion que c'était pas une si mauvaise idée que
j'ai eue et qu'il n'y a pas trop de danger à l'utiliser (si j'en crois
le peu de points à vérifier qui ont été soulevés).
Bonjour Yannick,
Je fais la même chose et n'ai aucun problème avec des combos remplis par
programmation. Pourtant je n'arrive pas à remplir des combos alimentés
par une requête car Windev dans le thread principal réclame la
non-existence du fichier sql... Comment tu fais, stp?
Merci d'avance.
Mat
Jusqu'à présent, seul la commande FichierVersTableMémoire cause un problème lorsqu'exécuté dans un thread secondaire... sinon, aucun problème à remplir les champs d'une fenêtre de manière simultanée.
En passant, les tests réalisés jusqu'ici me donnent satisfaction. J'en arrive donc à la conclusion que c'était pas une si mauvaise idée que j'ai eue et qu'il n'y a pas trop de danger à l'utiliser (si j'en crois le peu de points à vérifier qui ont été soulevés).
Bonjour Yannick,
Je fais la même chose et n'ai aucun problème avec des combos remplis par programmation. Pourtant je n'arrive pas à remplir des combos alimentés par une requête car Windev dans le thread principal réclame la non-existence du fichier sql... Comment tu fais, stp? Merci d'avance. Mat
