Jump to content
Sign in to follow this  
Oldschool

COM object to a process on a network system

Recommended Posts

Oldschool

Can I create a COM object to communicate to an application on a local network?

$oExcel = ObjGet("","Excel.Application")

Would something like this work?

$oExcel = ObjGet("/192.168.0.122/ProgramFiles/Microsoft Office/Excel.exe/","Excel.Application")

Share this post


Link to post
Share on other sites
ptrex
Oldschool

@Oldschool

This will not be possible. What is possible is to open a XLS file on the network.

regards,

ptrex

Are you sure Ptrex?

I read your two posts:

http://www.autoitscript.com/forum/index.php?showtopic=38671

http://www.autoitscript.com/forum/index.php?showtopic=54110

So I know you are the COM authority on this forum, great work BTW, probably take me a few months just to wrap my mind around it.

But I also know that similar thing to what I'm describing has been done from VBScript

http://www.emailarchitect.net/emailserver/...ects_remote.htm

I don't see a theoretical problem doing this from AutoIt, especially after reading your 2 posts.

But them again I'm just a newb.

Let me know what you think of this:

Server Remote Access by EmailArchitectObjects Component

--------------------------------------------------------------------------------

EmailArchitectObjects supports the following ways of remote access.

Remote Access by Named Pipe

Copy EmailArchitectObjects.dll to the remote machine, and run "regsvr32 path\emailarchitectobjects.dll" to register it as a com object.

For Windows XP or later user, open "Administrative Tools"->"Local Securiy Policy" on the server. Choose "Local Policies"->"Security Options"->"Networking access: Named Pipes that can be accessed anonymously", Add "{933495A9-9CBF-4517-80E5-9C08763A3984}" into the list and click "OK".

Add a NT user on the server who has the same name and password as the client NT user. e.g. You logon the client with NT user "tester", then you should add "tester" user on the server as well, and make sure they have the same password. If you logon client machine with NT built-in account "administrator", then this account must have the same password as the "administrator" account on server.

Finally, you can use EmailArchitectObjects to access server like this:

[VBScript]
Set oSvr = CreateObject("EmailArchitectObjects.ServerRoot")
r = oSvr.Connect( "myserveraddress", "system", "pass", 0 )
If r <> 0 Then
  WScript.Echo( "connect server failed!" )
End If

Remote Access by TCP/IP

Copy EmailArchitectObjects.dll to the remote machine, and run "regsvr32 path\emailarchitectobjects.dll" to register it as a com object.

Logon EAS Web Access with "system" account, click "Services->Remote Object Call", and make sure this service started. The default setting of Remote Object Call service only permits the access of emailarchitectobjects from IP address "127.0.0.1"(ipv4) and "::1"(ipv6). You should add IP address of your client machine to the allowed list, or change the Connection Control to "All except the IP addresses' list below" and remove all IP addresses from the denied list. In the IP addresses list, you can use wildcard(*) to represent a group of IP addresses, e.g. 192.168.0.* or 10.1.*

Finally, you should use [host name or IP address] [listen port] as the host name in Connect, Su, and OpenSession methods.

[VBScript]
Set oSvr = CreateObject("EmailArchitectObjects.ServerRoot")
r = oSvr.Connect( "mail.adminsystem.com 7328", "system", "pass", 0 )
If r <> 0 Then
  WScript.Echo( "connect server failed!" )
End If

[VBScript]
Set oSvr = CreateObject("EmailArchitectObjects.ServerRoot")
r = oSvr.OpenSession( sessionkey, "192.168.0.1 7328" )
If r <> 0 Then
  WScript.Echo( "connect server failed!" )
End If

If you use TCP/IP to access server, you need to use NOOP method of ServerRoot to keep the TCP/IP connection alive if you don't invoke any method of emailarchitectobjects in the "Connection timeout" interval. And once the total Connection time reaches "Session timeout" in Remote Object Call service, the server will terminate the connection forcedly.

You can change the value of "Connection timeout" and "Session timeout" in Remote Object Call service setting.

I understand that ObjGet() is not the mechanism that could accomplish the task, but maybe there is a way... Edited by Oldschool

Share this post


Link to post
Share on other sites
ptrex

@Oldschool

Sorry but you are mixing up things.

If you want to read what are the differences between ObjGet and ObjCreate

here is a good way to start : ObjGet versus ObjcreateThere is no way you can run an object remotely.

There only one exception when using ASP you can define to run it on the serer side, like

$Server = Server.ObjCreate("Excel.Application")

I looked at the example you mentioned. But this email object is just a local object which accepts remote TCP communication.

regards

ptrex.

Edited by ptrex

Share this post


Link to post
Share on other sites
Oldschool

This a bit more complicated than what I'm trying to do, but...

in Visual C++ they are doing it through DCOM

http://www.codeproject.com/com/HelloTutorial2.asp

Posted Image

Welcome to Step 7 of our DCOM tutorial. This is the last step!

If you want to follow along with this tutorial and add code and use the Visual C++ Wizards as we go along, that's great. In fact, I very very highly recommend that, because otherwise this tutorial is a big waste of electronic ink (?). However, I follow along exactly with the tutorial myself, as I write it, and develop the code and use the Visual C++ wizards just as I say you should. The screenshots, in fact, are from my development of the files for each step! To download this already-developed code to compare with your own, simply click the 'Download the Step n Files - n KB" links at the top of each step. There's also an archive of the files for all the steps at the Questions and Answers page for this tutorial. I still recommend that you follow along with us as we go; this way, you can learn while you code. If you ever have problems along the way with this tutorial, feel free to:

Send e-mail to me at brian@harttechservices.com.

Post a message to the message board at the bottom of this page.

Check out this tutorial's Questions and Answers page.

Remember, our steps in developing the software in this tutorial are as follows:

Step 1: Create the server, HelloServ, using the ATL COM AppWizard.

Step 2: Modify the starter files provided by AppWizard.

Step 3: Use the New ATL Object Wizard to add a simple COM object, the HelloWorld object, to the server.

Step 4: Modify the IHelloWorld interface to include a SayHello() method.

Step 5: Add an event method, OnSayHello(), to the connection point source interface, DHelloWorldEvents.

Step 6: Build the server, and install it on the server computer.

Step 7: Create a MFC client, HelloCli, which calls the server and handles the connection point event sink.

Share this post


Link to post
Share on other sites
Oldschool

Check out my DCOM snapin, AutoItX is a DCOM enabled app by default!

Run->dcomcnfg.exe

Posted Image

This opens up a whole new world for me...

Edited by Oldschool

Share this post


Link to post
Share on other sites
Oldschool

@Oldschool

Sorry but you are mixing up things.

If you want to read what are the differences between ObjGet and ObjCreate

ptrex.

You are probably right, but I need to call an API of a running application on a local network computer.

So I'm trying to figure out how to do it through COM objects.

I will know the exact reference of the DCOM object that belongs to this app, if I can figure out how to add it properly to DCOM apps.

Am I totally off my rocker?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.