Dialog not closing in 2021.9.0

[LarsJ]

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

[andrew_4619]

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!

[Barbara_P_Intel]

@LarsJ, what version of Visual Studio Shell are you using with Intel Fortran Compiler Classic 2021.9.0?

[LarsJ]

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]

[andrew_4619]

@Barbara_P_Intel  I used the OP's example with OneAPI 2024.0 and VS2022 17.0.5 and get the same behaviour.

[mfinnis]

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.

[andrew_4619]

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. 

[mfinnis]

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. 

[andrew_4619]

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 .

[mfinnis]

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.

[andrew_4619]

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. 

[LarsJ]

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

[Devorah_H_Intel]

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. 

[Devorah_H_Intel]

This issue is fixed, and the fix will be available in the ifx 2025.1 release.