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.
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
Salut Mat,
Pour mes requêtes, j'interroge directement mon serveur SQL 7 via les instructions HExecuteRequeteSQL en lui passant le code de la requête à exécuter. Je dois dire que je n'ai jamais bien aimé le fonctionnement des objets Requête de WinDev, du moins l'interaction entre SQL Server et le générateur de requêtes de WinDev.
Je déclare donc localement, dans chaque procédure qui est appelée par un thread, un objet source de données qui me permet d'accéder à mes données retournées par ma requête. Cet objet porte un nom unique pour ne pas entrer en conflit avec d'autres objets qui pourraient rouler en même temps (dans d'autres threads par exemple).
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
Salut Mat,
Pour mes requêtes, j'interroge directement mon serveur SQL 7 via les
instructions HExecuteRequeteSQL en lui passant le code de la requête à
exécuter. Je dois dire que je n'ai jamais bien aimé le fonctionnement
des objets Requête de WinDev, du moins l'interaction entre SQL Server
et le générateur de requêtes de WinDev.
Je déclare donc localement, dans chaque procédure qui est appelée par
un thread, un objet source de données qui me permet d'accéder à mes
données retournées par ma requête. Cet objet porte un nom unique pour
ne pas entrer en conflit avec d'autres objets qui pourraient rouler en
même temps (dans d'autres threads par exemple).
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
Salut Mat,
Pour mes requêtes, j'interroge directement mon serveur SQL 7 via les instructions HExecuteRequeteSQL en lui passant le code de la requête à exécuter. Je dois dire que je n'ai jamais bien aimé le fonctionnement des objets Requête de WinDev, du moins l'interaction entre SQL Server et le générateur de requêtes de WinDev.
Je déclare donc localement, dans chaque procédure qui est appelée par un thread, un objet source de données qui me permet d'accéder à mes données retournées par ma requête. Cet objet porte un nom unique pour ne pas entrer en conflit avec d'autres objets qui pourraient rouler en même temps (dans d'autres threads par exemple).
Pour mes requêtes, j'interroge directement mon serveur SQL 7 via les instructions HExecuteRequeteSQL en lui passant le code de la requête à exécuter. Je dois dire que je n'ai jamais bien aimé le fonctionnement des objets Requête de WinDev, du moins l'interaction entre SQL Server et le générateur de requêtes de WinDev.
Je déclare donc localement, dans chaque procédure qui est appelée par un thread, un objet source de données qui me permet d'accéder à mes données retournées par ma requête. Cet objet porte un nom unique pour ne pas entrer en conflit avec d'autres objets qui pourraient rouler en même temps (dans d'autres threads par exemple).
Bonne chance !
Merci pour cette info, je comprends maintenant. Je préfère ne pas toucher aux sources de données des combos pour l'instant, mais éventuellement, je vais changer la stucture de la requête principale qui fait trainer le reste (à cause de totalisations et HNbEnr, etc). Mat
Yanick Charland wrote:
Salut Mat,
Pour mes requêtes, j'interroge directement mon serveur SQL 7 via les
instructions HExecuteRequeteSQL en lui passant le code de la requête à
exécuter. Je dois dire que je n'ai jamais bien aimé le fonctionnement
des objets Requête de WinDev, du moins l'interaction entre SQL Server et
le générateur de requêtes de WinDev.
Je déclare donc localement, dans chaque procédure qui est appelée par un
thread, un objet source de données qui me permet d'accéder à mes données
retournées par ma requête. Cet objet porte un nom unique pour ne pas
entrer en conflit avec d'autres objets qui pourraient rouler en même
temps (dans d'autres threads par exemple).
Bonne chance !
Merci pour cette info, je comprends maintenant. Je préfère ne pas
toucher aux sources de données des combos pour l'instant, mais
éventuellement, je vais changer la stucture de la requête principale qui
fait trainer le reste (à cause de totalisations et HNbEnr, etc).
Mat
Pour mes requêtes, j'interroge directement mon serveur SQL 7 via les instructions HExecuteRequeteSQL en lui passant le code de la requête à exécuter. Je dois dire que je n'ai jamais bien aimé le fonctionnement des objets Requête de WinDev, du moins l'interaction entre SQL Server et le générateur de requêtes de WinDev.
Je déclare donc localement, dans chaque procédure qui est appelée par un thread, un objet source de données qui me permet d'accéder à mes données retournées par ma requête. Cet objet porte un nom unique pour ne pas entrer en conflit avec d'autres objets qui pourraient rouler en même temps (dans d'autres threads par exemple).
Bonne chance !
Merci pour cette info, je comprends maintenant. Je préfère ne pas toucher aux sources de données des combos pour l'instant, mais éventuellement, je vais changer la stucture de la requête principale qui fait trainer le reste (à cause de totalisations et HNbEnr, etc). Mat
