I have a code which automates few things to create an excel file. The
problem is that once its done and saves the file and closes it the
excel process still is running in the background. It terminates it
self after the app completely closes it's self.

here is a pice of my code:

================================================== =====
xlApp.SetUserControl(false);
xlApp.SetVisible(false);
wb = xlApp.GetWorkbooks();
_wb = wb.Add(covOptional);
ws = _wb.GetSheets();

//Automate some stuff...

_wb.SetSaved(TRUE);
_wb.SaveCopyAs(COleVariant(filePath));
_wb.Close(COleVariant(covFalse),COleVariant(filePa th),COleVariant((long)0));
wb.Close();
xlApp.Quit();
xlApp.ReleaseDispatch();
xlApp = NULL;
wb = NULL;
ws = NULL;
_ws = NULL;
_wb = NULL;

so am I terminating these in the wrong order? I've tryed different
ways...
This class is called from button event.

Excel doesn't have a "SetSaved" property, but rather a "Saved" property on
the workbook. Therefore, the code may be erroring out prior to getting to
the lines dealing with closing out the workbooks and app, depending on how
you have the app setup to handle run-time errors.

--

Sincerely,

Ronald R. Dodge, Jr.
Master MOUS 2000

"Kevin" wrote in message
ups.com...
I have a code which automates few things to create an excel file. The
problem is that once its done and saves the file and closes it the
excel process still is running in the background. It terminates it
self after the app completely closes it's self.

here is a pice of my code:

================================================== =====
xlApp.SetUserControl(false);
xlApp.SetVisible(false);
wb = xlApp.GetWorkbooks();
_wb = wb.Add(covOptional);
ws = _wb.GetSheets();

//Automate some stuff...

_wb.SetSaved(TRUE);
_wb.SaveCopyAs(COleVariant(filePath));
_wb.Close(COleVariant(covFalse),COleVariant(filePa th),COleVariant((long)0));
wb.Close();
xlApp.Quit();
xlApp.ReleaseDispatch();
xlApp = NULL;
wb = NULL;
ws = NULL;
_ws = NULL;
_wb = NULL;

so am I terminating these in the wrong order? I've tryed different
ways...
This class is called from button event.

On Jul 31, 4:11 pm, "Ronald Dodge" wrote:
Excel doesn't have a "SetSaved" property, but rather a "Saved" property on
the workbook. Therefore, the code may be erroring out prior to getting to
the lines dealing with closing out the workbooks and app, depending on how
you have the app setup to handle run-time errors.

Thanks for your responce... Yes the function SetSaved is available...
also I changed it as you suggested to Save();
but no luck... process still running...
any other sugestion?
thanks in advance...
-Kevin

On Jul 31, 11:13 am, Kevin wrote:
I have a code which automates few things to create an excel file. The
problem is that once its done and saves the file and closes it the
excel process still is running in the background. It terminates it
self after the app completely closes it's self.

here is a pice of my code:

================================================== =====
xlApp.SetUserControl(false);
xlApp.SetVisible(false);
wb = xlApp.GetWorkbooks();
_wb = wb.Add(covOptional);
ws = _wb.GetSheets();

//Automate some stuff...

_wb.SetSaved(TRUE);
_wb.SaveCopyAs(COleVariant(filePath));
_wb.Close(COleVariant(covFalse),COleVariant(filePa th),COleVariant((long)0)) ;
wb.Close();
xlApp.Quit();
xlApp.ReleaseDispatch();
xlApp = NULL;
wb = NULL;
ws = NULL;
_ws = NULL;
_wb = NULL;

so am I terminating these in the wrong order? I've tryed different
ways...
This class is called from button event.
Try closing the active x object u created to open xl.

Add DoEvents() calls to give control to the OS.

Make XL visible to debug.

Confirm process is from current script.

Kevin,

I am far from an expert with C++ but from my experience in using VB6 with
Office Apps I would think the problem is in setting the app to null before
setting the worksheet and workbook objects to null. Try the follwing
arrangement:

As a side note, the _ws was not in your original declarations...

_wb.SetSaved(TRUE);
_wb.SaveCopyAs(COleVariant(filePath));
_wb.Close(COleVariant(covFalse),COleVariant(filePa th),COleVariant((long)0));
wb.Close();

\\ Remove Worksheet references
ws = NULL;
_ws = NULL;
\\ Remove Workbook references
wb = NULL;
_wb = NULL;
\\ Close and remove App references
xlApp.Quit();
xlApp.ReleaseDispatch();
xlApp = NULL;

"Kevin" wrote in message
oups.com...
On Jul 31, 4:11 pm, "Ronald Dodge" wrote:
Excel doesn't have a "SetSaved" property, but rather a "Saved" property
on
the workbook. Therefore, the code may be erroring out prior to getting
to
the lines dealing with closing out the workbooks and app, depending on
how
you have the app setup to handle run-time errors.

