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?
Related
I have a question relating to the differences between the 32 bit and 64 bit versions of Excel and VBA.
I am working in Office 365, 64 bit. (I am using 64 bit because I ran into memory issues and as a test, to see if 64 bit works for our company). I am working on an Excel file which has a lot of VBA code used to gather product properties from SQL, calculate parameters from these properties, and output everything to another SQL database. In addition, the Excel file outputs PDF files.
The Excel file is stored as a template, so that users can open the template and save the new file to their respective workspace. At the moment, the users are using Office 365, 32 bit.
When I open the Excel template, Excel closes itself. It seems to crash before calculating the parameters on the new file. There is no error message; in the lower-right message box I can see that Excel doesn't get to the calculating stage.
However, when the other users open the file in 32-bit Excel, everything is fine.
I am not using pointers (no PtrSafe) and no LongLong variables.
I also have no compile errors.
I am currently rebuilding the Excel file by saving it as a file without macro's, and then copying the VBA modules - a different site mentioned the VBA code may be corrupt. I am halfway through adding macro's, and the error pops up again; the VBA code I have added last has been in use for about a year so I am tempted to exclude it as a culprit.
Where would you suggest I look to find the problem?
You're absolutely right of course. I have gone back to the last working version and began adding a text logfile, which would log the start and end of each procedure. I got lucky as the file crashed as I was doing this, and the logfile pointed me towards a procedure seemed to be working, until the right conditions were met for it to crash.
The procedure itself accesses global variables which were not initialised. I didn't catch errors that could occur properly. For some reason, this works fine in x86 Excel, doesn't trigger any problems in the compiler or during debugging but crashes in x64 Excel when enough memory is used.
Gekozen_Assen is the name of a global variable. It is a dictionary which contains information. I had tried to use .Exists as a method to test if the required item in the dictionary exists, but this doesn't work if the dictionary isn't initialized at all.
The errorous code:
GetFromGlobal = ""
If Global_Dictionary.Exists(Answer_Type) Then
GetFromGlobal = Global_Dictionary.Item(Answer_Type)
Else
GetFromGlobal = "Error!"
End If
Instead I should've been using "Is Nothing", the fixed code below:
If Global_Dictionary Is Nothing Then
GetFromGlobal = "Error: Dictionary not initialized"
Else
If Global_Dictionary.Exists(Answer_Type) Then
GetFromGlobal = Global_Dictionary.Item(Answer_Type)
Else
GetFromGlobal = "Error: Dictionary item not found"
End If
End If
I have a Windows Forms application with an OpenFileDialog. The user clicks a "Process" button and the application goes through the file - an Excel spreadsheet - and processes the data in it. All of this works as expected with one caveat.
After the application is done processing, the file remains locked for editing so when I open the file to make changes, I get this message:
If I close the application completely, the file is unlocked so I'm assuming the application is just holding onto the file for longer than it should. I'm guessing there should be some sort of Close() method or something that will release the resources but I can't figure out exactly what I need. I tried using Dispose() and wrapping my code in a Using block which I thought destroyed everything automatically but no luck.
Here's my code:
Using excel = New ExcelPackage(OpenFileDialog1.OpenFile)
Dim ws = excel.Workbook.Worksheets.First()
'Process data in ws...
OpenFileDialog1.Dispose() 'Doesn't seem to release the file
excel.Dispose() 'Doesn't seem to release the file
End Using
The OpenFileDialog.OpenFile Method returns a Stream object that likely is not being closed by the ExcelPackage.
To ensure that the stream is released, use the following pattern.
Using strm As IO.Stream = OpenFileDialog1.OpenFile
Using excel = New ExcelPackage(strm)
' ...
End Using
End Using
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.
I havea a method in Delphi that saves some data into a ExcelFile. The Program works fine for any kind of Excel except Excel 2013.
Here is the code
try
// If no instance of Word is running, try to Create a new Excel Object
ExcelApp := CreateOleObject('Excel.Application');
except
ShowMessage('Cannot start Excel/Excel not installed ?');
Exit;
end;
ExcelApp.DisplayAlerts := False;
ExcelApp.Workbooks.Add(xlWBatWorkSheet);
// fill the Excel file
ExcelApp.Visible := True;
// Save the Workbook
ExcelApp.save;
if not VarIsEmpty(ExcelApp) then begin
ExcelApp.DisplayAlerts := False; // Discard unsaved files....
ExcelApp.Quit;
end;
So As I said, this worked fine for Excel untill the 2013 Version. When I try to use this on a computer with Excel 2013 I get the error
Save Method of Application class failed.
Any Ideas why is this happening and any possible Workaround?
PS I tried with
ExcelApp.Workbooks[1].SaveAs('c:\test.xlsx', xlWBATWorksheet);
I also get an error :
SaveAS Method of Workbook class failed.
I also read that I could be that I don't have acces to save on that location, but i'm the administrator on the computer.
If I help the time of executing this operation takes a lot more time that It usually did in Excel 2010 or Excel 2007.
According to the documentation, the Excel Application object has no Save method. Use SaveAs from the Workbook object.
You are trying to save a file to the root directory of the system volume, and by default, that is secured so that standard user cannot create files in that location. Even though you are an administrator, UAC means that your process runs with a standard user token.
The other problem I see is that xlWBATWorksheet is not a file format constant. You mean to use xlOpenXMLWorkbook. This should be fine:
Workbook.SaveAs('c:\somedir\test.xlsx', xlOpenXMLWorkbook);
where you replace c:\somedir with some suitable path on your machine.
Switching to early bound COM might alleviate some of your travails but the answers can always be found in the documentation. You don't need to do this blind.
I haven't done any Microsoft Office automation myself but I do remember from the time that I still used Delphi 7 that when you installed it the installer actually asked you for which version of office do you wanna install the extensions for.
So I would gues that there are some differences in COM implementation that different versions of Microsoft Office use so it is posible that components your Delphi use for Microsoft Office Automation are not compatible with Office 2013.
May not be relevant but had same error message in VB6 (yes, 2016 and I still use it for odd things on Windows 10!) because the sheet was selected. Selected another object before saving and it worked.
You need to install KB2830391 HF460904 for Excel 2013 issue for AX 2009. Change in one sysExcel class on how the transfer/save are made!
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