Opening a Word document from an app

[gazza67]

Hi,

I want to do something that I thought would be simple but i cant seem
to work it out, perhaps someone out there could help me.

I want to browse for a file (it will be a word document), save the file
name to a string and then at some later stage open that file with word.

The operating system will be windows 2000 (dont know if that makes a
difference or not).

string pathToWord = "c:\\Program File\\Microsoft
Office\\Office\\winword.exe";

OpenFileDialog theDiag = new OpenFileDialog();
theDiag.ShowDialog();
string theFileName = theDiag.FileName; // note the file name is
c:\Test Directory\testFile.doc

Process.Start (pathToWord, theFileName);


This resulted in word trying to open two files called c:\test and
Directory\testFile.doc.

Could someone tell me what I can do to make word see this filename
correctly?

Another question is, if I dont include the pathToWord and just rely on
Windows to work out how to open a .doc file it takes almost 30 seconds
to open the document (it does it successfully - but it takes too long)
- even though if I go into the file explorer and double click on the
..doc file it will open inside word immediately. I dont really want to
include the path for word (since it may be different on different
computers) - how do I get around this problem?

Gary

 

[Steve Barnett]

To fix the file name splitting problem, wrap the file name in quotes. Word
will see it as a single paraneter then.

To find the Word executable, you can wrap the FindExecutable api call. Just
pass it the name of the file you're about to open.

[System.Runtime.InteropServices.DllImport("shell32.dll")]
static extern int FindExecutable(string fileName, string fileDir,
System.Text.StringBuilder buffer);

// Returns the name and path of the EXEcutable file that is associated to
the specified file.
// Returns an empty string if there is no such associated file,
// and raises an error if the file or the path hasn't been found.

public string GetExecutableFile(string filePath)
{
const int ERROR_FILE_NO_ASSOCIATION = 31;
const int ERROR_FILE_NOT_FOUND = 2;
const int ERROR_PATH_NOT_FOUND = 3;
const int ERROR_FILE_SUCCESS = 32;
System.Text.StringBuilder buffer = new System.Text.StringBuilder(260);

// call the FindExecutable API function and process the return value
int ret = FindExecutable(System.IO.Path.GetFileName(filePath),
System.IO.Path.GetDirectoryName(filePath), buffer);

if (ret == ERROR_FILE_NOT_FOUND || ret == ERROR_PATH_NOT_FOUND)
throw new System.IO.FileNotFoundException();
else if (ret == ERROR_FILE_NO_ASSOCIATION)
return "";
else if (ret >= ERROR_FILE_SUCCESS)
{
// extract the ANSI string that contains the name of the associated
executable file
return buffer.ToString();
}
else
return "";
}

HTH
Steve

 

[Tom Porterfield]

I want to do something that I thought would be simple but i cant seem
to work it out, perhaps someone out there could help me.

I want to browse for a file (it will be a word document), save the file
name to a string and then at some later stage open that file with word.

The operating system will be windows 2000 (dont know if that makes a
difference or not).

string pathToWord = "c:\\Program File\\Microsoft
Office\\Office\\winword.exe";

OpenFileDialog theDiag = new OpenFileDialog();
theDiag.ShowDialog();
string theFileName = theDiag.FileName; // note the file name is
c:\Test Directory\testFile.doc

Process.Start (pathToWord, theFileName);

This resulted in word trying to open two files called c:\test and
Directory\testFile.doc.

Could someone tell me what I can do to make word see this filename
correctly?

Another question is, if I dont include the pathToWord and just rely on
Windows to work out how to open a .doc file it takes almost 30 seconds
to open the document (it does it successfully - but it takes too long)
- even though if I go into the file explorer and double click on the
.doc file it will open inside word immediately. I dont really want to
include the path for word (since it may be different on different
computers) - how do I get around this problem?

The following should work a little faster:

OpenFileDialog opf = new OpenFileDialog();
opf.Filter = "Word Files|*.doc|All Files|*.*";
if (opf.ShowDialog() == DialogResult.OK)
{
string wordDoc = opf.FileName;

System.Diagnostics.ProcessStartInfo psi = new
System.Diagnostics.ProcessStartInfo();
psi.FileName = wordDoc;
psi.UseShellExecute = true;

System.Diagnostics.Process.Start(psi);
}

 

[gazza67]

Thanks for replying Tom,
When I supply a startInfo to Process.start I cant specifically supply
the application (ie winword) AND when i dont specifically supply
winword.exe and its path the startup time for the document within
winword is about 30 seconds. This method does however solve the problem
of winword looking for a list of files rather than just one, its just
that its too slow to be useful.

Gary

 

[gazza67]

Steve,

Thanks for replying, I know this is an agonisingly basic question but
how do I wrap a string in quotes?

As for the method for finding the path of an associated application I
will definitely use this code i think.

Thanks a lot.

