IFDLG100.DLL: Porting 32-bit App to Win10

[arney]

I'm up against a deadline to get a CVF application with ActiveX controls ported to IVF/Win10.  First off, I apologize, but I've read the topics regarding CVF porting/AvisGrid and registering IFDLG100.DLL, but just didn't seem to find a comprehensive solution. 

The application included the AvisGrid Grid Control. After deactivating the AvisGrid calls, I have successfully been able to port/build and fully execute the application on a WinXP using IVF12 and VS 2005, with no glitches.  All GUI screens work w AvisGrid deactivated portions just blank, which is what I was going for. However, when I built this on a new system with Composer XE 2016, VS Studio Pro 2015, and Win10, and try to execute, it bombs.

Investigations revealed issues with IFDLG100.DLL.  Initially, the program bombed because it could not find IFDLG100.DLL.  Even after following directions to register IFDLG100.DLL it is failing.  This is confusing when it works successfully on the IVF12/VS2005/WinXP.  For starters, I'm unsure how to properly register IFDLG100.DLL for Win10 for a 32-bit application.  I followed directions on how to register using regsvr32.  However, this step was not successful (i.e., it still was not finding IFDLG100.DLL when running the app).  

I then used regWow32 and the full path to 32-bit IFDLG100.DLL.  This is now causing an access violation error message that I was not getting before when it simply wasn't finding the DLL.

Not a high-end user, but appreciate prompt advice.  

[arney]

Ok, search revealed the error above because I didn't use "Run as Administrator" when I opened a command window to perform regsvr32.  Registration was successful once I did.

[arney]

After successful regsEvr32 registration error, now getting the following error:

Dialog Procedure Error: "Error creating ActiveX Control {38B7A3DD-8CA4-11D2-A6AA-E4215A82BCA0} - Class not registered."

[Steven_L_Intel1]

Your ActiveX DLL also needs to be registered.

[arney]

Makes sense.  However, I'm not sure how to find out which DLL it's missing.  When we provided an installer of this application for the CVF version, I noticed the following DLLs were included:  

AVIEW160.DLL; DFDLL100.DLG; MSVcp60.DLL; MsVcRt.DLL

I suspect it's AVIEW160.DLL, as that is the CVF Array Visualizer AvisGrid; however, I thought with all the Grid Control calls commented out that this wouldn't be needed?  DFDLL100.DLG looks directly replaced by IFDLG100.DLL.  

[Steven_L_Intel1]

Something is still referencing the AVGrid control, maybe a dialog box? There would not need to be explicit calls to reference it. Check your dialog box resource file for references to the control.

[arney]

Ok, another clue, I think... When I went back into Visual Studio 2015 Pro after the regsvr32 steps and tried to open one of the dialogs that had the Avis Grid control (albeit commented out) and got the following message:

Microsoft Visual Studio: "The ActiveX control "AvisGrid Control" could not be instantiated because it requires a design-time license".  

As you know, AvisGrid came with Compaq Array Visualizer.  I have CAV 1.6 loaded on the WinXP system that does successfully build with IVF12/VS2005/WinXP.  I do not have any of the CVF/CAV components loaded on the Win10 system. I do have a license, albeit no original installation disks any more.  Thoughts?

[Steven_L_Intel1]

Sorry, I have no idea what this is looking for nor how you would get around it, other than by removing all references to the control from the dialog box. I am quite familiar with Array Visualizer from CVF.

[arney]

Well, something is fishy, regardless.  

As another example of "oddities" with porting the program from CVF to IVF: I found that the program bombs at runtime even for standard control dialogs (i.e., those created via Visual C++ design), unless I specifically add IFLOGM.f90 code into my solution.  Just having the library in the path isn't enough.  So, that perplexes me, but did get resolved.  It has been the remaining dialogs that had ties to Avis Grid that I can't get working with IVF16/VS2015.

[Steven_L_Intel1]

You probably are building with /iface:cvf. This will break dialog callbacks so I suggest you make sure the project property Fortran > External Procedures > Calling Convention is set to Default. Failure to USE IFLOGM could cause problems in passing arguments.

You need to scan the .rc file for references to the AV control and remove them.

[arney]

Yes.  When I ported the solution, Visual Studio kept the "/iface:CVF" switch.  I didn't know of any changes I should make for that until mentioned earlier in this thread.  I did apply those "DEFAULT" changes for the Avis Grid routines, however, the routines are on comment lines so I don't see what benefit that was.  

It is evident the callbacks are the source of the problem.  I am using "USE IFLOGM" to include the modules in the code.  However, the callbacks don't appear to be found or correct at runtime unless I build in (via compilation) IFLOGM.F90 in the project solution. I will change the calling convention properties per your suggestion and see what happens.  

[rwg]

Adding Interfaces helps.

I had the same problem. My program was designed in 2009 and used /iface:cvf because it used some code written in plain c.

I compiled it with Intel Fortran version 17.0.0.109 and got unhandled exceptions in dlgdomodal.

Simply adding !dec$ attributes default did not help but adding an interface for my callbacks solved my problems.

This fails, but worked in old versions of Intel Fortran (perhaps CVF):

       PROGRAM TEST
       EXTERNAL MYCALLBACK
       ...
       LRET=DLGSETSUB(DLG,IDD,MYCALLBACK)
       ...
       END

       SUBROUTINE MYCALLBACK(DLG,IDD,CALLBACKTYPE)
       ...

This fails too:

       PROGRAM TEST
       EXTERNAL MYCALLBACK
       ...
       LRET=DLGSETSUB(DLG,IDD,MYCALLBACK)
       ...
       END

       SUBROUTINE MYCALLBACK(DLG,IDD,CALLBACKTYPE)
       !DEC$ ATTIBUTES DEFAULT::MYCALLBACK
       ...

This is OK:

       MODULE MYCALLS
       CONTAINS
       SUBROUTINE MYCALLBACK(DLG,IDD,CALLBACKTYPE)
       !DEC$ ATTIBUTES DEFAULT::MYCALLBACK
       ...
       ENDMODULE MYCALLS

       PROGRAM TEST
       USE MYCALLS
       ...
       LRET=DLGSETSUB(DLG,IDD,MYCALLBACK)
       ...
       END