Changes to Dialog module iflogm in latest compiler update

[Stephen_Sutcliffe]

I updated to the latest compiler yesterday and when I tried running the program after rebuilding my project the dialog boxes stopped working properly. I had a look at the iflogm.f90 module source in the installation folder and when comparing with the previous version noticed that the type of the controlid variables had been changed to integer(INT_PTR) in place of the INTEGER defeinition used previously. As the control ID parameters are created by deftofd.exe these are still defined as INTEGER in my resource.fd include file so could lead to a mismatch. These resource.fd files do not get regenerated automatically but I am reluctant to try this until I have a better understanding of what has been changed and why. I just need reassurance that this change is correct as I wouldn't have expected control ID s to be pointers.

Funnily enough I've been using a local version of iflogm because of a bug that I had reported to Intel many years ago where variables were not being intialised correctly when using the non-supported controls such as treeview and listview. The bug would cause intermittent program crashes when dialogs were being opened up after using a dialog with one of these non-supported controls.  I fixed the bug using a local copy and have been using it ever since. 

I does however look as though the i mentioned bug has been fixed at last.

As it takes about a hour to compile I wanted to get a better understanding of what has been changed and what I need to do to resolve the issue if I am to move onto the latest compiler.

I wish Intel would provide a full list of the changes like they used to do in the past. It is always a bit of a gamble that your code will continue to work after an update and this is exacerbated when you've no idea what has been changed. 

Has anyone got any thoughts on this that might be of help.

Thanks

Steve

[andrew_4619]

by latest I guess you mean xe2020 update 2? I am on update 1 so can't easily check, what do you mean by "controlid variables had been changed to integer(INT_PTR)" or specifically could you post an example.

If that  means in  interfaces to dialog routine where a controID is passed than that would be a bug as it will be wrong in x64 builds. 

[Steve_Lionel · Accepted solution]

This changed between the 2019 (19.0) and 2020 (19.1) versions. For a 32-bit application, it is harmless, but for a 64-bit application I can see it breaking working programs. There is more than one place that a default integer (32-bit) was changed to a pointer-sized integer, including as arguments to one or more of the DLG routines.

At first I was very upset by this, as it could be an incompatible change, but the more I looked into it I was having difficulty finding a scenario where it would be a problem. Except... you said you were using your own copy of IFLOGM.F90, and that's a problem, as it is no longer consistent with IFLOGM.LIB as provided by the 2020 product.

The issue you're having isn't related to the definitions in the .fd file, which are just PARAMETER constants and the compiler can convert those as needed. What is a problem is the data structure(s) declared in your copy of the module no longer match the library linked in. That, and one or more of the routines now take a 64-bit integer on x64 when they didn't before.

Really, you did this to yourself. If you had also copied iflogm.lib and linked to a local copy of that, you would not have seen a problem. But when you mix an old module with a new library, that's a problem.

[Steve_Lionel]

I've been thinking about this some more, and I need to revise what I wrote above. In essence, the Intel Fortran run-time library made an upwards-incompatible change in the interface to one or more of its routines. This violates a decades-long principle of the Fortran library (for which I was a developer for many years) of always being upwards-compatible. By this I mean that once you have compiled a Fortran source into object form, you should always be able to link it to a newer set of language support libraries.  This dates back to the VMS days - I'll note that the Intel C++ team does not follow this, nor does Microsoft C++.

I wish they had found another way to resolve whatever the issue was.

[andrew_4619]

I think it is true to say that other than a few bug fixes and maintaining compatibility with the latest compiler there has been no development of the "iflogm/dflogm" dialog routines for many years. They make a useful starting point for some simple front end windows style  user interface but have limited support for  a very limited sub-set of the range of dialog controls available. For that reason I long ago dropped the use of these routines and opted just to use the windows API. Once the basic concepts are mastered that is really not difficult to do. Some more extensive dialog samples using the API would probably be quite useful for new users IMO. 

Anyway that  is my two penneth on this subject....

[Stephen_Sutcliffe]

Thanks everyone for your thoughts. Based on what you all said I decided the best course of action was to simply remove my custom iflogm.f90 from my project solution and rebuild everything. I believe the bugs that needed my tweaks have been fixed and these were the only parts I had changed.

DlgIssueError had hinst argument defined as INTEGER which is now correctly defined as INTEGER(HANDLE)

and in DlgInitWithResourceHandle function the following lines of code were added after comment:

! Not a recognized control, zero out the sizes so that we don't
! try to deallocate them in DlgUninit.
! SS Fix
dlg % list(dlg%NumControls) % id = 0
dlg % list(dlg%NumControls) % control = 0   (Intel used ctrl_error instead of 0)

BTW The application I am working on is quite large and has evolved over at last twenty years. The dialog module was useful early on (back in Powerstation/Digital Fortran days, remember them?) to quickly get a working prototype at the time. Nowadays I generally use the Windows API approach if I need something not supported in dflogm. There are too many dialogs (100s of them) to convert them all to API when they normally work very well. The secret is to perform the setting up of controls in a callback subroutine (using the Dialog form control ID in function DlgSetSub(dlg,IDD_,..)) where the dialog box handle is available. This method was not covered by the example provided back in the day where I think it actually called the callback routine before the dialog was created by the DlgModal function. Therefore I agree with the comment regarding provision of examples of the API approach using FORTRAN would be useful. I remember a book by Norman Lawrence called Compaq Visual Fortran being a good guide for this though this only covered 32-bit option.

[Stephen_Sutcliffe]

I can now confirm that the dialog functionality has been fully restored by removal of the custom iflogm.f90 from the project and rebuilding.

So thanks again to everyone for taking the trouble to help and advise.

[Paul_Curtis]

I am using a much older version of IVF, but...

1) I have never found deftofd to work reliably, and long ago created a stand-alone helper program which reads the .h files created by the resource editor and writes a custom output "myprog.fd" which is then explicitly included in my (Win32) code.  All the Windows items are of type INTEGER.

2) My main product is a native Windows program written entirely in IVF, calling WinAPI functions for extended and complex UI with a wide variety of Windows features, accessed via the provided interfaces (except when the needed interfaces are missing or wrong, in which case they have been created manually).  This program is 120K+ lines of code, comprising 60+ modules, and the entire code compiles and links in under one minute.  I am curious what are the metrics and aspects of your code which requires an hour to compile, that strikes me as indicating some other major issues.