Gary

To fix the file name splitting problem, wrap the file name in quotes. Word
will see it as a single paraneter then.

To find the Word executable, you can wrap the FindExecutable api call. Just
pass it the name of the file you're about to open.

[System.Runtime.InteropServices.DllImport("shell32.dll")]
static extern int FindExecutable(string fileName, string fileDir,
System.Text.StringBuilder buffer);

// Returns the name and path of the EXEcutable file that is associated to
the specified file.
// Returns an empty string if there is no such associated file,
// and raises an error if the file or the path hasn't been found.

public string GetExecutableFile(string filePath)
{
const int ERROR_FILE_NO_ASSOCIATION = 31;
const int ERROR_FILE_NOT_FOUND = 2;
const int ERROR_PATH_NOT_FOUND = 3;
const int ERROR_FILE_SUCCESS = 32;
System.Text.StringBuilder buffer = new System.Text.StringBuilder(260);

// call the FindExecutable API function and process the return value
int ret = FindExecutable(System.IO.Path.GetFileName(filePath),
System.IO.Path.GetDirectoryName(filePath), buffer);

if (ret == ERROR_FILE_NOT_FOUND || ret == ERROR_PATH_NOT_FOUND)
throw new System.IO.FileNotFoundException();
else if (ret == ERROR_FILE_NO_ASSOCIATION)
return "";
else if (ret >= ERROR_FILE_SUCCESS)
{
// extract the ANSI string that contains the name of the associated
executable file
return buffer.ToString();
}
else
return "";
}

HTH
Steve

Hi,

I want to do something that I thought would be simple but i cant seem
to work it out, perhaps someone out there could help me.

I want to browse for a file (it will be a word document), save the file
name to a string and then at some later stage open that file with word.

The operating system will be windows 2000 (dont know if that makes a
difference or not).

string pathToWord = "c:\\Program File\\Microsoft
Office\\Office\\winword.exe";

OpenFileDialog theDiag = new OpenFileDialog();
theDiag.ShowDialog();
string theFileName = theDiag.FileName; // note the file name is
c:\Test Directory\testFile.doc

Process.Start (pathToWord, theFileName);


This resulted in word trying to open two files called c:\test and
Directory\testFile.doc.

Could someone tell me what I can do to make word see this filename
correctly?

Another question is, if I dont include the pathToWord and just rely on
Windows to work out how to open a .doc file it takes almost 30 seconds
to open the document (it does it successfully - but it takes too long)
- even though if I go into the file explorer and double click on the
.doc file it will open inside word immediately. I dont really want to
include the path for word (since it may be different on different
computers) - how do I get around this problem?

Gary

 

[Tom Porterfield]

Thanks for replying Tom,
When I supply a startInfo to Process.start I cant specifically supply
the application (ie winword) AND when i dont specifically supply
winword.exe and its path the startup time for the document within
winword is about 30 seconds. This method does however solve the problem
of winword looking for a list of files rather than just one, its just
that its too slow to be useful.

You don't supply the path to winword.exe because setting UseShellExecute to
true as in the example instructs it to use the Windows Shell to determine
how to open the file based on how the file extension is registered with
Windows. It should basically behave the same as if you double clicked the
word document. It shouldn't be any slower than that and on my machines it
is not any slower.

 

[gazza67]

Hi Tom,

I completely agree with what you say and actually it was the first
thing I tried. However it does seem to take too long to start up.

Attempt 1
Setup a StartInfo object
Process.Start(StartInfo);
Result -> file opens up correctly after hanging for 20-30 seconds.

Attempt 2

String stringA = path to Word
String stringB = path to document

Process.Start(stringA, stringB);
Result -> word immediately starts however it has incorrectly tried to
open up a list of files (defined by stringB)


Gary

 

[Tom Porterfield]

I completely agree with what you say and actually it was the first
thing I tried. However it does seem to take too long to start up.

Attempt 1
Setup a StartInfo object
Process.Start(StartInfo);
Result -> file opens up correctly after hanging for 20-30 seconds.

Have you tested this on multiple machines? Are all machines experiencing
this delay, or only 1 or a few.

Attempt 2

String stringA = path to Word
String stringB = path to document

Process.Start(stringA, stringB);
Result -> word immediately starts however it has incorrectly tried to
open up a list of files (defined by stringB)

That's because winword treats the space as a separator and thinks each word
is a separate argument on the command line. If you want to go this route
you need to do as Steve suggested and put the file name in quotes. That
could be done as follows (using the syntax from your original post):

string theFileName = "\"" + theDiag.FileName + "\"";

 

[gazza67]

Thanks for you Help Tom,

I have found that Steves method works, I just didnt know how to do the
quotes, thanks for the syntax.

I will go with Steves solution although not knowing why you get the
delay sorta bugs me - but life is too short to track all of these
things down I guess.

Gary