After seeing numberous posts (I believe by Albert Kallal(sp?)) regarding
using Application.Hyperlink rather than the Shell command to open files, I
recently applied this to a small utility db. I deployed this db about a week
ago, and the Application.Hyperlink worked fine, for everything except one
filetype in particular.

Here's the basic code I used:

sDocPath = "\\DSServer\Data\PartDocs\509.dwf"
Application.FollowHyperlink sDocPath

The sDocPath variable changes depending on which doc is going to be viewed
(509 is the ID for this particular one), but the folder never changes. The
file extension is stored in the table and is contencated after the ID. This
works for .xls, .doc, .pdf, .dwg, .sldpart, basically everything except .dwf
(.dwf files are distributable versions of Autodesk files).

My first thought was that the .dwf filetype wasn't registered with the local
computer, but as it turns out, it is. I can manually go to the file and open
it, no big deal. (the server itself is strictly a fileserver... it doesn't
even have msoffice installed). I've verified the file's existance through a
FileExist function in vba, and everything looks fine there. But if I run
FollowHyperlink on any .dwf file that has been entered, it acts as though it
should open it (no errors raised, code goes through without any issues), but
nothing happens.

The user brought this up this morning, so I switched him back to the
ShellExecute API that generally use, and now everything works fine.

Any ideas why Application.FollowHyperlink is failing for this particular
filetype? I even went to the extent of making sure that the entire path was
case-matched, to no avail.

Thanks


--
Jack Leach
www.tristatemachine.com

- "A designer knows he has reached perfection not when there is nothing left
to add, but when there is nothing left to take away." - Antoine De Saint
Exupery

For the record, I've always found these .dwf files to be a major pain... I
constantly run into errors trying to view them (autodesk puts out a new
viewer about every 6 months or so and if you don't use the right one with the
right files, it won't work), but alas I have no choice as my customer
distributes only these .dwf cad viewing files.

Is it possible that there may be a security feature associated with the
filetype (put there by Autodesk) that prevents them from opening via
hyperlink addressing? I don't know much about how the system handles stuff
like this (if there's even a difference), but I thought it an odd coincidence
that my least favorite of all filetypes is now giving me issues with methods
that others have used without fail.

--
Jack Leach
www.tristatemachine.com

- "A designer knows he has reached perfection not when there is nothing left
to add, but when there is nothing left to take away." - Antoine De Saint
Exupery


"dymondjack" wrote:

> After seeing numberous posts (I believe by Albert Kallal(sp?)) regarding
> using Application.Hyperlink rather than the Shell command to open files, I
> recently applied this to a small utility db. I deployed this db about a week
> ago, and the Application.Hyperlink worked fine, for everything except one
> filetype in particular.
>
> Here's the basic code I used:
>
> sDocPath = "\\DSServer\Data\PartDocs\509.dwf"
> Application.FollowHyperlink sDocPath
>
> The sDocPath variable changes depending on which doc is going to be viewed
> (509 is the ID for this particular one), but the folder never changes. The
> file extension is stored in the table and is contencated after the ID. This
> works for .xls, .doc, .pdf, .dwg, .sldpart, basically everything except .dwf
> (.dwf files are distributable versions of Autodesk files).
>
> My first thought was that the .dwf filetype wasn't registered with the local
> computer, but as it turns out, it is. I can manually go to the file and open
> it, no big deal. (the server itself is strictly a fileserver... it doesn't
> even have msoffice installed). I've verified the file's existance through a
> FileExist function in vba, and everything looks fine there. But if I run
> FollowHyperlink on any .dwf file that has been entered, it acts as though it
> should open it (no errors raised, code goes through without any issues), but
> nothing happens.
>
> The user brought this up this morning, so I switched him back to the
> ShellExecute API that generally use, and now everything works fine.
>
> Any ideas why Application.FollowHyperlink is failing for this particular
> filetype? I even went to the extent of making sure that the entire path was
> case-matched, to no avail.
>
> Thanks
>
>
> --
> Jack Leach
> www.tristatemachine.com
>
> - "A designer knows he has reached perfection not when there is nothing left
> to add, but when there is nothing left to take away." - Antoine De Saint
> Exupery