Home |
Search |
Today's Posts |
#8
![]()
Posted to microsoft.public.excel.programming
|
|||
|
|||
![]()
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 - |
Thread Tools | Search this Thread |
Display Modes | |
|
|
![]() |
||||
Thread | Forum | |||
How do I isolate my Excel server (automation) from other Excel instances? | Excel Discussion (Misc queries) | |||
excel user's manual | Excel Discussion (Misc queries) | |||
Excel General Environment | Excel Discussion (Misc queries) | |||
Excel 2003 Error Cannot Locate the Internet Server or Proxy Server | Excel Discussion (Misc queries) | |||
DTS: SQLServer to Excel in unattended server environment | Excel Programming |