Thanks for your responce... Yes the function SetSaved is available...
also I changed it as you suggested to Save();
but no luck... process still running...
any other sugestion?
thanks in advance...
-Kevin

Usually is best to clean up your variables from the smallest (child) objects
to the largest (parent) objects, which Dove indirectly was pointing out.
The other thing, make sure any code in the BeforeSave or BeforeClose events
of the workbook are performing properly, if there is any code in either of
them and if the application's EnableEvent is set to "True" (-1).

Maybe for the programming languages outside of VBA, there's a different set
of methods, properties, and statements available for Excel. I wouldn't know
about that as I haven't programmed with C programming, but yet, I have had
to convert some C programming code to VBA code to get various applications
to be manipulated by VBA within Excel, such as Acrobat Adobe, Lotus Notes,
and IBM Personal Communicator. I am currently in the process of getting my
MCSD cert, which is taking me a while to go through the training material,
though 90% to 95% of the stuff that I have learned is self taught, so many
of the stuff is also review. However, since some of the stuff is geared
towards .NET stuff, that aspect of it is relatively new to me, but still
uses all the same general programming stuff in terms of how you would create
your code even though the syntax is different in many respects and the
object interactions in some cases are different too. But yet, the more
changes that I see, the more of the same I also see. There's one major
thing I don't like about the .NET stuff, though I fully understand their
reasoning for getting rid of it, I still think there's rare occassions of
when it may still be needed. They got rid of the GoTo statement. The
single biggest reason why they got rid of it is simply cause people have
used it in improper ways creating bad programming practices. Now you have
to use the Try...Catch method in it's place.

--

Sincerely,

Ronald R. Dodge, Jr.
Master MOUS 2000

"Kevin" wrote in message
oups.com...
On Jul 31, 4:11 pm, "Ronald Dodge" wrote:
Excel doesn't have a "SetSaved" property, but rather a "Saved" property
on
the workbook. Therefore, the code may be erroring out prior to getting
to
the lines dealing with closing out the workbooks and app, depending on
how
you have the app setup to handle run-time errors.

Thanks for your responce... Yes the function SetSaved is available...
also I changed it as you suggested to Save();
but no luck... process still running...
any other sugestion?
thanks in advance...
-Kevin

Thanks Again... I've tryed your sugestions but still nothing is
working the right way...
I have debuged it setting:
xlApp.SetUserControl(true);
xlApp.SetVisible(true);
I have seen everything shutdown normally except that the process still
is running...
I just think its kind of anoying that only when the whole application
shuts down only then it terminates the excel process.

About the DoEvent() function is there something like this for C++?

thanks!
-Kevin

I don't know if it's available for C++. Works for sure in VBScript,
Outlook and Excel VBA - tested there.

Note the "s" its DoEvents()

About the DoEvent() function is there something like this for C++?

thanks!
-Kevin

C++ help!? anyone? I really don't know what could be wrong! my app
does everything like it should... creates my excel file and saves it
properly... but doesn't kill the excel process....
There has to be a way to terminate this proces...
Thanks for everyones help!
-Kevin

Did you look at the Quit Method within the Excel help file for the different
things that it could be, such as some other workbook open and not saved?

--

Sincerely,

Ronald R. Dodge, Jr.
Master MOUS 2000

"Kevin" wrote in message
ups.com...
C++ help!? anyone? I really don't know what could be wrong! my app
does everything like it should... creates my excel file and saves it
properly... but doesn't kill the excel process....
There has to be a way to terminate this proces...
Thanks for everyones help!
-Kevin

Ok! I started from the begining narrowing it down...

1). I started opening the excel application and closing nothing
else... and excel process DID shut down properly....

2). Started adding all the different things I'm automating excel
with...

Now I found the problem. When I try to add extra sheets to the
workbook excel doesn't shutdown the process... Any other automation
works fine, but only on the add function part....
I tried releasing handler event and all but I really don't know what
it is holding on to make excels process stay running...

any ideas?

//**CODE**//
wb = xlApp.GetWorkbooks();
_wb = wb.Add(covOptional);
ws = _wb.GetSheets();

//Add extra worksheets
COleVariant VOptional((long)DISP_E_PARAMNOTFOUND, VT_ERROR);

//THIS CALL MAKES EXCEL STAY ON... if commented out excel shuts
process properly..
ws.Add(VOptional, VOptional, COleVariant((short)3),
COleVariant((short)XL_WORKSHEET));


ws = NULL;

_wb.SetSaved(TRUE);
_wb.SaveCopyAs(COleVariant("C:\\filePath.xls"));
_wb.Close(COleVariant(covFalse),COleVariant("C:\
\filePath.xls"),COleVariant((long)0));
_wb = NULL;

