Re: actxserver and related issues

John,
I wanted to take you up on your offer to Paul (if it's
transferrable). I am having trouble with COM and don't particularly
want to learn all about it.

My problem is for Excel and i have seen posts on this group about it
in the distant past (2004), but they didn't really help.

I can open and close excel, but if I invoke a workbook or a ***,
even though I quit excel, the process remains.

Essentially, if I do not create workbooks/sheets, no problem.

Excel = actxserver('Excel.Application');
set(Excel,'Visible',1);
invoke(Excel,'Quit')
delete(Excel)

Excel will start, open a window, quit, and kill the process. This is
good.

But, if I do anything like

Excel = actxserver('Excel.Application');
set(Excel,'Visible',1);
Workbook = invoke(Excel.Workbooks,'open','Book1.xls');
% or any other .xls file in existence
invoke(Workbook,'Save');
Workbook.Close;
% ok, now the wookbook was saved and closed
invoke(Excel,'Quit');
% ok the window closes
delete(Excel);

The excel process (under task manager) lingers. It is not destroyed.
In R2006b, I can't even link to it again. In R2007a, I can even do
Excel=actxGetRunningServer('Excel.application')
and fire it up again, but I would like to kill the process.

Can you help?

Thanks so much!

Nick Firoozye

John Reilly wrote:


Hi Paul,

I don't think you need an in-depth understanding of COM. I've
never
found a decent non-programmer's guide to it. Here is a link to a
relevant page in the uSoft documentation:

<http://msdn2.microsoft.com/en-us/library/ms683835.aspx>

Let me summarize. A DLL is a "dynamic link library"; Unix has been
doing the same thing for years but has called it a "shared
library".
What this means is that the OS loads the code, contained in the
library, one time in its memory and multiple processes can access
the
same code at the same time. So memory is only used once, even
though
N processes are calling it. The N processes access the code when
the
OS "maps" the code into each process's virtual memory. Thus, to
each
process, the code appears like it is actually loaded into the
process's memory (which it really is thru the miracle of virtual
memory) when it is in truth loaded into *multiple* processes's
memory.

A COM object is an abstraction consisting of the object (e.g. an
Excel spread***) and the methods (or functions) that you can call
to do things with this object. The methods are organized
(partitioned, divided, however you want to think about it) into
logical groups called interfaces. As a contrived example, say
there
was an interface ISaveable (by convention, interfaces begin with an
I) that defines methods Save() and SaveAs(). Your Excel and Access
COM objects might implement ISaveable, which means that both
objects
must implement Save() and SaveAs().

A COM object is implemented in code somewhere (duh). It can be
implemented in one of 2 major models: in-process and
out-of-process.
In-process means DLL, as the definition of DLL above indicates.
The
code for the COM object is somewhere on your disk in a file
xxx.dll.
When your process creates the COM object, the OS loads the DLL into
your virtual space and the COM object's memory is allocated WITHIN
your process's virtual memory space.

An out-of-process COM object is the opposite. The COM object code
is
defined in an executable (EXE) somewhere. When you create the COM
object, the OS runs the EXE and
uses an inter-process communication (IPC) channel to call methods
on
the COM object. This EXE may be running on your local machine,
*OR*
on a remote machine to which your application communicates using
DCOM
(Distributed COM). Notice that the memory for the COM object is
*NOT* in your process's space, but is in the COM server's space.

As you might imagine, the in-process COM object is faster than the
out-of-process due to the overhead of IPC.

A COM server is the DLL or EXE which actually implements the COM
object methods. A COM client is your process which creates the COM
object and calls methods on it.

What is a COM object? In the days before .NET, uSoft's answer to
Java was the Component Object Model. Succinctly, it is a binary
specification of data and interface for creating software
components
(i.e. objects). If an object is a COM object, then you can
immediately know how to call it from C, Basic, and Fortran because
it
adheres to the COM spec. VB was *built* on COM technology and uses
it implicitly. ActiveX is a special type of COM object with more
stringent requirements. When something is an ActiveX component, it
*is* a COM object, although the revserse is *not* necessarily true.

Unless you are a programmer, that should be all you need to know.
Give the uSoft MSDN documentation a browse. The definitive book is
"Essential COM" by Don Box, but you shouldn't read it unless you
want
to write a COM object.

If you have any other questions, you can email me or continue this
thread and I can answer them. I am a software guy who has been
doing
COM for years.

Good luck.

John.

pauldepstein wrote:


Perhaps this is a little OT as my question isn't directly
matlab-
related but it's certainly matlab-inspired.

To understand the actxserver command, I typed "help actxserver"
and
I
found that there's quite a lot of reading I will need to do to
understand this area.

For example, I don't understand what is meant by dll, com
server,
com
object, in-process server etc.

Does anyone know of any good beginner's reading for this type
of
info
on the web?
If not, are there any good books which cover this?

Thank you very much,

Paul Epstein


.