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

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 -

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


"Joseph Geretz" <jgeretz@nospam.com> wrote in message
news:OVWSrUGLGHA.668@TK2MSFTNGP11.phx.gbl...
> 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 -
>
>

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 -
>
>
>

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!!

"Joseph Geretz" <jgeretz@nospam.com> wrote in message
news:OVWSrUGLGHA.668@TK2MSFTNGP11.phx.gbl...
> 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

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.

--
www.alignment-systems.com


"David Welch" wrote:

> 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!!
>

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

"Joseph Geretz" <jgeretz@nospam.com> wrote in message
news:OVWSrUGLGHA.668@TK2MSFTNGP11.phx.gbl...
> 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 -
>
>

John.Greenan wrote:
> 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.

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" <JohnGreenan@discussions.microsoft.com> wrote in message
news:3B735683-7775-4833-9FB5-AADC1AFC5474@microsoft.com...
> 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 -
>>
>>
>>

Joseph,
Would using the OLE control be suitable ?

NickHK


"Joseph Geretz" <jgeretz@nospam.com> wrote in message
news:ugxLWcPLGHA.2336@TK2MSFTNGP12.phx.gbl...
> 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" <JohnGreenan@discussions.microsoft.com> wrote in message
> news:3B735683-7775-4833-9FB5-AADC1AFC5474@microsoft.com...
> > 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 -
> >>
> >>
> >>
>
>

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 -

"NickHK" <TungCheWah@Invalid.com> wrote in message
news:%23G%23vOfRLGHA.2912@tk2msftngp13.phx.gbl...
> Joseph,
> Would using the OLE control be suitable ?
>
> NickHK
>
>
> "Joseph Geretz" <jgeretz@nospam.com> wrote in message
> news:ugxLWcPLGHA.2336@TK2MSFTNGP12.phx.gbl...
>> 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" <JohnGreenan@discussions.microsoft.com> wrote in message
>> news:3B735683-7775-4833-9FB5-AADC1AFC5474@microsoft.com...
>> > 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 -
>> >>
>> >>
>> >>
>>
>>
>
>