How to action GetOpenFileNameW wide Win32 API

[MikeWinsteps]

Folks, I need to access Korean folders and file names using a dialog box. IFORT 2024.2 with VS2022 does not recognize GetOpenFileNameW Win32 API. How do I do it?

[Steve_Lionel]

None of the W functions are declared because Intel Fortran doesn't support wide characters. You can declare the function yourself, but you'll also have to declare the OPENFILENAMEW structure. Look at the declarations of the A versions in commdlg32.f90 and ifwinty.f90 as a basis.

A word of caution - the function documentation I linked to above incorrectly gives OPENFILENAME as the structure type, but as suggested in "Syntax", it is actually OPENFILENAMEW.

[MikeWinsteps]

Thanks, Steve:

Success to far:

OPENFILENAMEW structure - is already defined, Good.

GetOpenFileNameW interface constructed, modeled on comdlg32.f90 - good!

Source code now compiles OK with GetOpenFileNameW

Problem: Linker reports "unresolved external symbol GETOPENFILENAMEW"

GetOpenFileNameW is a name in ComDlg32.lib, but perhaps I am not looking at the same one as IFORT uses. Where does IFORT look for ComDlg32.lib?

Any other suggestions anyone?

[Steve_Lionel]

If you'll look at the source for comdlg32.f90, you'll see that each routine uses an ATTRIBUTES DECORATE,STDCALL,ALIAS directive to give the mixed-case name of the function. You haven't done that so you get the default upcasing. You should be able to adapt the GetOpenFIleNameA declaration and make the minor edits for the W version.

[MikeWinsteps]

Hi Steve. Yes, I copied the comdlg32.f90 code changing A to W. But IFORT would not accept DECORATE in my INTERFACE code. 

So I used a hex editor on the .obj file to replace GETOPENFILENAMEW with GetOpenFileNameW, and it worked! The app linked and ran!

Now to persuade IFORT to do this for me. Is there a compiler switch to output mixed case symbol names or some other method?

[Steve_Lionel]

Please fix this the correct way. Show us your interface block, and the error message, so that we can see what the problem is. 

[MikeWinsteps]

Steve here's the code snippet. It compiles in the full version but the linker complains:

Error error LNK2019: unresolved external symbol GETOPENFILENAMEW referenced in function STDFIL stdfil.obj

Hex edit  stdfil.obj, changing GETOPENFILENAMEW to GetOpenFileNameW, and it links and runs correctly.

    SUBROUTINE  STDFIL  (hDlg)
    use ifwin
    
    INTERFACE 
    FUNCTION GetOpenFileNameW( arg1)
      use ifwinty
      integer(BOOL) :: GetOpenFileNameW ! BOOL
      !DEC$ ATTRIBUTES DEFAULT, STDCALL, DECORATE, ALIAS:'GetOpenFileNameW'  :: 'GetOpenFileNameW'
      TYPE (T_OPENFILENAME) arg1 
     END FUNCTION
    END INTERFACE

    record /T_OPENFILENAME/ ofnx

    INTEGER*8 MAXREC
    INTEGER*8 hDlg; value hDlg
    PARAMETER (MAXREC=260)
    ! these are assigned in actual code
    CHARACTER*(MAXREC) PATHHERE, NAMEHERE, FILTERHERE, PROMPTHERE. LOCALCD
    CHARACTER*10 SUFFIX3
    integer rvalue

    ofnx.lStructSize       = sizeof(ofnx)
    ofnx.hwndOwner         = hDlg 
    ofnx.hInstance         = 0  
    ofnx.lpstrFilter       = loc(FILTERHERE)
    ofnx.lpstrCustomFilter = 0
    ofnx.nMaxCustFilter    = 0
    ofnx.nFilterIndex      = 0
    ofnx.lpstrFile         = loc(PATHHERE)
    ofnx.nMaxFile          = len(PATHHERE)
    ofnx.lpstrFileTitle    = loc(NAMEHERE)
    ofnx.nMaxFileTitle     = len(NAMEHERE)
    ofnx.lpstrInitialDir   = loc(LOCALCD)
    ofnx.lpstrTitle        = loc(PROMPTHERE)
    ofnx.Flags             = 0
    ofnx.nFileOffset       = 0
    ofnx.nFileExtension    = 0
    ofnx.lpstrDefExt       = loc(SUFFIX3)
    ofnx.lCustData         = 0
    ofnx.lpfnHook          = 0
    ofnx.lpTemplateName    = 0

    rvalue = GetOpenFileNameW(ofnx)  
    
    END

[mfinnis · Accepted solution]

You shouldn't have the quotation marks around the external name ie:

!DEC$ ATTRIBUTES DEFAULT, STDCALL, DECORATE, ALIAS:'GetOpenFileNameW'  :: GetOpenFileNameW
      

[GVautier]

Hello

Shouldn't the !DEC$ statement start in column 1 ?