cs_Ptinico
Messages postés4Date d'inscriptionvendredi 20 décembre 2002StatutMembreDernière intervention31 mai 2007
-
3 mai 2007 à 21:03
cs_Ptinico
Messages postés4Date d'inscriptionvendredi 20 décembre 2002StatutMembreDernière intervention31 mai 2007
-
4 mai 2007 à 21:40
Salut,
Question toute bête :
- J'ai un fichier Excel ouvert contenant un macro déclenchée par un "Worksheet_SelectionChange"
- Depuis Delphi, je me connecte au fichier Excel ouvert (par OLE), je remplis la case qui va bien, puis je selectionne une autre case. Ca force donc le "Worksheet_SelectionChange" de Excel.
Par contre, je veux conserver la main sur mon application Delphi, sans attendre la fin de l'éxecution de la macro Excel....
Qq'un a une idée ? J'ai essayé les thread, mais le "GetActiveOleObject" ne semble pas fonctionner dans un thread !!
Merci d'avance.
florenth
Messages postés1023Date d'inscriptiondimanche 1 août 2004StatutMembreDernière intervention17 août 20083 4 mai 2007 à 13:33
Salut à tous
@Cari: il est possible d'utiliser OLE dans un thread. Il faut juste faire attention à plusieurs trucs:
- Si tu utilises le type TThread de Delphi, il faut absolument tout faire dans le méthode Execute() car c'est la seule qui est réellement threadée (donc, tu ne peux pas initialiser OLE dans le constructeur et l'utiliser dans Execute()).
- Ensuite, il ne faut pas oublier d'initialiser OLE et de le libérer DANS ce même thread (Delphi le fait par défaut dans le thread principal mais pas dans les autres)
- Donc, appel de CoInitialize(nil) au début et CoUnInitialize() à la fin.
- Donc, bien sûr, Variants, ActiveX et ComObj dans les uses.
- Et ensuite, tout fonctionne ! Faire gaffe à ne pas utiliser la même instance dans un autre thread, ça plante sinon ...
- Préférer CreateOLEObject('Excel.Application') plutôt que GetActiveOLEObject().
Caribensila
Messages postés2527Date d'inscriptionjeudi 15 janvier 2004StatutMembreDernière intervention16 octobre 201918 3 mai 2007 à 22:56
Salut!
Je crois que tu es mal barré, là.
L'idée de OLE est qu'une application en contienne une autre.
C'est une technique qui permet d'inclure dans ton application un document d'une autre application.
Mais, à ma connaissance, y'a pas de
threading possible.
Ton idée d'utilser un
thread secondaire me semble prouver que
ton problème, si j'ai bien compris, c'est plutôt un problème de multitâche...
Moi, perso, j'abandonnerais l'idée d'OLE et je lancerais les deux applications séparément. Ce qui revient à dire 2 processus ou 2 threads (Problème du multitâche résolu).
Ensuite, il suffira de les faire communiquer.
Et y'a plein de techniques pour ça dont tu trouveras les exemples ici.
cs_Ptinico
Messages postés4Date d'inscriptionvendredi 20 décembre 2002StatutMembreDernière intervention31 mai 2007 4 mai 2007 à 19:25
Flo, t'es un chef. Merci vraiment !
J'y étais presque, manquait que le CoInitialize et le CoUnInitialize. J'avais déjà remarqué que dans les DLL les librairies COM n'étaient pas forcément initialisées correctement.
Voilà mon unité du thread. Pour info, même le GetActiveOleObject fonctionne !
cs_Ptinico
Messages postés4Date d'inscriptionvendredi 20 décembre 2002StatutMembreDernière intervention31 mai 2007 4 mai 2007 à 21:40
C'est un copier coller malencontreux d'un bout de code qui trainait chez moi ds un coin.
Ca marche effectivement juste avec la ligne indiquée.
Merci encore pour ton aide.
PS : le but de mon appli :
- aller chercher dans le port série un poids transmis par une balance, qui pèse des pièces produites en série par une presse
- compiler en temps réel ces poids, les faire manger à un algo qui décide s'il faut corriger le programme Excel de la presse
- envoyer le poids corrigé à Excel pour qu'il recalcule le nouveau programme
- envoyer enfin un message via TPC/IP à la presse pour qu'elle s'arrête, mange le programme recalculé, et redémarre.
Tout ça en temps réel.
Grace à toi je vois maintenant le bout du tunnel, tout ce qui était port série + tcp/ip marche déjà en multi-thread..