wb.Close();
wb = NULL;
xlApp.Quit();
xlApp = NULL;

//**END CODE**//

Try applying that particular line to a worksheet object variable so as you
can have it clear out of memory properly rather than possibly having it hang
out there in memory, such as below.

Set wshNew = ws.Add(VOptional, VOptional,
COleVariant((short)3),COleVariant((short)XL_WORKSH EET))

The other thing I learned about VBA programming a long time ago, if you are
using a function as a procedure call, meaning not setting (or letting) the
result of it to some variable, and it's more than just one argument provided
to the call, can not use the parantheses around the set of arguments as it
would need to be like the following:

ws.Add VOptional, VOptional,
COleVariant((short)3),COleVariant((short)XL_WORKSH EET)

I can't speak for C++, but it may have the same type deal. In VBA, if this
rule is broken, it instantly comes up as a syntax error. Just so you know,
all 4 arguments are optional with the default being 1 worksheet inserted
before the active worksheet.

--

Sincerely,

Ronald R. Dodge, Jr.
Master MOUS 2000

"Kevin" wrote in message
ups.com...
Ok! I started from the begining narrowing it down...

1). I started opening the excel application and closing nothing
else... and excel process DID shut down properly....

2). Started adding all the different things I'm automating excel
with...

Now I found the problem. When I try to add extra sheets to the
workbook excel doesn't shutdown the process... Any other automation
works fine, but only on the add function part....
I tried releasing handler event and all but I really don't know what
it is holding on to make excels process stay running...

any ideas?

//**CODE**//
wb = xlApp.GetWorkbooks();
_wb = wb.Add(covOptional);
ws = _wb.GetSheets();

//Add extra worksheets
COleVariant VOptional((long)DISP_E_PARAMNOTFOUND, VT_ERROR);

//THIS CALL MAKES EXCEL STAY ON... if commented out excel shuts
process properly..
ws.Add(VOptional, VOptional, COleVariant((short)3),
COleVariant((short)XL_WORKSHEET));


ws = NULL;

_wb.SetSaved(TRUE);
_wb.SaveCopyAs(COleVariant("C:\\filePath.xls"));
_wb.Close(COleVariant(covFalse),COleVariant("C:\
\filePath.xls"),COleVariant((long)0));
_wb = NULL;

wb.Close();
wb = NULL;
xlApp.Quit();
xlApp = NULL;

//**END CODE**//

Hey Ronal thanks for your suggestions, in one way or another it helped
me find the problem... here is the solution... very weird how It came
about.

//Setting the result to ws for some reason ws wont work again, but
ws = ws.Add( vOpt, vOpt, COleVariant((short)3),
COleVariant((short)XL_WORKSHEET) );

//Setting this right after to re gain the objects properties for ws no
it works!
ws = _wb.GetSheets();

thanks all PROBLEM SOLVED!
-Kevin

From what I have learned, in your example below, looks as though the "ws"
variable is a "Worksheet Collection" (may be declared as "ws As
Excel.Worksheets", and you are attempting to set it to a "Worksheet Object",
thus probably why it's not working. However, when you do the "GetSheets"
function, it resets the ws back to the proper collection.

I'm also assuming you are declaring your variables.

If you set a variable to a "Worksheet Object" such as the following VBA
declaration command:

Dim wsh As Excel.Worksheet 'Note, there is no "s" as the end to refer to the
object rather than the collection.

then what looks to be like your C++ command.

wsh = ws.Add( vOpt, vOpt, COleVariant((short)3),
COleVariant((short)XL_WORKSHEET) );

This way you don't get a "Mistype" error.

Glad to be of help to the extent possible. I have worked with Excel VBA
quite extensively and I'm also in the process of getting my MCSD cert
dealing with .NET programming. There's one main thing about the .NET
programming that I don't like about it, and it's the fact that it has gotten
away from using the Goto feature. I most certainly understand their
argument for it, but there are those rare occassions for it's use outside of
error catching. If anything, I generally use it more so for debugging and
error catching purposes than for anything else, but yet, there's those rare
exceptions to that rule.

--

Sincerely,

Ronald R. Dodge, Jr.
Master MOUS 2000

"Kevin" wrote in message
oups.com...
Hey Ronal thanks for your suggestions, in one way or another it helped
me find the problem... here is the solution... very weird how It came
about.

//Setting the result to ws for some reason ws wont work again, but
ws = ws.Add( vOpt, vOpt, COleVariant((short)3),
COleVariant((short)XL_WORKSHEET) );

//Setting this right after to re gain the objects properties for ws no
it works!
ws = _wb.GetSheets();

thanks all PROBLEM SOLVED!
-Kevin