Shellexecute to open a Word.doc - no reaction 1

[Koen Piller]

Hi,

I would like to open a word.doc in my VFP application and have therefore constructed:

DECLARE INTEGER SellExecute in Shell32.dll ;
INTEGER hhdWin, ;
STRING cAction, ;
STRING cFileName, ;
STRING cParams, ;
STRING cDir, ;
INTEGER nShowWin

lcFileName = "myWord.DOC"
= shellexecute(0,"open",lcFilename,"","",1)

And nothing, virtualy nothing, happens.
So I replaced lcFilename with

SYS(5)+SYS(2003)+"\archief\myWord.doc"

still nothing

needless to say.
- Word is installed on this PC
- Directory archief is found in my path
- File myWord.DOC resides in SYS(5)+SYS(2003)+"\archief"

What possibilities do I have to correct this unwanted behavior?

Regards,

Jockey(2)

 

[Olaf Doschke]

Your root problem is not shellexecute not working, but file associations. It's more compilcated than the open with settings suggest. ShellExecute is about DDE actions.

Take this example: Both the DBF and the PRG file extension are associated with VFP, but they make VFP act differently. If you lose associations and simply reconnect DBF with VFP via the windows explorer settings, then DBFs are opened in the VFP editor.

Something is halfways right, so you can start a doc via double click, but the DDE open action is not defined or defined wrong.

Bye, Olaf.

 

[Scott24x7]

That's a good point Olaf.
And easy to fix...

Navigate to any word file.
Right click it.
Select "Open With" from the drop-down.
Check on the box that says "Always use this to open with"
Select Word from the list of applications.

Now it's associated with it, going forward and the Shellexec will work.


Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

"Everything should be made as simple as possible, and no simpler."

 

[Olaf Doschke]

Well,

Scott, I don't think so.

That meachnism is breaking functioning associations. Shellexecute is about DDE actions, "open" is one, "print" another one, these actions are not defined by "associating" files manually with the mechanism you describe. This association is already existing from what Jockey describes, as double clicking the word doc opens it. It's the thing MS should rather remove from the Windows Explorer because it can break more than it heals. You only define the open action and it's defined in a simplistic way, assuming the EXE takes the file name as first parameter to open it. That's not necessarily working. If you associate DBFs this way with VFP9.exe they are opened with the editor like PRGs instead of opened in a workarea. There are typically different actions and even for the same action like OPEN there are different ways to start an EXE and that's not at all simply defined by the "open with" associaation, especially for more complex applications like MS Office Word.

Jockey, just to answer an earyl question: This should work for your customers, as long as they have Word installed, normally its associations are working, you must have done something at your dev pc, that works for double clicking docs, but not for ShellExecute. What version of Word are you using under which OS?

Bye, Olaf.

 

[Scott24x7]

Olaf,
Disagree. Just tried this by changing the default app for opening .PDF from Acrobat Pro to Acrobat Reader. Even without a restart of VFP, launching a .PDF from it using SHELLEXE() function I have worked fine. It used Reader instead of full Acrobat to launch them. Then changed it back, 20 seconds later, same result. I'll try a .RTF open in .DOC and vice versa... but this should 100% work.


Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

"Everything should be made as simple as possible, and no simpler."

 

[Olaf Doschke]

It obviously does not work with Jockeys Word version.

As I already said that merely depends on the application and how it reacts to the kind of association you do with "always open with.." associations.

To expand once further: See what registry keys Sergey Berzniker does for VFP file extensions here:

https://www.berezniker.com/content/...file-associations-open-files-one-vfp-instance

The DDE entries are not done by "always open with..". So in the general case you better not use this simplified meachnism to change file associations.

Bye, Olaf.

 

[Scott24x7]

Just did the same thing with .DOC
Changed it to use Wordpad to open .DOC with launched a .DOC from link in VFP. Changed it back to Word using same process, and it instantly worked.

I don't see where anyone has offered the solution like this to set file association. If his OS won't recognize file association, then it's either a) broken, or b) not Windows...

Run Windows Repair to fix registery problems, or reinstall Windows...

JOCKEY2

Have you tested this on another machine? Does it work fine there?
If it does, then your OS is broken.

If it doesn't then your code is broken.


Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

"Everything should be made as simple as possible, and no simpler."

 

[Olaf Doschke]

Again: It obviously does not work with Jockeys Word version. The version might also be important and also the OS.

And I trust Jockey already made such an association as he says the doc opens via double click on the file but not via ShellExecute. He gets error 31, not 2, so the file must exist and there is no obvious error in code, but in associations only half ways working. Some half baked registry entries must make the one thing work and the other not.

Bye, Olaf.

 

[Mike Lewis]

Jockey,

This is a bit of a long shot, but it might be worth trying.

Instead of passing "open" as the second parameter to ShellExecute(), try passing "edit".

