 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
VB Forum / COM / August 2005Get an Office Application Instance from a ProcessID?
Hey Folks, Since I know how to enumerate and obtain ProcessIDs, I was wondering how one could actually gain automation control of an Office Suite App once the ProcessID was obtained? Thanks & Regards, Todd Todd, Could you not use GetObject ? NickHK > Hey Folks, > [quoted text clipped - 5 lines] > > Todd GetObject works great when there's only a singular instance of the application running. I need to loop through the processes and then loop through the matching processes yet again in order to be sure I have the appropriate instance. For example, if a user happens to be running 2 instances MS Word then enumerating processes would return 2 Winword.exe processes. I would then to gain control of each instance of the Word application based upon the processID and then check to see which instance I need. Based upon the processID, how can I gain control of the application? Regards, Todd > Todd, > Could you not use GetObject ? [quoted text clipped - 11 lines] >> >> Todd What problem are you trying to solve that requires you to get a specific instance? It is rare and probably not necessary to specify which process of an automation server to use in order to use the server. I tried to get more than one instance of Word (WinWord) to execute, but I did not succeed. What version of Word are you using? > GetObject works great when there's only a singular instance of the > application running. I need to loop through the processes and then loop [quoted text clipped - 27 lines] >>> >>> Todd > GetObject works great when there's only a singular instance of the > application running. I need to loop through the processes and then loop [quoted text clipped - 27 lines] > >> > >> Todd "If multiple instances of the application you want to automate are running, there is no way to guarantee which instance the GetObject function will return." It is almost impossible without some extraordinary effort on the part of the running instance. When you invoke any of the COM creators (GetObject, CreateObject, CreateInstance, etc.), COM launches a ClassFactory which uses its own rules for seeking out and creating an Interface. No where in that process does the ProcessID show up. However, one can never say never when it comes to programming. It is all 1s and 0s at some point, and there are a zillion ways to fiddle with 1s and 0s. (You could play with the ROT). I would question why you want or feel you need to do this? If you need to massage a particular file you can call GetObject with the file name. This often works in Word as it is really a complex "MDI" in an "SDI" format. (???) If it is to provide some kind of custom programming for a particular instance of Word, then you may be better off by creating an ActiveX component for that a particular instance of Word to invoke. If it is to avoid confusion with other running instances - then create your own and keep it hidden. If it is to provide some kind of ipc, then you might be better served to use FindWindow and messaging. While it may appear simple on the POW. Designing an app that seeks out specific instances of running programmings, that may or may not be there, is bound to be fragile and overly complex. But that's just my opinion, and I am often wrong. -ralph I once tried to do something of this sort in order to be able to auto-connect between our application and an instance of Excel running with our COM addin, so that they could share state as the user wanted. The basic technique consists of scanning the ROT (use Edamno's interface code) to get there. The biggest problem you'll face is that a Word instance might - "by design" - not be in the ROT, either becuase it hasn't registered itself yet (see KB238610), or because it has decided that theres no need to as there's already an instance in the ROT (KB238975). KB238975 also explains why having the process handle won't help you - "by design" - attach from your VB client (why there's no mapping). We eventually ditched the whole caboodle. We added a menu command / button to our application to launch an Excel (CreateObject) and tie in our COM Addin. Our Addin tested if it had been given out application's handle, and warned the user if not that he would be unable to see any "state" outside of Excel as he hadn't started Excel from our application. We have since added Word. User acceptance of this solution was not a problem- in fact the users are quite happy. > GetObject works great when there's only a singular instance of the > application running. I need to loop through the processes and then loop [quoted text clipped - 27 lines] >>> >>> Todd > We added a menu command / button to our application to launch an Excel > (CreateObject) and tie in our COM Addin. You know more than I about most of that, but I think I would have done something like that. There is probably many ways for the application and add-in to find each other. I would not mind making suggestions, but I might not have any that you have not already thought of. Perhaps that would be relevant to this thread but if not then perhaps the suggestions should be continued elsewhere. > > We added a menu command / button to our application to launch an Excel > > (CreateObject) and tie in our COM Addin. [quoted text clipped - 7 lines] > thread but if not then perhaps the suggestions should be continued > elsewhere. By all means offer a suggestion if you have one, but bare in mind the question on the table, is how to instantance a COM interface with a specific instance of multiple running instances of a ActiveX Exec server. It is not a matter of just creating a line of communication with another instance - one could do that with FindWindow and simple Messaging. You can do that thru the ROT, however, it has been my experience, that Word (and many other servers) don't necessary update the ROT as expected. I have therefore given up on designing any system that depends on creating such a relationship, and sought out other solutions. However, I may have missed something and bailed too soon. If you know of something that works, please share it. -ralph > By all means offer a suggestion if you have one, but bare in mind the > question on the table, is how to instantance a COM interface with a > specific > instance of multiple running instances of a ActiveX Exec server. Note that there are two or three tables. There is the one for Todd (TMan), another for Mark and possibly a third for you. I have already indicated that the one for Mark might not be relevant here. The Running Object Table (ROT) is designed to allow connection with objects, not processes. It sure makes sense to me that anyone trying to use the ROT to connect to a process might get caught trying to go upstream and would (excuse me, I just have to say this) end up rotting. >> We added a menu command / button to our application to launch an Excel >> (CreateObject) and tie in our COM Addin. [quoted text clipped - 7 lines] > thread but if not then perhaps the suggestions should be continued > elsewhere. One of the things that prevented simple "shared memory or the like" approaches in our case, was that not only was our application not single-instance, but that it was both TS and RunAs capable (BTW, that led to a W2K security bug report to MS that got a hotfix). >>> We added a menu command / button to our application to launch an Excel >>> (CreateObject) and tie in our COM Addin. [quoted text clipped - 12 lines] > single-instance, but that it was both TS and RunAs capable (BTW, that led > to a W2K security bug report to MS that got a hotfix). You probably have already considered use of messages for your application and add-in to find each other. If you need to exchange more data than that and shared memory is not possible, then another possibility is sockets (TCP/IP). The IPC section of the SDK documentation also lists COM as a possibility. Have you considered that? I assume your addin is a server, but you could also make your application a server that the addin uses to find your application. Is that possible? That might not help Todd or Ralph, but perhaps it would help Mark. >>>> We added a menu command / button to our application to launch an Excel >>>> (CreateObject) and tie in our COM Addin. [quoted text clipped - 22 lines] > also make your application a server that the addin uses to find your > application. Is that possible? Our addin is a COM object, and our application is full DCOM. All communication between all components is via (D)COM. The problem is not in getting the two to find an instance of each other, but ensuring they've found the "right" partner (which includes ensuring they're in the same TS session and running under the same security principal). Sockets would be a _very bad idea_ as they're far too low-level. Merely thinking about the amount of coding necessary to get secure communication, including Kerberos delegation, gives me the heeby jeebies. And that doesn't even begin to address the application issues. I'll stick to DCOM (and skip .NET questions, as this is a VB6 forum). As I said at the beginning of my response, we don't have a "problem" - our users are quite happy to hit the button marked "Excel" in our application's GUI to get an instance of Excel whose lifetime we can correctly control (we need to handle some Excel workbook and worksheet events to do this). > That might not help Todd or Ralph, but perhaps it would help Mark. > Our addin is a COM object, and our application is full DCOM. All > communication between all components is via (D)COM. The problem is not in > getting the two to find an instance of each other, but ensuring they've > found the "right" partner (which includes ensuring they're in the same TS > session and running under the same security principal). It seems to me that if the communication can occur when the application is started first, then all that complicated stuff is done somehow. > Merely thinking about the amount of coding necessary to get secure > communication, including Kerberos delegation, gives me the heeby jeebies. Previously, you said something about the addin not finding the application if Excel is started after the application is started. If the application is started first, then either all that extra stuff must be done then or it does not. There are many other things that are confuing about your description of the requirements. So of course I can't suggest anything without a more clearly definition of the requirements. It's OK Sam, I haven't asked a question - I was responding to the OP's question "how one could actually gain automation control of an Office Suite App once the ProcessID was obtained?" by pointing out that one can't in general, as Windows doesn't "work that way". As far as our application is concerned, the "problem" has been addressed in a manner that the users are quite content to deal with. They ask our application to launch Excel, and we then establish all the plumbing with a new Excel instance. If they use our addin from an Excel launched "externally", we warn them of the "consequences". >> Our addin is a COM object, and our application is full DCOM. All >> communication between all components is via (D)COM. The problem is not in [quoted text clipped - 17 lines] > the requirements. So of course I can't suggest anything without a more > clearly definition of the requirements. Note that I said "There is probably many ways for the application and add-in to find each other. I would not mind making suggestions ...." and your reply was ambiguous. I am sorry I tried to help; I was not sure if you wanted help. > It's OK Sam, I haven't asked a question - I was responding to the OP's > question "how one could actually gain automation control of an Office [quoted text clipped - 6 lines] > new Excel instance. If they use our addin from an Excel launched > "externally", we warn them of the "consequences". |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.