Posted to microsoft.public.excel.programming
|
|
How do I isolate my Excel Server from the user's general Excel env
Joseph,
Would using the OLE control be suitable ?
NickHK
"Joseph Geretz" wrote in message
...
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 -
"John.Greenan" wrote in message
...
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
--
www.alignment-systems.com
"Joseph Geretz" wrote:
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 -
|