The reason I say this is that you tested the file associations by double-clicking on the doc file. But that implies that the default action for double-clicking is "open", which it usually is, but not necessarily; it might just possibly be something else, and "edit is the most likely.

Come to think of it, you can check it by right-clicking on the doc file, and then seeing whichever context menu entry shows up in bold. If it is indeed "open", then the above will be a waste of time. If not, pass the relevant verb as the second parameter.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Another long shot would be: Deinstalling Word, cleaning up the registry from any word related keys (I don't know if MS offers some registry cleanup, most probably you'd rather find some third party tool sepcialised on Office reg keys) and then reinstalling word. Or work on another machine, where Word file associations are not in this nonworking state. It's an exception anyway, but surely an exception your customers also can be confronted with. It's just more likely such association errors happen on a dev machine when you develop with several things and try out code samples etc. than it happens to the average user. Unless you have power users trying the one or other thing themselves.

Bye, Olaf.

 

[Mike Lewis]

Yet another possibility ....

Could it be that the file associations are specific to a user? When I say "user", I mean the person who is logged into Windows. If User A installs an app, does User B's instance of the app always see the same file associations? I don't know.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Could be. Many parts of the registry are still a puzzle to me, but are existing in both the local machine and the user branches of the registry. It's not a database, it's the registry.

Bye, Olaf.

 

[Koen Piller]

Olaf,
I am working with Word2013 and have also Word365 installed. OS = win10, VFP version= 7425
--
Shellexecute() working like a charm with PDF, the second time I activated it showed me the PDF in < 1 sec. Grr behind my Mainscreen, with a Adobe logo on the windows statusbar, 1 click and it showed up front.
--
It seems this is a pc-related problem.

Thanks for support, the moment I have found the solution I will report back,

Regards,

Jockey(2)

 

[Mike Lewis]

Jockey,

You've had a lot of suggestions for tackling the original problem. I appreciate you will probably want to stay with the PDF solution, but if you do have time to try the other suggestions, it would be useful if you could let us know the results. That would be helpful if any of us ever come across the same problem again.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

I only have DOCX here for testing with Word 2013, but on Win 8 ShellExecuting a docx works OK.

Someone posted a problem with !|RUN on Windows 10 at MSDN Foxpro General Forum today, that he couldd fix by setting compatibilty to Windows 95. That shouldn't be related and surely is nothing to try with Word2013. Are you sure you have that Word version installed locally or is executing a doc starting a webbrowser showing the doc online? Office365 is no local installation. It may come with the permission to install the full blown Word2013 and still profit from the OneDrive and other online meachnism, but Office 365 rather is your license for using a Web Office, not associating DOC or DOCX with a locally installed software.

Bye, Olaf.

 

[Tore Bleken]

Jockey,

I am pretty sure that the problem is that you have two versions of Word installed on your machine. Word 365 can't be automated, and has many other shortcomings. So if Word 365 was installed last, the registry will tell your computer to use Word 365, which can't be automated.... In other words, it's a catch 22 situation. The fix may be to install Word 2013 again, or you may have to uninstall Word 365 completely.

 

[Dan Freeman]

I'm having a similar issue with Office 365 on a Win7 machine.

The machine originally had Office 2003 installed. It was uninstalled after the later version was installed, I suspect. And then Outlook 2003 was reinstalled because of incompatibilities with our Exchange server.

IAC, if I double-click an XLSX file, it doesn't open. I get a SaveAs dialog. As mentioned earlier in this thread, right clicking the file and examining the default option shows SaveAs where it should show Open (Or Edit).

Something is whacked somewhere but this machine is temporary so I'm unlikely to have time to dig into it much. But it's frustrating trying to work with XLSX files and relearning how to open the dang things!

 

[Mike Lewis]

I am pretty sure that the problem is that you have two versions of Word installed on your machine. Word 365 can't be automated, and has many other shortcomings.

You are right about that. But would it explain why ShellExecute() doesn't recognise the file association? That was Jockey's basic problem, and was not related to automation.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Indeed automation is not the same mechanism as file associations, but booth root in registry keys defining actions and if such installations flaw the keys for automation it's likely also file associations are flawed, even though Jockey does not have the problem dan has with the wrong SaveAs action.

Bye, Olaf.

 

[Mike Lewis]

Good point, Olaf. But it's interesting that when Jockey double-clicked on the file, Word was successfully opened. I would have thought that ShellExecute() executes the same actions that the user performs in the Windoows UI (the "shell"). But I'm not sure about that. Unfortunately, I don't have Office 365, so I can't test it for myself.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Koen Piller]

Mike,
I believe you should forget about Office365 in this case, since when I double click Word2013 is activated.
I am now processing to test the application as is on a different pc.
Regards,
Jockey(2)