How do I isolate my Excel Server from the user's general Excel environment?

[Joseph Geretz]

I'm trying to use Excel as an automation server form within my own
application, but I'm finding it very difficult to keep my own instance of
Excel isolated from the user's general Excel environment. I've found the
basic setting 'Ignore other Applications' (I forget the programmatic
property, and I don't have my code in front of me right now) which keeps my
copy of Excel isolated form any Workbooks / Excel instances that the user
may open from the windows shell. However this does have a rather nasty side
effect - it prevents workbooks from being opened by simply double-clicking
them from the windows shell. Presumably, by directing Excel to ignore DDE
requests (DDE - and this is 2006 :-\ ) it sets up Excel to ignore DDE
requests from the windows shell.

What the @$##$^% has Microsoft done here? How can Excel be taken seriously
as an automation server, if we can't create an isolated instance which
doesn't wack out and doesn't get wacked out by other instances of Excel??
This is Windows after all. The OS which is suppoed to support more than one
thing going on at any given time.

Thanks for any guidance which you can provide.

- Joe Geretz -

 

[NickHK]

Joseph,
Launching Excel using Automation from VB6 (not VBA), setting
MyXLApp.IgnoreRemoteRequests = True, means that XL files opened from
Explorer are open in a new instance of Excel.
i.e. My instance ignores DDE requests, but .IgnoreRemoteRequests is NOT set
to True for future instances of Excel.
Setting Excel.Application.IgnoreRemoteRequests = True from within the VBA
IDE, sets this prpoerty to True for future instances of Excel.

AFAIK, there's no simple way to islate your instance from COM

So are you trying to do this from VBA ?

NickHK

 

[Guest]

Hmm, this is a nasty problem...

At the very core, your problem is this - Excel is NOT designed to run as a
server for a VB6 or VC++ or whatever application. If someone else run
GetObject they might get your object. I spent six months working on an
application to run Excel on a server. In theory it should have worked, but
in practise we had to write a load (thousands of lines) of VB6 code with lots
of Windows API calls to get an instance of Excel and kill it when finished
(application.quit just does not always work) in a production safe, reliable
manner. We actually had more plumbing code than we did application code.

The code is copyright, so I cannot post it here, but I could give you a few
pointers if you are interested

 

[David Welch]

In my experience GetObject won't work if the Excel window has not been
activated. I think this would
be the case if Excel was started like:
Set xlapp = New Excel.Application

since the window is hidden by default?

Ignore the highlighting in this email!!

 

[Robert ap Rhys]

I'm trying to use Excel as an automation server form within my own
application, but I'm finding it very difficult to keep my own instance of
Excel isolated from the user's general Excel environment. I've found the
basic setting 'Ignore other Applications' (I forget the programmatic
property, and I don't have my code in front of me right now) which keeps my
copy of Excel isolated form any Workbooks / Excel instances that the user
may open from the windows shell. However this does have a rather nasty side
effect - it prevents workbooks from being opened by simply double-clicking
them from the windows shell. Presumably, by directing Excel to ignore DDE
requests (DDE - and this is 2006 :-\ ) it sets up Excel to ignore DDE
requests from the windows shell.

What the @$##$^% has Microsoft done here? How can Excel be taken seriously
as an automation server, if we can't create an isolated instance which
doesn't wack out and doesn't get wacked out by other instances of Excel??
This is Windows after all. The OS which is suppoed to support more than one
thing going on at any given time.

Just thinking out loud here, so feel free to shoot me down in flames if I've
over-simplified things, but how about hooking the Workbook_Open event in
your Server instance? You can then check if the workbook being opened is
'authorised' (i.e. has been instructed to open by the server itself). If it
is unknown, assume it has been instructed to open via DDE, get it's fullname
property, immediately close it and then re-open it via the ShellExecute API.

Robert

 

[Guest]

Correct. You may have to send a windows message to the Excel window and then
GetObject will work.

This is in the msdn as well.

 

[Robin Hammond]

Joseph,

Just a quick thought. Is there something you are doing with Excel that
cannot be done with the Office Web Components? I haven't tested in a full
production environment yet, but I have an early beta web app running server
side under .net 2 that hooks to OWC and it seems to be fairly stable.

Robin Hammond
www.enhanceddatasystems.com

 

[David Welch]

Correct. You may have to send a windows message to the Excel window and then
GetObject will work.

This is in the msdn as well.

Ahha, this will fix a problem in an Excel hyperlinking program I've been
working on.

 

[Joseph Geretz]

Hi John,

I don't know if it's a case of you feeling my pain, or vice versa!

I'm trying to incorporate Excel document viewing into our document
management software. We natively handle a large variety of popular document
formats. However, in addition we can handle almost any document format by
finding its associated application and launching it, and then doing the
necessary API work to integrate it with our own application so that it looks
like a seamless part of our own UI. Up until this point, we've been using
ExcelViewer and WordViewer to handle Excel and Word documents (we haven't
been using Word or Excel since we need a medium which will initially present
the document in read-only mode) but we'd like to move to Excel/Word since
these are such popular formats and we can obviously get a much tighter
integration with Word / Excel automation.

Word was a breeze. But Excel - what a #$%^%&!

Anyway, after loads of aggravation, I think I've finally gotten Excel to
work. This involves removing all of the Excel UI framework (i.e. Taskbar
icons, Window Title, Menu, Toolbars), so that the 'document' area itself is
plugged into our UI to look like a seamless part of our UI. Stuff like this
was much more complicated than it really should be because we don't want
changes to our embedded Excel UI to impact other instances of Excel that the
user might launch from outside our application. Standard approaches to
removing Toolbars just won't cut it for us.

To address the main point of my thread, it seems that when setting
IgnoreRemoteRequests = True via COM, this will not affect the user's Excel
environment in general. However, you must set this back to False before
shutting down your instance of Excel, even if you set SaveChanges = False)
otherwise this setting is persisted and then the user's Excel environment is
impacted!

The main problem I'm left with now is that every so often, Excel trips an
error upon shutdown.

We actually had more plumbing code than we did application code.

Tell me about it! :-\

The code is copyright, so I cannot post it here, but I could give you a
few
pointers if you are interested

If you have any specific experience with presenting an Excel sheet with a
very minimalist UI (i.e. no menu, no toolbars, etc.) without impacting the
user's external Excel environment, I'd be very interested to hear any
releavnt advice. We did get this to work for us, but it's a terrifically
complex sequence of API work and seems very sensitive. I'd welsome a more
straightforward approach, but so far I just haven;t found it.

Anyway, thanks for the sanity check. (I was starting to wonder if maybe I am
losing my edge...

- Joe Geretz -

 

[NickHK]

Joseph,
Would using the OLE control be suitable ?

NickHK

 

[Joseph Geretz]

Hi Nick,

Would using the OLE control be suitable ?

I don't know. I'd have to try it. What is it and where do I get it?

Thanks!

- Joe Geretz -