asked on

VBS script run from a C++ program hangs onto thread, wont allow shut down and clean up

Hello,
I have a program written in Visual Studio 6.0 using C++. The program should run until it receives a message to switch, then it should shut itself down, wait a few seconds, and then start up its sister program. Currently if I open the first program and close it manually, then run the sister program manually (double-clicking on it) everything works fine. I am trying to make it simpler for the user though and use a script that will run to handle this action when a special message is received.

Currently the flow of the program is for the main program to shut itself almost all the way down before it opens a VBScript file that will loop, waiting for the main program to close.
The main program then finishes closing itself. When the main is closed the vbs file will then wait 30 seconds and then run the sister program. The problem is that when I use ShellExecute to run the vbs file it seems to create a new thread. When MAIN closes and the sister program attempts to open I run into numerous errors with memory and inabilty to acess things that should have been cleaned up and freed when MAIN shut down (They share many resources). But if I run the script on my own from outside of my main program then it works fine... it is only if I call it from main that I receive the problem.

Anyone have any ideas /sample code on how I can run this vbs script from my program but not have this thread attaching back to the parent program? Not much to it but I included the code on how I call ShellExecute.

HINSTANCE nResult = ShellExecute(NULL, NULL, _T("C:\\Projects\\EMMT\\Software\\Scripts\\Switch_Over.vbs"), _T("1"), NULL, SW_HIDE);
if( (int)nResult == ERROR_FILE_NOT_FOUND)
{
//not found
}

Open in new window

DanRollins

I can say that it seems to work as expected when I try it....

#include "stdafx.h"
#include <windows.h>
#include <shellapi.h>
 
int main(int argc, char* argv[])
{
	char szFile[]="c:\\temp\\test.vbs";
	HINSTANCE nResult = ShellExecute(NULL, "open", szFile, "1", NULL, SW_SHOWNORMAL );
	if( (int)nResult == ERROR_FILE_NOT_FOUND) {
		//not found
	}
	if( (int)nResult <= 32 )  {
		// SOME OTHER ERROR
	}
 
	return 0;  /// exit from this console app
}

Open in new window

DanRollins

Here's the VBS I used "test.vbs"

Option Explicit
 
Const cIMG = "<img src='file:\\C:\TEMP\sourcegray.bmp' border='1'>"
 
Dim oIEA : Set oIEA = CreateObject("InternetExplorer.Application")
With oIEA
  .ToolBar = 0
  .AddressBar =false
  .StatusBar = 0
  .Width = 700
  .Height = 550
  .Left = 0
  .Top = 0
  .MenuBar = false
  .Navigate "about:blank"
  While oIEA.Busy
  Wend
  .Document.Title = "Murphy Gets The Finger!!!"
  .Document.Body.InnerHTML = cIMG
  .Visible = 1
End With 
 
WScript.Sleep 10 * 1000
 
On Error Resume Next 
oIEA.Quit
set oIEA = Nothing

Open in new window

DanRollins

In the Task Manager, I can see that CONSOLE22.EXE starts, then WSCRIPT.EXE starts, then CONSOLE22.EXE ends, then WSCRIPT.EXE ends a few seconds later (WSCRIPT.EXE is the program that actually runs a VBS or JS script file) .
BTW, always use SW_SHOWNORMAL for testing!! -- never leave yourself in the dark :-)

yelowsnw2

ASKER

The bigger problem I was having was that the C++ program would call the script , the script would run and TASKKILL the C++ program that called it, then would start up it's sister C++ program. The only issue was that the C++ program that got killed would never clean up or free up the memory it was using until the script went away. As if Windows saw the child thread was still running, not allowing end of program cleanup. The sister program that then starts up (basically same exact program with a different name) and is not allowed to hook into that memory because it is still in use by the first program as the script hasn't finished yet.

We have since had our main C++ program gracefully close itself down (no more TASKKILL) but the problem still remained as it still called a script.

yelowsnw2

ASKER

Oops, forgot to add. We have since found a workaround and it works now, but not in the best of ways. We had to create a new unrelated exe that basically just sits there and watches for a sign that it is time to switch over from one to the other. Once the main C++ program exits on its own then it just calls the same script and it works fine now. The memory gets released by windows now.

But I would still like better clarification on the problem, and I do wonder if there is a way to better avoid it.

ASKER CERTIFIED SOLUTION

DanRollins

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

yelowsnw2

ASKER

Haven't had a chance to test this out yet but it's something I haven't tried yet!