Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.



When compiling attached file ' NISPHelp.f, I get error #6404 at line 56: need explicit TYPE for [GETDESKTOPWINDOW].

Likewise for file 'ElmntHelp.f', lines 34,36,44,50 all generate error #6404 for [HTMPHELP], [HELP_CONTENTS], [HH_CONTEXT], and [HH_QUIT]. 

I am pretty far out-of-date, but hopeful of finding the SDK or the API with these definitions.  There are caveats and workarounds in the pre-2009 code which have probably changed.

Thank you for your assistance.


0 Kudos
1 Reply
Honored Contributor II

I suspect I misunderstand your question, but...

The USER32 module provided with the compiler provides an interface for GetDesktopWindow.  HELP_CONTENTS is in the similar IFWINTY module, which I expect is also made available by USER32, but your use of that symbol, which is from the very old WinHelp API, in ElmntHelp in a call to HtmlHelp, looks wrong to me.  I suspect there is more confusion between the WinHelp and HTMLHelp API's in that subprogram.

I am not aware of Fortran bindings for HtmlHelp, though they would be relatively trivial to construct.

The subprogram in NISPHelp.f already has an interface for HtmlHelp.  You could extract that into a module and then use that module in the subprogram in ElmntHelp.f.

The other symbols do not appear in the C header files for HtmlHelp (these header files are distributed with the Windows SDK, or are available within the separate download for Html Help Workshop, versions may differ).  Perhaps HH_CONTEXT is a misspelling of HH_HELP_CONTEXT, which you already have defined in the NISPHelp subprogram.

Some years ago, HtmlHelp was effectively deprecated, but with no clear alternative to replace it.  It's status might reflect be why attempts to find the documentation for the HtmlHelp API function proper on MSDN result in a page not found error.   The HtmlHelp API reference is included in the help for Html Help Workshop.

(Ordering within use statements is not significant - if you are seeing a difference in behaviour due to a different ordering of statements, then that is likely a symptom of a compiler bug.)

0 Kudos