11-14-2005 12:21 PM
There are memory leaks when calling the Excel_xxx functions. I have verified this using the NI sample code “excel2000demo” as well as my application. At the most fundamental level, simply calling Excel_NewApp() and then calling Excel_AppQuit() does not free all of the handles. And yes, I am calling CA_DiscardObjHandle () on the handle returned by Excel_NewApp(). I have verified this using the task manager and monitoring the "Memory Usage" and "Handles" columns. For the simple case noted above, the handle count increments by two. Also, when I throw in all of the other Excel calls in order to do something useful, there are even more leaks. Does anyone know of a patch for these leaks? Also, I have tried leaving the Excel application “open” and there are still leaks involved with some of the other calls.
11-21-2005 12:15 AM
I've the same problem of you with an application of mine: I wrote an application for testing that saves a large amount of data in an excel sheet. When the application ends, I save the open sheet, I close it and I end Excel by using the functions contained in excelreport.c
I run this application on two test apparatus that have two different PC: the first PC works fine, whereas the second PC always leaves an excel process opened every time I open an excel sheet and save it. Now I changed two old PC with two new PC (they are equal to each other now) and the problem seems to be solved. New PC are two top machine (at hardware level), therefore I suppose it's only a question of hardware resources (memory, processor, etc.).
The only tip I can give you is to use the excelreport.c: it's much more simple to understand, and to try to expand the hardware resources.
Sincerely
Andrea
11-21-2005 03:08 PM
I am having a similar problem. By watching the "Windows Task Manager" I have observed that the Excel2000 demo DOES close everything upon exiting. Unfortunately my program which I based largely on the Excel2000 demo leaves an EXCEL task running. I have scrubbed my code, and as best as I can tell I am releasing all of the handles I create but I cannot figure out what I am leaving dangling. In the demo programming calling Excel_AppQuit clears the Task Manager ID, but when my program makes the same call it closes the app (returns no errors) but the Task Manager PID remains until I kill it manually.
I definately concur that ExcelReport.fp is much simpler and easier to understand and use than Excel2000.fp but there are still features that I need from Excel2000.fp
It should not have to be this hard.
-don
11-22-2005 08:13 AM
10-25-2010 02:22 PM
10-27-2010 07:45 PM
I've used Excel and Word automation from CVI for years, it's always been somewhat problematic.
NI's excuse is that they're at the whim of Microsoft on this, that Microsoft can and does change the automation interface, so they tend to not do a particulalry good job with the Excle and Word support code. I've found errors before (the hard way) in the NI code used to run Word.
We've seen memory leaks when using Word automation that for the life of us we couldn't find or correct - there's a long thread on this forum on this topic from years ago.
I am using ExcelReport now, with Excel 2007, and it seems to be error free, though if I terminate a debug session without shutting down Excel, I of course see hung up EXCEL.EXE tasks left running.
Having Excel stay running after the CVI app stopped was an old problem with CVI ten years ago, it drove us nuts, then they had it fixed.
I do find that if you run Excel on your desktop while a CVI app is already running it, and then you close Excel "manually", the CVI app loses its linkage to Excel as well and hangs.
Good Luck
10-28-2010 09:19 AM
I've also dealt with a number of customer reported memory leak issues with these APIs, and very often (certainly not always) the cause has been a failure to close out handles returned from the API. Because handles are returned by a majority of the API, it can become tedious to make sure you're always closing them out. This is where the resource leak detection feature of LabWindows/CVI 9.0 can come in very handy.
Simply turn on resource tracking (set the debugging level in the build options to extended), run your program to completion from the debugger and then close it, and then wait to see if the Resource Tracking window displays. If it does display, double click on each item in the list to see where it was allocated. Then deallocate as necessary. This tool can take a lot of the hassel out of making sure you are not leaking any handles/memory - ActiveX or otherwise.
NickB
National Instruments
10-28-2010 01:41 PM
The problem we were seeing with Word wasn't a memory leak in the application per se, but rather some odd, second order depletion of a Word or Office resource that we never have figured out. I thought it might be the Office Clipboard (added in Office 2003 I think). It happened while we were pasting bitmaps into the word doc.
In my current app, I've watched it pretty carefully and I can't say that I've ever seen Excel stay running when I've allowed the app to shut it down and close handles.
It can be hard to get an app not to leak - Win32 is notorious for having calls that will leak without you realizing it, though many of these are well known.
Menchar
10-29-2010 02:12 AM
Before you start hunting this leaks, be sure you have install all the ServicePacks and patch for Office.This can fix lot of this bugs.(specialy in old good Word 2000, without SPs it`s realy bad)