Opening Word document from VB6 in Windows 7/8 issue

Question

I have an old VB6 app that opens an Word document (.doc). It has worked perfectly on Windows XP for a long time. My problem is that when I install the app on Windows 7 or Windows 8, the code will open Word, but not bring up the actual document. When it opens Word, I am able to navigate to file and open it perfectly fine, so there is no issue with the file. It seems like I'm missing something simple here, but after a lot of searching and reading, I can't pinpoint it.

I've made sure that Word is the program associated to .doc files on the Windows 7 and 8 computers, so that's not it.

Here is the code I use to open the document:

Dim iret As Long
iret = ShellExecute(hwnd, vbNullString, QuoteFilePath & File1.FileName,  vbNullString, "c:\", SW_SHOWNORMAL)

Any help is appreciated!

Works for me (VB6 on Windows 7), but try passing `"open"` as the second parameter. — GSerg, Mar 24 '13 at 16:36
Where is `QuoteFilePath` located? What is the full `QuoteFilePath & File1.FileName` when this is called? This can either be a problem with the file name or location, or a user rights issue on Win7/8 that didn't exist on XP. It may also be because you're setting the working directory to `C:\`, which is not writable by standard (non-admin) users on Vista and above. — Ken White, Mar 24 '13 at 16:41
the quoteFILEpath is the folder "users\public\public documents" on Windows 8 machine. The file is located in a subfolder called "data" and the filename is a series of numbers followed by .doc (ex: 3434332.doc). If I shouldn't set the working directory to C:, what should I set it to? — John Marzion, Mar 24 '13 at 16:53
@GSerg..setting it to "open" made no difference. Thanks for the thought. — John Marzion, Mar 24 '13 at 17:05

Bob77 · Answer 1 · 2013-03-24T18:38:14.710

0

There are a number of reasons why this special folder should not actually be used to store user documents. Microsoft and even 3rd parties have begun to use it for entirely different purposes. Depending on what applications have been installed you might even find DLLs in here.

If you mistrain users to play with this folder they might delete a file critical to the operation of some other program.

But if you insist on doing this note that it is not safe to refer to the folder by a literal string value since it can appear under varying aliases based on the user's language settings. It might even be relocated elsewhere through administrative actions.

It also hasn't been necessary to stoop to using the non-COM ShellExecute entrypoint in ages, at least as far back as version 5.0 of Shell32.dll.

This should work at least from WinXP forward:

Option Explicit

Private Const ssfCOMMONDOCUMENTS As Long = &H2E
Private Enum SHOW_WINDOW
    SW_HIDE = 0
    SW_SHOWNORMAL = 1
    SW_SHOWMINIMIZED = 2
    SW_SHOWMAXIMIZED = 3
    SW_SHOWNOACTIVATE = 4
    SW_SHOW = 5
    SW_SHOWMINNOACTIVE = 7
    SW_SHOWDEFAULT = 10
End Enum

Private Shell As Object
Private Path As String

Private Sub File1_Click()
    On Error Resume Next
    'Works on XP through Vista, fails on Win7:
    'Shell.ShellExecute File1.FileName, , Path, "open", SW_SHOWNORMAL

    'Works on XP through Win7:
    Shell.ShellExecute Path & "\" & File1.FileName, , , "open", SW_SHOWNORMAL
    If Err Then
        MsgBox "Error " & CStr(Err.Number) & " " & Err.Description
    End If
End Sub

Private Sub Form_Load()
    Set Shell = CreateObject("Shell.Application")
    With Shell.NameSpace(ssfCOMMONDOCUMENTS).Self
        Path = .Path
    End With
    With File1
        .Pattern = "*.doc"
        .Path = Path
    End With
End Sub

edited Mar 24 '13 at 18:38

answered Mar 24 '13 at 18:18

Bob77

13,167
1
29
37

Well I spoke too soon. This code works on XP and Vista but fails on Win7: "Windows cannot find 'dummy.doc'. Make sure you typed the name correctly...". Something else seems to be at work here. – Bob77 Mar 24 '13 at 18:28
1

Ok, found a way that works even on Win7 though I don't like it. Hard to say what changed, perhaps something related to the doofy "Libraries" concept added to the Shell in Windows 7? – Bob77 Mar 24 '13 at 18:39
I'm using public documents because I need a place where all users on a machine can read/write documents and mdb files. If I put in mydocuments, not all users can see. If I put in appdata, it's hidden. I though Public Documents was exactly that...a place to put documents and files you want all users to see/have access. This stuff is driving me crazy! Where should I put user created documents/writable mdb's and what was your way that works in Windows 7? – John Marzion Mar 24 '13 at 19:26
1

I had edited the example above so that it works in Windows 7. Look for the comments. I don't have another suggestion for a shared common document folder aside from creating a folder on some non-boot partition. That fact that people are installing DLLs into CommonDocuments is very unfortunate. You could try telling your users to be careful. But in general you don't want users to see MDB files anyway, so CommonAppdata makes more sense. – Bob77 Mar 24 '13 at 23:46
thanks for your help, I truly appreciate it. I have a combination of mdb files and user generated word quotes. They like to be able to edit/attach the quotes to e-mails and a machine might have more than 1 user who is going to access them, so MyDocuments was out. They won't see them in CommonAppData, so I figured put them in Common Document folder. I'll try your code for opening Word docs and see if it improves thins on Win7/8. – John Marzion Mar 25 '13 at 02:09
As long as the users don't mess with anything else in there it should be ok. Another option is to create your own folder under Public, but the Public special folder does not exist until Vista and even then there is no CSIDL/SSF value for it (you have to use KNOWNFOLDERIDs with another Shell API call instead). – Bob77 Mar 25 '13 at 16:33

Opening Word document from VB6 in Windows 7/8 issue

1 Answers1