Running another VB program from VB

Posted on 1998-12-15
Last Modified: 2010-05-03
I am building a system monitoring application. It looks at certain files to see if their date/time stamps are changing.  ( To see if they are locked up).  It also counts files in directories and checks the oldest time stamp and reports problems through alphanumeric paging. It also needs to run some maintenance on its data each day (Clearing some counters and logs).  Eventually it will be running some scripts to dial into individual modems to see if they are operational.

I want to run this maintenance against the database and the dial out scripts which will be written in VB code from within my application.  I want to pass paramaters to them and return results.  I think that I would rather not have them be functions or sub's within my application because I would like to have the ability to kick off other programs from my application at defined intervals, while passing paramaters.  I am pretty new to VB.  Should I create these as DLL's, ActiveX components or something else.

Please be specific and provide some example code.
Question by:louy
  • 3
  • 2
LVL 12

Expert Comment

Comment Utility
Just build your maintenance programs as separate .EXE files and run them as you would any other task. This allows you to build components that can run stand-alone (and can be *tested* in that mode) and then just spawn them off like any other windows app.



Author Comment

Comment Utility
How do I pass paramaters and return results and how exactly do I run them from within my VB application.  Please provide some code.
LVL 12

Accepted Solution

mark2150 earned 200 total points
Comment Utility
You can pass params on the command line or you can use an external file. The file is the simplest and allows you to run each part separately.

If your program has menus and such, then you can use the SENDKEYS command to tell it what to do.

SHELL( yourprog & " " & paramlist, 1)

If you need to wait for the child to complete, then use ExecCmd instead of SHELL.

' These data type declarations are required to support the obscure windows
' function to spawn a child task and wait for it to finish before continuing
    cb As Long
    lpReserved As String
    lpDesktop As String
    lpTitle As String
    dwX As Long
    dwY As Long
    dwXSize As Long
    dwYSize As Long
    dwXCountChars As Long
    dwYCountChars As Long
    dwFillAttribute As Long
    dwFlags As Long
    wShowWindow As Integer
    cbReserved2 As Integer
    lpReserved2 As Long
    hStdInput As Long
    hStdOutput As Long
    hStdError As Long
End Type
    hProcess As Long
    hThread As Long
    dwProcessID As Long
    dwThreadID As Long
End Type
Private Declare Function WaitForSingleObject Lib "kernel32" (ByVal hHandle As Long, _
    ByVal dwMilliseconds As Long) As Long
Private Declare Function CreateProcessA Lib "kernel32" ( _
    ByVal lpApplicationName As Long, _
    ByVal lpCommandLine As String, _
    ByVal lpProcessAttributes As Long, _
    ByVal lpThreadAttributes As Long, _
    ByVal bInheritHandles As Long, _
    ByVal dwCreationFlags As Long, _
    ByVal lpEnvironment As Long, _
    ByVal lpCurrentDirectory As Long, _
    lpStartupInfo As STARTUPINFO, _
    lpProcessInformation As PROCESS_INFORMATION) As Long
Private Declare Function CloseHandle Lib "kernel32" (ByVal hObject As Long) As Long
Const INFINITE = -1&
' I don't really understand the above declares, but they do work so DON'T MESS WITH THEM!

Public Sub ExecCmd(cmdline$)
' This executes an external windows program and waits for it to complete
' Initialize the STARTUPINFO structure:
start.cb = Len(start)
' Start the shelled application
ret& = CreateProcessA(0&, cmdline$, 0&, 0&, 1&, NORMAL_PRIORITY_CLASS, 0&, 0&, start, proc)
' Wait for the shelled application to finish:
    ret& = WaitForSingleObject(proc.hProcess, 5000)
    If ret& <> 0 Then GoTo holdhere
ret& = CloseHandle(proc.hProcess)
End Sub


Author Comment

Comment Utility
I want to use the ExecCmd, I tried it and it works well.  To pass the data back and forth should I just write to a text file from each .exe or should I use a table in my Access DB or is there a cleaner way?
LVL 12

Expert Comment

Comment Utility
Straight ASCII text file is simplest and cleanest. This also allows you to component test by creating fake files with EDIT. You can also review outputs the same way.



Featured Post

How to improve team productivity

Quip adds documents, spreadsheets, and tasklists to your Slack experience
- Elevate ideas to Quip docs
- Share Quip docs in Slack
- Get notified of changes to your docs
- Available on iOS/Android/Desktop/Web
- Online/Offline

Join & Write a Comment

Introduction In a recent article ( for the Excel community, I showed an improved version of the Excel Concatenate() function.  While writing that article I realized that no o…
When designing a form there are several BorderStyles to choose from, all of which can be classified as either 'Fixed' or 'Sizable' and I'd guess that 'Fixed Single' or one of the other fixed types is the most popular choice. I assume it's the most p…
Get people started with the process of using Access VBA to control Outlook using automation, Microsoft Access can control other applications. An example is the ability to programmatically talk to Microsoft Outlook. Using automation, an Access applic…
Get people started with the utilization of class modules. Class modules can be a powerful tool in Microsoft Access. They allow you to create self-contained objects that encapsulate functionality. They can easily hide the complexity of a process from…

763 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

7 Experts available now in Live!

Get 1:1 Help Now