Programatically get path of open Excel/Word-document - c#

Is there any way to get the path of documents currently open in Microsoft Word and Microsoft Excel?
I know how I can fetch the PID and the window handle for the running instance of Excel or Word, but I have no idea how to get the path of the open document. Is it even possible?
I am thinking that an API would be nice, but I doubt it even exists. Perhaps some kind of plugin that sends information to my application is a possibility? (But if any other way is possible, I'd like to avoid having to install plugins everywhere.)
I would prefer to do it using C#, but anything that can be compiled into an executable is alright.
And just in case someone thinks this sounds fishy, it is not to be used for anything remotely illegal. It is for a data collection system at work.

There is an API called Office Interop... it is basically a COM based interface for MS Office... and can be used from C# .
For Excel you can get the current file including path via Application.ActiveWorkbook.FullName.
For Word you can get the current file including path via Application.ActiveDocument.FullName.

Related

Filesystem Hook for .doc open C#

I'm writing an application that needs to be notified of every doc file that is opened, I've tried using the FileSystemWatcher but it seems that these days NotifyFilter.LastAccess is disabled due to a large overhead.
There is LastWrite which I suppose I could use but it would mean I'd need to try and figure out the original file name from the temporary file that word creates when it opens a document.
I also need to keep watch on 4 directories so ideally I don't want to be polling them.
I'm aware I could write a WordAddin which is one option but that means another deployment to manage, another codebase and another product to support along with the problem that many users always see addins as a source of slowdowns.
Is there a straightforward way to tell windows Vista upward that I want to know about doc or docx that is opened?
One thing I was wondering about is if I could alter the default program associated with .doc to mine, which is running as a service and then passing the details through it to mine to be opened? This seems like a bit of a hack so I was wondering if there was an easy way to hook into these sorts of file open?
UPDATE
From talking it through with various people here the most reliable way(and most resource effective) would seem to be to replace the existing file association for .doc. & .docx to my own program and then use Microsoft.Office.Interop.Word to launch word and then hook into the DocumentOpen event.
That way I get the file name thats being opened along with any future documents that are open in word.
If I recall correctly, the temporary file that is created in the same folder has the file name format of ~$ + filename, for example:
~$very_important_file.doc
It contains the name of the user that opened the file. Note that the file has the hidden attribute set.
This makes it quite easy to figure out which document is actually open and by whom.
Such tasks are usually accomplished using filesystem filter drivers. Procmon works this way. You can create your own filter driver or use the precreated one (eg. our CallbackFilter).

extracting a file without letting the user access it

I was always pretty impressed by those programs that you could install by executing one installer file, which would then extract all the other required files to run the actual program.
And even now im still wondering how you would code a program that extracts files that are literally still inside the program ( so not in some kind of zip) , i've seen tons of installers for games who have this. I need this cause I want to extract a file on the right moment without giving the person who uses the program the ability to delete the file before its extracted, this may seem vague, but I hope i've informed you enough.
I'm just going to say that building an installer is difficult.
I'd recommend using NSIS: http://nsis.sourceforge.net/Main_Page
As for creating a file the user can't access, create a temp file with the correct read/write permissions, extract the data to the temp file, then copy the file where it needs to go.
Extract happens without the user interfering, and copy protection is handled by the OS.
What about changing the build action for the file you want to hide to Embedded Resource, or something like that that compiles the file inside the dll/exe?
Executable program is just file, So you can append any data at you executables. (works for my c++ compiled program)
$ cat executables some_blob_data > new_executables
Since argv[0] of main() is name of your file, you can use this to acess data in this file itself (works for c or c++ and likley for other languages to)
A really simple way to do this is to use your archive tool or one of the dozens of already made installers. WinRar, WinZip and most others allow the creation of self extracting exe files. I know you've said that is not what you want but if you make sure to make it auto exec your installer app and remove all of the temporary files when you're done it really can be very fool proof and professional looking. Obviously, the various installer applications are able to do what you're wanting.
If you really want to do this yourself the easy solution is going to most likely be dependant on your IDE software and language. The generic answer is that you'll need a compression library which can accept a stream as input. Then you'll want to make your actual files into resources inside your installer app. At that point it's just a matter of telling the compression library to read from a stream which is pointed at the resource. How that is done varies greatly from language to language.

Can I determine the temporary path of an open excel workbook?

I'm trying to create an excel file from ASP.NET. I assume this file is created somewhere temporary right? How can I get this location?
What are you using to create the Excel file? Since you have an ASP.NET tag I hope you are not trying to do this with Office COM Automation, it is not supported and trust me it is very very unreliable. See this link from Microsoft http://support.microsoft.com/kb/257757
Key message from the link
Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
I would suggest that you take a look at using NPOI library, it is very fast and works reliably on the server side. And you can then control where the file is generated.
If you are using a temp path or a temp file you should not care about where it is. If you need to care you should use a concrete path with a concrete file. You can also use a MemoryStream to do this all without HardDisk.
EDIT:
Additional to the comment I recommend you to use Open XML to create a Excel Sheet. If this is an option let me know than will I post more on that.
I must say I didn't know this article from Chris Taylors post and if I had found this one last year it had saved me a lot of time. But what I must say at this point; it is possible to get a serverside solution running which uses interop and I need it last year. But it was a pain till it work and if anyone want to give it a try here are some advices:
you should not use interop directly
from a ASP apllication
you can't use impersonation (it may
fail unexpected)
you will need a service which runs as
System
you need a executable that runs the
interop
you have to manage the the execution
through the service (and I mean
manage, not just starting)
And again; I don't recommend to do this. Use any other solution if you. (MS Supports automation services with SharePoint2010)

Resolve path of Excel

Actually I intended to ask the following question:
For an executable that lies in a
directory defined in %PATH%, how can
I find out in which of these directory
it is found?
because I need to run Excel from C# using Process.Run(...), and just indicating "Excel" works fine: Windows seems to know where to find it. However I need to provide the appropriate working directory, too.
But in the meantime I found out that Microsoft Office is not even in the %PATH%, Windows apparently resolves it in another way.
So how could I use or mimic this functionality from Windows to get the directory containing excel?
Update: Besides the suggestion of Ruel, is there a straighter way to achieve this? I know that Windows is able to resolve the path in some way, so I'd like to reuse this functionality if possible.
Any idea?
Fetch it from the registry: HKLM\SOFTWARE\Microsoft\Office\(VERSION)\Excel\InstallRoot for the VERSION it can be 10.0 11.0 etc. You can detect it by checking if there's a subkey Excel in it.

Invoke client side MS Word - VS2008/C#3.0

I have a asp.net web site. I want to invoke MS word on a Client machine. Is there any easy way to do this with VS2008, C#3.0?
I can do this with Qt and with an ActiveX control but trying to avoid going this way...
would silverlight be a way to go?
You want to execute an application from the browser (without the evil ActiveX things, of course)?! If you could do that, probably you could wipe off the whole disk too.
And no, Silverlight runs in a partially trusted sandbox. It won't run unmanaged executables on the client machine.
If you are just trying to get Word open to view a document, you could just give your user a link to the .doc/.docx file and their browser would take care of opening the file. If you want to interact with Word, you're going to have a hard time doing that from the browser without using ActiveX.
Silverlight has the same locked down sandbox environment that the web browser has, so that won't help you get around this security limitation.
What are you trying to do with Word? Even if you could launch the app, I don't think you could do any kind of COM interaction from within your web page.
An easy way to merely launch Word would be to have the user download a Word file, but I don't think that's what you're asking and they might not open the file -- they could choose to save it instead.

Categories

Resources