Bon, je me permet de poster une petite question concernant un petit problème qui me cause actuellement un grand soucis en espérant quelques petites aides qui, mises bout à bout, me donneront la grosse solution !!
Grand 1, Explication sur ce qui se passe :
Lors du traitement d’une feuille Excel (processus qui peut durer plusieurs minutes) en automation depuis notre soft, un problème survenait lorsque l’utilisateur, impatient, basculait sur Microsoft Excel (déjà ouvert) et commençait à s’amuser avec ce dernier. Le soft plantait tout simplement.
La solution fut de détecter tous les processus de Microsoft Excel et de les désactiver pour que l’utilisateur ne puisse plus les utiliser durant le temps de traitement du soft.
Le problème a été résolu… mais…
Grand 2, mon problème :
Ce qui fait planter le soft, désormais, c’est que certains utilisateurs ont la fonction “Sauvegarde automatique” d’Excel activée. Du coup, même si l’utilisateur ne peut plus faire planter le soft en utilisant Excel, ce dernier s’active tout seul à cause de la sauvegarde automatique et donc … fait planter mon soft.
Et enfin … conclusion :
D’où ma question (après avoir pas mal cherché : Y a t-il un moyen (ou une autre piste/solution) pour désactiver les processus Excel existants afin de les rendre complètement inactifs (et pouvoir les réactiver bien entendu le moment voulu), même leur fonction de sauvegarde automatique (les endormir un laps de temps) ?
Merci à tous !
Cha Ce message a été édité par chalupit le 03/12/2003
Et si tu désactives la sauvegarde automatique, par programmation, juste avant ton truc et que tu la remets après ? ça serait pas plus simple que de monter une usine à gaz ? Ce message a été édité par phili_b le 03/12/2003
Je vais faire une réponse de mémoire, il va donc falloir que tu vérifies :
Sous VC++ tu récupères la liste des processus/applications Excel (méthode des MFCs) => tu vas récupérer une variablr de type (CWnd *) ou bien (HWND) ensuite tu n’as plus qu’à lui envoyer le message : SUSPEND…
Bon, voilà une méthode, maintenant il faut que tu te débrouilles.
[quote]Je vais faire une réponse de mémoire, il va donc falloir que tu vérifies :
Sous VC++ tu récupères la liste des processus/applications Excel (méthode des MFCs) => tu vas récupérer une variablr de type (CWnd *) ou bien (HWND) ensuite tu n’as plus qu’à lui envoyer le message : SUSPEND…
Bon, voilà une méthode, maintenant il faut que tu te débrouilles.[/quote]J’allais lui conseiller de voir la même méthode. Ou sinon :
ParametershThread [in] Handle to the thread that is to be suspended.
The handle must have the THREAD_SUSPEND_RESUME access right. For more information, see Thread Security and Access Rights.
comme le dit la doc il te faut une handle sur le thread en question et gérer les droit d’access.
Et je ne suis pas du tout sur que ça puisse fonctionner (je suis meme pas sûr que tu puisse recuperer le(la?) handle sur le bon thread).
May the force be with you.
Ce message a été édité par Kane–sama le 03/12/2003 Ce message a été édité par Kane–sama le 03/12/2003
Question toute bête tiens : est-ce qu’il ne serait pas plus intéressant de tout simplement chercher POURQUOI ça fait planter ton application ? Et, une fois le bug localisé… corriger le problème ? A priori le problème semble facilement reproductible, donc la seule difficulté (qui peut être majeure hein, c’est pas forcément évident) consiste à trouver la solution du crash. Je me trompe ?
Personnellement (mais ça n’engage que moi), je préfére trouver une solution au problème plutôt que de mettre une rustine. Parce que la rustine, elle a des limites… et que tu trouvera toujours un nouveau cas qui fait planter ton application.
Cela dit je ne connais pas ton code, ça se trouve il est blindé et le problème se situe uniquement du coté Excel de la chose auquel cas tu ne pourrais rien faire. Mais vu que tu semble dire que le crash se situe dans ton application…
Voui voui, je suis tout à fait d’accord ! Je n’aurais pas mieux dit. Mais là, le temps joue contre nous donc la rustine c’est pour faire valider le soft à très court terme. La correction du bug ce sera plutôt du moyen terme.
J’aurais pas mieux dit que tuo. Certes ça va être validé, mais ne pas trouver ce bug c’est un calcul à court terme qui va revenir très cher à tout le monde (client et fournisseur).
ça sent la maintenance de longue durée avec à chaque fois un intervenant diffèrent. La joie pour les utilisateurs!
[quote]J’aurais pas mieux dit que tuo. Certes ça va être validé, mais ne pas trouver ce bug c’est un calcul à court terme qui va revenir très cher à tout le monde (client et fournisseur).
ça sent la maintenance de longue durée avec à chaque fois un intervenant diffèrent. La joie pour les utilisateurs![/quote]je pense qu’il cherche à rustiner pour pouvoir valider le produit global (présentation client par exemple) et qu’il va corriger ensuite correctement.
enfin, c’est ce que j’ai compris…
Je n’ai donc pas de solution à court terme à te proposer, je ne connais pas suffisamment Excel et ce genre de choses pour ça. Cela dit, le suspend de thread risque de t’être difficile, je doute que ton appli ait les droits nécessaires pour faire ça à Excel (mais bon, on sait jamais, j’ai jamais testé en fait).
Sinon, ça m’intéresserait de savoir le fin mot de l’histoire et de savoir combien de temps ça a pris cette rustine. Je me souviens d’un jour où mon “patron” (je suis dans un système “à la” SSII mais pour le jeux video, donc c’était en fait mon client) m’a demandé de faire une rustine pour un problème de crash… et bien, après correction du bug (après avoir mis la rustine et que le tout ait été validé, je me suis aperçu que j’avais corrigé le bug plus vite que la rustine n’avait été mise en place C’est pour ça que, depuis, je suis très réticent à ce genre de solution.
Je fais remonter le thread pour donner un peu les résultats des essais :
Les tests ne se sont pas montrés très concluant, mais pour le client ça s’est bien passé… grosse goutte de sueur quand même!
On s’est penché depuis sur la résolution de ce bug et je m’en vais de ce pas vous donner quelques infos sur le sujet :
Il se trouve que pour une automation OLE embarquée, je veux dire par là que le but est d’intégrer l’application (ici Excel) cible dans notre soft et non pas la piloter à distance, le système regarde si un processus de l’application cible (donc toujours Excel, il n’a pas changé celui là ) est lancé ou pas.
Si l’utilisateur a, au préalable, lancé Excel alors le système ce sert de ce processus comme serveur OLE et colle notre feuille Excel embarquée à ce dernier.
Donc (pour les deux du fond), notre feuille Excel embarquée et Microsoft Excel (le vrai) partage tous les deux le même processus (les mêmes fonctions, les mêmes préférences/Propriétés etc…) … et c’est là que le bât blesse (en tout cas pour moi), il y a des moments où des conflits apparaissent (notamment pour le coup de l’autosave qui se déclenche pour les deux)…
Alors que (solution idéale, Ô combien idéale!) si l’utilisateur n’a pas lancé Excel au préalable, le système en lance un exprès pour notre petite feuille Excel embarquée et là… plus aucun problème. Pourquoi ? Parce que tous les Excel lancés après coup utilisent chacun un processus indépendant (à titre indicatif, dans la suite Office, il n’y a que powerpoint qui n’est pas multi-instances).
Donc la solution serait de forcer notre automation à lancer un nouveau processus Excel à chaque fois qu’il est exécuté (qu’un Excel soit déjà lancé ou pas à coté )…Chaud, très chaud apparemment parce que ce n’est pas la méthode habituelle. On est en train de chercher…
PS-Merci encore d’avoir répondu
Edit : Tiens y a des smileys qui se sont glissés sans crier gare !?