Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Run exe-file on another computer 2
- Thread starter Bjornis
- Start date
In VB, use the Shell(pathname[,windowstyle])
The Shell function syntax has thesenamed arguments:
pathname(Required); Variant (String). Name of the program to execute and any requiredarguments orcommand-line switches; may include directory or folder and drive.
windowstyle(Optional). Variant (Integer) corresponding to the style of the window in which the program is to be run. If windowstyle is omitted, the program is started minimized with focus
The Shell function syntax has thesenamed arguments:
pathname(Required); Variant (String). Name of the program to execute and any requiredarguments orcommand-line switches; may include directory or folder and drive.
windowstyle(Optional). Variant (Integer) corresponding to the style of the window in which the program is to be run. If windowstyle is omitted, the program is started minimized with focus
-
1
- #3
I partially agree with Antzz. His suggestion of using the Shell command WILL start up the executable, but it will not run on the client machine. It will run on what ever machine called the Shell command.
The method described by Antzz will start up the executable, but it will start it on the same machine that ran the Shell command even if the executable is located on a remote server. What will happen, assuming that the running process has access to the remote machine, is the shell command will execute and the first computer will load the remote executable across the network into its own memory and then run the code there. If you actually want the executable to run on the remote machine, you need to do things a little bit differently. I have include a few options.
Method 1
The executable that you want to run on the remote machine can be converted to an ActiveX executable and then registered on the remote machine. When you were ready to run the remote executable, you would call -
Set obj = CreateObject( ProgID, [Remote Machine Name])
This would start up the EXE on the other machine, but remember that with this method, you are dealing with a COM object and when the objects reference count went to 0, the object (and the process) will be destroyed.
Method 2
Another method you be to create a DCOM "Stub" that would start any regular process on the other machine. This would still entail the creation of an ActiveX Executable, but that executable's only job would be to call the Shell command on the other machine.
Here is the sequence of events with this method.
1) The desired EXE is copied over to the client.
2) The DCOM "stub", which has already been register
on the client machine, is instantiated by the
server with a call to CreateObject.
3) the DCOM "stub" class supports a function called
Shell that would accept all of the normal parameters
that the normal shell command would accept. Then
server would call that method on the object, and
inside the object, the original Shell command that
Antzz suggested would be called and the EXE that
was just copied over would execute on the client
machine.
If you need anymore help with this, or if you would like to see an example, please let me know and I will be more than happy to provide you with som e examples.
The method described by Antzz will start up the executable, but it will start it on the same machine that ran the Shell command even if the executable is located on a remote server. What will happen, assuming that the running process has access to the remote machine, is the shell command will execute and the first computer will load the remote executable across the network into its own memory and then run the code there. If you actually want the executable to run on the remote machine, you need to do things a little bit differently. I have include a few options.
Method 1
The executable that you want to run on the remote machine can be converted to an ActiveX executable and then registered on the remote machine. When you were ready to run the remote executable, you would call -
Set obj = CreateObject( ProgID, [Remote Machine Name])
This would start up the EXE on the other machine, but remember that with this method, you are dealing with a COM object and when the objects reference count went to 0, the object (and the process) will be destroyed.
Method 2
Another method you be to create a DCOM "Stub" that would start any regular process on the other machine. This would still entail the creation of an ActiveX Executable, but that executable's only job would be to call the Shell command on the other machine.
Here is the sequence of events with this method.
1) The desired EXE is copied over to the client.
2) The DCOM "stub", which has already been register
on the client machine, is instantiated by the
server with a call to CreateObject.
3) the DCOM "stub" class supports a function called
Shell that would accept all of the normal parameters
that the normal shell command would accept. Then
server would call that method on the object, and
inside the object, the original Shell command that
Antzz suggested would be called and the EXE that
was just copied over would execute on the client
machine.
If you need anymore help with this, or if you would like to see an example, please let me know and I will be more than happy to provide you with som e examples.
jmarler,
i have a question i think you just might be able to answer. here goes. i have create an EXE that will take read a text file, parse it, then out the results to another text file. well, it works fine. the problem arrises when i try to read the file the EXE has created using the FileSystemObject from within the same sub. Here's the sub code...
Set fs = CreateObject("Scripting.FileSystemObject"
fs.CreateTextFile "parsein.tmp"
Set F = fs.GetFile("parsein.tmp"
Set ts = F.OpenAsTextStream(2, -2)
ts.Write sHtml 'write text to IN temp file file
Shell "parsecmdnew.exe """ & sParseString & """", vbNormal 'create parseout.tmp file here
If fs.FileExists("parseout.tmp" Then
Set F2 = fs.GetFile("parseout.tmp"
Set ts2 = F2.OpenAsTextStream(1, 0)
strSearchThis = ts2.Read(F2.Size)
ts2.Close
Set F2 = Nothing
Set ts2 = Nothing
End If
When i run this sub from my a dll, the file is created, however the FileSytemObject can't find it. When i run the program again, it does find it. It just can't the first time for some reason. Why is this?
i have a question i think you just might be able to answer. here goes. i have create an EXE that will take read a text file, parse it, then out the results to another text file. well, it works fine. the problem arrises when i try to read the file the EXE has created using the FileSystemObject from within the same sub. Here's the sub code...
Set fs = CreateObject("Scripting.FileSystemObject"
fs.CreateTextFile "parsein.tmp"
Set F = fs.GetFile("parsein.tmp"
Set ts = F.OpenAsTextStream(2, -2)
ts.Write sHtml 'write text to IN temp file file
Shell "parsecmdnew.exe """ & sParseString & """", vbNormal 'create parseout.tmp file here
If fs.FileExists("parseout.tmp"
ThenSet F2 = fs.GetFile("parseout.tmp"
Set ts2 = F2.OpenAsTextStream(1, 0)
strSearchThis = ts2.Read(F2.Size)
ts2.Close
Set F2 = Nothing
Set ts2 = Nothing
End If
When i run this sub from my a dll, the file is created, however the FileSytemObject can't find it. When i run the program again, it does find it. It just can't the first time for some reason. Why is this?
Hi jmarler...I think I have a similar problem with Bjornis BUT I need the .exe file to run on the server. This is my problem: I put an .exe (VB6) file on the server, I scheduled it to run every hour from 7 pm to 7 am. The .exe's task is to check a folder on the server if it contains the newest zip file, say aaa.zip. If the aaa.zip is the newest (checked by filedate and time), the .exe would extract it, then import the contents (aaa.txt) to the SQL server. It runs fine. BUT...since the task is scheduled only from 7 pm to 7 am, sometimes I need to run the .exe from a client computer (authorized users') in case the newest .zip file is generated after 7 am. How do I do that? Because I don't want the .exe to be run on the client. I'm posting a new question because I'm not really sure if it's a similar problem with Bjornis'. Thank you
-
1
- #7
You need to have a program (Windows Service) running all the time on the server, waiting for people to request that your program be run. This means it needs to be listening on some sort of communications mechanism -- like a TCP/IP socket, Message Queue, or be looking for a file to appear in a certain directory.
Chip H.
____________________________________________________________________
Click here to learn Ways to help with Tsunami Relief
If you want to get the best response to a question, please read FAQ222-2244 first
Chip H.
____________________________________________________________________
Click here to learn Ways to help with Tsunami Relief
If you want to get the best response to a question, please read FAQ222-2244 first
I have created a similar program. I have created a trigger, when some thing new happens in the server it makes my program to execute. And in another program I am using Scheduled task at particular time it gets executed.
This might give you some idea to you.
Thanks.
This might give you some idea to you.
Thanks.
Yes, someone mentioned about a Windows Service using VB, but I have no clue how to build one...Can you lead me to a sample somewhere, or if you have your own sample?
Right now, everything works fine (with the Scheduled Task on the server), but I think the ability of a user to run that .exe manually without having to go to the server room would be a nice enhancement. Thanks guys.
Right now, everything works fine (with the Scheduled Task on the server), but I think the ability of a user to run that .exe manually without having to go to the server room would be a nice enhancement. Thanks guys.
Commercial product that is supported: DesaWare NT Service Toolkit for VB6
Free (but not supported at all, and crashes if you debug it wrong) is the NTSvc.ocx. Microsoft no longer has it on their website, but you can google for it.
Writing a service has been discussed here several times, just do a search.
The key things to remember:
1. Don't put breakpoints in the service code. It's not running under your process.
2. No interaction AT ALL with the user (not even a msgbox!)
Chip H.
____________________________________________________________________
Click here to learn Ways to help with Tsunami Relief
If you want to get the best response to a question, please read FAQ222-2244 first
Free (but not supported at all, and crashes if you debug it wrong) is the NTSvc.ocx. Microsoft no longer has it on their website, but you can google for it.
Writing a service has been discussed here several times, just do a search.
The key things to remember:
1. Don't put breakpoints in the service code. It's not running under your process.
2. No interaction AT ALL with the user (not even a msgbox!)
Chip H.
____________________________________________________________________
Click here to learn Ways to help with Tsunami Relief
If you want to get the best response to a question, please read FAQ222-2244 first
- Status
Similar threads
- Locked
- Question