- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi
We recently changed from using intel visual fortran compiler 19.0.8.234 (using visual studio shell 2015) to using intel Fortran Compiler Classic 2021.9.0 (oneAPI) both in x64.
We noticed that our modeless dialogs does no longer respond when pushing the close button in the corner of the dialog.
I made the attached example using the template for windows application -> Dialog Code in 19.0.8.234 in visual studio shell 2015.
We found that a work-around was to place a hidden "cancel" button in the dialog and then intercept the IDCANCEL, however I would rather not do this for all my dialogs.
Any other suggestions?
Best regards
Lars
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
That is the behaviour in Intel® Fortran Compiler Classic 2021.11.0 [Intel(R) 64] also FYI. the x32 is also the same. I question for Intel staff really as to what the expected behaviour of the IFLOGM routines is as to if this is a bug or a feature!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@LarsJ, what version of Visual Studio Shell are you using with Intel Fortran Compiler Classic 2021.9.0?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We use two different setups:
1) VS2015Shell + Intel fortran 19.0.8.234 - works as expected.
2) VS2022 17.5.4 + 2021.9.0 (oneAPI) - does not close when pushing [x]
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@Barbara_P_Intel I used the OP's example with OneAPI 2024.0 and VS2022 17.0.5 and get the same behaviour.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The lines in iflogm.f90 that are responsible for the change in behaviour are (from line 1953 in the current file)
! ignore unsupported controls
if (i .eq. 0 .and. id .eq. IDCANCEL .and. hwndControl .eq. 0) then
call DefaultPushbuttonCallback(dlg,IDCANCEL,0)
return
end if
if (hwndControl .eq. 0_HANDLE) then
return
endif
in the old cvf version it was just
! ignore unsupported controls
if (i .eq. 0) return
which actually reflects the comment. Intel have added to it over the years. Firstly
! ignore unsupported controls
if (i .eq. 0 .and. id .eq. IDCANCEL .and. hwndControl .eq. 0) then
call DefaultPushbuttonCallback(dlg,IDCANCEL,0)
return
end if
which is an error as the if statement is never .true. so the effect, as far as the dummy IDCANCEL button that presumably this is supposed to catch, is the same as before - though an unsupported control now drops through. The most recent change which has caused the behaviour you are seeing is
! ignore unsupported controls
if (i .eq. 0 .and. id .eq. IDCANCEL .and. hwndControl .eq. 0) then
call DefaultPushbuttonCallback(dlg,IDCANCEL,0)
return
end iff
if (hwndControl .eq. 0_HANDLE) then
return
endif
Presumably this is supposed to trap a control that has hwndContrl equal to zero. Unfortunately the dummy IDCANCEL button that closes the dialog does have a zero hwndControl value and so now is ignored. (A real button with id IDCANCEL, visible or invisible, on the dialog has a non-zero value of hwndControl and drops through to the subsequent code and is handled correctly.)
To keep the changes that Intel have made the code could perhaps be modifed to
! ignore unsupported controls
if (i .eq. 0) return
if (id .eq. IDCANCEL .and. hwndControl .eq. 0) then
call DefaultPushbuttonCallback(dlg,IDCANCEL,0)
return
end if
if (hwndControl .eq. 0_HANDLE) then
return
end if
Until Intel releases a fix you can copy iflogm.f90 from the Intel include folder, edit it and add it to your project.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Good spot @mfinnis but I will further muddy the water in that IDCANCEL is set in IFWINTY ( integer, parameter :: IDCANCEL = 2 ). In a C++ app it is set in the .h headers. It should not be coming back as zero so there is an initialisation issue somewhere.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
IDCANCEL is, as you say, a parameter with value 2. The value of hwndControl is the window handle of a control. For the dummy button with id IDCANCEL it is zero. The variable i is the index into Intel's list of a dialog's controls which, if the control isn't supported by Intel, is zero.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
By the dummy button I think you mean the [x] on the window/dialog menu. That should return IDCANCEL value. The fact that is isn't doing that is part of the problem. I haven't used IFLOGM for some years I use the SDK direct and the [X] returns 2 (IDCANCEL) irrespective if I have a cancel button (with ID =IDCANCEL) or not .
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The dummy button is an entry in Intel's list of controls for the dialog. When the dialog's close command is issued the above code is run after the index of the control with an id of IDCANCEL is determined, which is either a real button with id IDCANCEL or the dummy button if there isn't a real button. There is no problem other than the code in iflogm.f90 has been modified so that it inadvertently returns without processing the dummy button.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The [x] button is a standard Microsoft window control that has a defined default action to close the window. You can chose to process that control in a call back if you wish by the a setsub with IFLOGM or a windows dlgproc with sdk. The point I am making the issue with different behaviours is entirely a product of the intel code IMO.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for all the input.
For info. We made this work around (placed in main message loop):
!handle close button [x] in the corner and close command in menu (work around due to change in iflogm behaviour)
if ( (msg%message == WM_COMMAND .and. msg%wParam .eq. IDCANCEL) .or. (msg%message == WM_SYSCOMMAND .and. msg%wParam .eq. SC_CLOSE) ) then
ignor = DestroyWindow(msg%hwnd)
cycle
endif
Regards
Lars
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I've noticed the same problem with IFX. This issue has been forwarded to our engineering team for a fix. Thank you for your report.
![](/skins/images/D2683F18326913BBA0436CB7114DD569/responsive_peak/images/icon_anonymous_message.png)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page