I am using the Scriptom extension to Groovy 1.7.0 to automate some processing using Excel 2007 under Windows XP.
This always seems to leave an Excel process running despite my calling quit on the excel activeX object. (There is a passing reference to this phenomenon in the Scriptom example documentation too.)
Code looks like:
import org.codehaus.groovy.scriptom.ActiveXObject;
def xls = new ActiveXObject("Excel.Application")
xls.Visible = true
// do xls stuff
xls.Quit()
The visible excel window does disappear but an EXCEL process is left in the task manager (and more processes pile up with each run of the script).
There are no error message or exceptions.
Can anyone explain why the Excel process is left behind and is there any way to prevent it from happening?
This works:
xls.Quit()
Scriptom.releaseApartment()
The javadocs state:
In some cases, the JVM can close
before everything is cleaned up, which
can leave automation servers
(especially Excel) hanging. Call this
before your script exits to get
correct behavior from automation
servers.
Looks like you are missing
xls.release();
like it is done here.
Related
I'm trying to start a (very) proprietary application at work with VBA. I've used plain old Shell("C:\app\app.exe") and with WScript.Shell and Shell.Application I've tried ShellEX.Run and ShellEX.ShellExecute. All methods work, but when I log in to the application, it freezes. Are these methods doing something in the background that could cause the application to freeze? Are there any other methods I could try?
I am able to call the application easily with a batch file or with a PowerShell script. There is something about VBA that this application doesn't seem to like.
Thanks,
J
matlab (2015b) in my new notebook ThinkPad function xlsread/ xlswrite not work
for every exist excel file， xlsread not load the data
xlswrite also not work in every path
error use xlsread (line251)
catch exception
if isempty(exception.identifier)
exception = MException('MATLAB:xlsreadold:FormatError','%s', exception.message);
end
throw(exception);
the method import data also not work for excel file。
I found this answer in
https://cn.mathworks.com/matlabcentral/answers/282688-why-my-excel-file-can-not-be-read-by-matlab hope it can help you:
Who has problem to read excel file, can follow this order.
1- open the excel> file, >option, >add in, manage then select COM ADD IN, and clear everything (unchecked). everything should be cleared (unchecked).
2- restart the PC, and open the matlab.
3- perform xlsread command.
NOTE: for those people who use foxit pdf reader, it is potential to face this problem, so follow mentioned order.
NOTE: sometimes by using the matlab, configuration of excel is changed in unknown way, therefore there is no way to open the usual excel file in windows by double click.
So, open excel from desktop icon, file> option,> advanced,> general and then make clear (unchecked) "the ignore applications that use dynamic data exchange (DDE)". (same information for NOTE 2: https://support.microsoft.com/en-us/kb/3001579) these are some error for excel worker with matlab and related command.
Having an issue involving the creation of ActiveX handles using MATLAB 2015b. Before updating (from 2013a) I used to create a new Excel application handle using the following 'try catch':
global Excel
try
Excel = actxGetRunningServer('Excel.Application') ;
catch
Excel = actxserver('Excel.Application');
end
Since updating to 2015b, the code still runs through without error, but now the Excel handle created, whilst still of type Excel_Application, has no properties. Calling Excel.get returns a struct with no fields.
Apart from the update, there haven't been any other changes made to the code, and the version of MS Office hasn't changed.
Have there been any changes in the way MATLAB handles the ActiveX interface, or is there something wrong with my code?
Excel_Obj = CREATE OleObject
Excel_Obj.ConnectToNewObject( 'excel.application' )
Excel_Obj.Workbooks.Add
Excel_Obj.Application.ActiveWorkbook.WorkSheets.Add
Excel_Sheet = Excel_Obj.Application.ActiveWorkbook.WorkSheets[1]
//EXAMPLE
Excel_Sheet.Cells[1,1] = 45
Excel_Obj.Application.ActiveWorkbook.SaveAs(ls_file,56) //csv
//where ls_file = the Opened File
error happened after / during saveas.
try catch throw "error calling external object..in click..line.. saveas.."
--
i want to state to the user that the excel file is open therefore cannot be overwritten properly. I used a try catch and throwed a proper message but before the messagebox for the catch event happens, the PB execution error R0035 happens. any solutions or proper way to know if the excel file is open.
You might be able to check if the file is open first, have a look at this answer:
how to check if file is opened in excel using OLE (leaves excel process open)
I'd try a PowerScript FileOpen () call with a LockReadWrite! parameter to see if it can be opened, followed immediately by a FileClose () if it was successful. (I think this is a PowerScript-specific variation on the DXL solution Colin linked to.)
Good luck,
Terry
Have you tried approaches similar to these?
Using Win32 API:
http://www.rgagnon.com/pbdetails/pb-0030.html
Using PB function fileopen()with the (default) exclusive rights set:
http://www.tek-tips.com/viewthread.cfm?qid=1610670
In other words, see if the file can be opened exclusively before connecting to Excel or making the CSV?
You will have to turn off the option to break into the debugger for that exception to see the exception handling work in the IDE. Look for the Help topic "Exception Settings dialog box" for details. Once you see it's working I recommend you set it back to break into the debugger, since you'd normally want to see what threw the error.
You cannot use ole when document is open( even you set lock write) by the user and not by apllication.
my approach, I have been using many times till now:
Check excel is open or not, use use can use api or wsh script in the internet to check app opened. If opened do not run save as and tell user to close excel and not run it for while for while.
if you user run excel and your program still running active workbook and worksheet application will be switch to excel that opened by user ( imagine it wrong written data).
Change your code as below
if Excel_Obj.ConnectToNewObject( 'excel.application' ) <> 0 then
messagebox("warning", "could connect to excel", stopsign!)
RETURN
end if
just for knowledge another technique is DDE call, but not common today and most complicated.
Happy coding From pb developer.
I'm developing a COM server to be used from Excel VBA. When I update the server (edit code, unregister, re-register) Excel seems to carry on using the original version of the COM server, not the updated version. The only way I have found to get it to use the updated version is to close and re-open Excel, which gets a bit irritating. Is there a way to force Excel to use the newly registered version (maybe some kind of "clear cache" option)?
More details:
The server is being developed in Python using win32com.
In VBA I'm doing something like:
set obj=CreateObject("Foo.Bar")
obj.baz()
Where Foo.Bar is the COM server I have registered in the registry.
If I unregister the server then run the VBA code, I get a "can't create object" error from VBA, so it must realise that something is going on. But once I reregister it picks up the old version.
Any hints appreciated!
Thanks,
Andy
I've found a solution to my problem - the general idea is to set things up so that the main COM server class dynamically loads the rest of the COM server code when it is called. So in Python I've created a COM server class that looks something like:
import main_code
class COMInterface:
_public_methods_ = [ 'method1' ]
_reg_progid_ = "My.Test"
_reg_clsid_ = "{D6AA2A12-A5CE-4B6C-8603-7952B711728B}"
def methods(self, input1,input2,input3):
# force python to reload the code that does the actual work
reload(main_code)
return main_code.Runner().go(input1,input2,input3)
The main_code module contains the code that does the actual work and is reloaded each time the COM method is called. This works as long as the inputs don't change. There will presumably be a runtime penalty for this, so might want to remove the reload for the final version, but it works for development purposes.
Just a suggestion, have you tried to Unload the object? Maybe create a button in your excel spredsheat that force to unload the object.
I hope it helps