I am running DOpus 9.1.1.8 x64 and I have a program called Nitro PDF Professional installed.
In Windows Explorer, I can right-click on a PDF file, select "Edit with Nitro PDF Professional" and it opens up in Nitro PDF no problem.
But if I use DOpus, after selecting "Edit with Nitro...", I get the error message dialog box stating:
This file does not have a program associated with it for performing this action. Create an association in the Set Associations control panel.
Note that the association is set because (a) it works from within Windows Explorer and (b) when I double-click on the file, it automatically opens up in Nitro.
I only get the error when I select the "Edit" context menu option from Nitro.
For what it's worth,
I also can confirm this using the Trial Version on Vista32.
This happens even if I make Nitro my Vista default pdf program.
Although it's almost moot, it may be worth noting for the debug process that my DOpus Open Action still is set as Adobe for PDF's.
Weird... and hey Leo, FWIW - your FileTypeDiag (nifty tool) code doesn't grab reg data for filetypes located under:
[b]HKEY_CLASSES_ROOT\SystemFileAssociations[/b]
...and I don't have studio installed at the moment to build and test changes .
Anyhow, the issue is not specific to NitroPDF, it rather seems generic to Opus not playing nice with shell actions defined under the key above under a filetype "extension" sub-key (like .pdf or .mp3, etc). In this case:
I don't usually see products add shell actions under this key, though there's often shellex menu handlers there... which has this NitroPDF product making me chuckle a bit, as it DOES also implement a menu handler which provides 'other' functions than the "Edit" menu item you're trying to use... and the menu handler is NOT implemented in THIS part of the registry.
Anyhow, not sure what's up with that... especially since things work just fine with keys under this path that are pointed to as a PerceivedType for a file extension.
As an example of how THAT works ok, here's a reg file (zipped up) that will create a key called PDFDocument under the key above... In order to make use of it, double-click on the PDFDocument.reg file to merge it to the registry. Then open Regedit and manually go to the HKEY_CLASSES_ROOT.pdf key... if the key already contains a string value called PerceivedType then rename it and create a new one, and set the value to PDFDocument...
You should now see a context menu entry when right-clicking on PDF files called Edit with Nitro PDF Pro that should actually work. To get rid of the changes entirely... you can just put back the original PerceivedType value, and delete the HKEY_LOCAL_MACHINE\SOFTWARE\Classes\SystemFileAssociations\PDFDocument reg key created by the double-clicking the attached .reg file...
So unfortunately, where i spend most of my time online (work and wireless card) i cant get bug reports through to GPsoft over smtp. I can only get it through via my home ISP gateway, and for the last few weeks have not been home much for anything but a few hours of sleep a night, and the weekends have been spent trying to get my kids to stop asking the wife, "mommy... who's that man on the couch"?
Some programs install their menus in ways which Opus doesn't see, either because they're undocumented or just because they weren't noticed before.
(Seems like there are about 100 different ways for context menus to be installed in Windows and Microsoft, in their wisdom, seem to add another 10 with every Windows release. Some of the changes made in Vista are still not documented, for example.)
Other programs assume things that aren't part of the API contract, basically assuming they will only ever be hosted in Explorer.exe and going haywire if hosted inside something which behaves slightly different.
In my experience most programs work fine, though.
If you find one which doesn't work you should report it to GPSoftware so they can look into why. (Or work around it by creating Opus buttons which call the program and do the same things, if the program has a command-line interface that lets you do so.)
I contacted the support team and they replied that they have installed mediainfo x64 and they don't have a problem with it. This is strange, could someone please try mediainfo?
I had the same problem under Vista 64 and my current Windows 7 x64 is a "clean" new system. I have tried both Mediainfo x32 and x64 with the same results.
I just checked. The value in the registry as you said. it is
"C:\Program Files\Video\MediaInfo\MediaInfo.exe" "%1"
and the program is installed in
C:\Program Files\Video\MediaInfo
Remember, the context menu does work in windows explorer.
So those values are correct. It just doesn't work in DOpus.
So there is something wrong there.
.
