•  
  • Addition of the DftiCopyDescriptor convenience function
  • Reduction in the size of statically linked executables calling DFTI functions
  • Support for DFTI_REAL_REAL storage (i.e., real and imaginary parts in separate arrays) in complex-to-complex transforms

In order to reduce the size of statically linked executable, we introduce specific functions in mkl_dfti.h 
like DftiCreateDescriptor_s_1d, DftiCreateDescriptor_s_md for different dimensions DFT. The specific function is used by the preprocessor macro definition.  Some DFT application in C/C++ may run into the compiler error 
"Undefined symbol '_DftiCreateDescriptor_s_1d' referenced in x.c"

Resolution : 
you can safely undefine it after inclusion of the Intel MKL FFT header file, as follows:
    # include "mkl_dfti.h"
    # undef DftiCreateDescriptor
or add compiler flag
    "-DDftiCreateDecriptor=DftiCreateDescriptor"  into preprocessor definitions of your project

Problem 2: Program crashed when upgrade to MKL 10.1

Regarding the data layout in fortran Interface, take  the code real_1d_ccs_double_ex6.f90 as sample
(DFT_VF_sample.zip is Intel Fortran project sample)  
It is Fortran-interface, do Real to CCS packed 1D DFT.  But the input and output data are from the column of two -dimension array. So the data storage layout need to be considered.

     Program REAL_1D_CCS_DOUBLE_EX6
      real(8) :: X_IN_2D (M_MAX,N_MAX)
      real(8) :: X_IN    (M_MAX*N_MAX)
      real(8) :: X_OUT_2D(M_MAX+2,N_MAX)
      real(8) :: X_OUT   ((M_MAX+2)*N_MAX)
      !      complex(8) :: X_OUT_C((M_MAX/2+1)*N_MAX)
      equivalence (X_IN,  X_IN_2D)
      equivalence (X_OUT, X_OUT_2D)
      !      equivalence (X_OUT_C, X_OUT_2D)
 
      integer   strides_in(2)
      integer   dist_in
      integer   strides_out(2)
      integer   dist_out
      dist_in  = M_MAX
      ! works with MKL Version 10.0.1 Product Build 072211.12 for 32-bit applications
      !$      dist_out = (M_MAX+2)/2

      !! works with MKL Version 10.1.0 Product Build 081809.14 for 32-bit applications and later
      dist_out = M_MAX+2
      Status = DftiCreateDescriptor( Desc_Handle, DFTI_DOUBLE, &DFTI_REAL, 1, n )
      Status = DftiCommitDescriptor( Desc_Handle )
     !  Status = DftiComputeForward( Desc_Handle, X_IN, X_OUT)
        Status = DftiComputeForward( Desc_Handle, X_IN, X_OUT_C)
        ....
X_OUT_C and dist_out = (M_MAX+2)/2 worked in previous version, but broken in latest version.

Resolution: 
To set dist_out=M_MAX+2

The use of X_OUT_C and dist_out = (M_MAX+2)/2  in previous version works because the  DftiCompute function in previous version reinterpret "the distance parameter" according to the X_OUT_C data type, which is corrected in latest version.

According to the code,
Status = DftiCreateDescriptor( Desc_Handle, DFTI_DOUBLE, &DFTI_REAL, 1, n )
Status = DftiCommitDescriptor( Desc_Handle )
It is a 1D real to CCS real transform and DftiComputeForward() will request two real array as input and output.  And the value of dist_out shoud be the distance in real-type array, not complex-type array.  So dist_out=M_MAX+2
is right value.

See more in MKL manual:
Once the descriptor is committed, the parameters of the transform, such as the type and number of transforms, strides and distances, the type and storage layout of the data, and so on, are "frozen" in the descriptor.   It should not be expected that DftiComputeForward would reinterpret the strides/distances.

Introduction

This article is aimed at users who are familiar with the ideas involved with managing a Modal dialog box, using call-back routines but who wish to expand its capabilities to permit customising windows using calls to the Windows API (Windows functions to you and me). This will involve introducing them to Windows messages, message queues, and window procedures and to the process of ‘subclassing'. The base for this application is the Dialog support provided by Intel Visual Fortran in module IFLOGM.  For details on the Dialog support, please refer to the Intel Visual Fortran documentation.

A Microsoft Visual Studio .NET 2003 solution and project with source code for this example is provided in the attachment linked at the bottom of the article.  The project assumes Intel Visual Fortran 11.0 or later is installed.

Figure 1 shows a dialog box where the dialog box background and several of its controls have had their colours changed from the standard default colours. This article is intended to show how this is done.

Figure 1: Coloured Dialog Box with Coloured Controls and Text

The Windows Message Loop

In any Windows application involving a dialog box,  all user actions and requests involving controls and menus in the dialog box are translated by the Windows system into "messages"  that are sent to a message queue that is set up by the system and associated with the dialog box. Each message in the message queue is then sent to a "dialog box procedure" to be processed and a value must be returned to the Windows system by the procedure that indicates how the message has been processed by the procedure. This defines a message loop for the dialog box.

If the user implements the dialog using the routines in the IFLOGM module, then he can assign a call-back routine to be used for one or more dialog controls. This permits the user's program to respond to user actions on controls and menus without having to deal directly with the Windows message loop for the dialog box, considerably easing the task of writing and running a dialog. However, the message loop is still running underneath.

When a dialog box is initialised using DLGINIT, the system assigns a default dialog box procedure to it for handling its message queue. This takes care of most of the work in maintaining the dialog box (for example, redrawing it when it is restored or uncovered after being partially or wholly hidden by another window). If the user includes the module IFLOGM to permit access to code for using call-back routines, then some messages are translated directly into calls to call-back routines specifically written to handle them and then return control to the system. However, the call-back method in IFLOGM does not permit the user to control the colours assigned to controls. If this capability is required, then you need access directly to functions in the Windows API and you need to access them at the correct time, when the appropriate messages are sent to the dialog procedure. Therefore you need access to the dialog procedure. This access is provided using the technique of ‘subclassing'.

Subclassing a Dialog

Once a user has become familiar with writing code to display and manage dialog boxes using routines supplied in the module IFLOGM a question that arises sooner or later is "How can I customise my dialog by adding colour?" One answer to this is to insert some of your own code to be used by Windows whenever parts of your dialog box have to be redrawn. The method by which this is done is called "Subclassing".  Subclassing is a technique that allows an application to intercept and process messages sent or posted to a particular window, before the window has a chance to process them, by using a ‘subclass procedure'. A subclass procedure is an application-defined window procedure (a function) that replaces a window's original window procedure when the window is subclassed. The subclass procedure is written by the user to contain code that recognizes certain Windows messages that the user wants to intercept and that then adds commands to Windows API functions before returning control back to Windows. Any messages not intercepted and processed must be passed on to the default dialog procedure, otherwise the dialog will stop functioning properly.

Where and When to Subclass the Dialog

The subclassing is done before the dialog is displayed. In the present example, this is achieved in a call-back routine called "BackColorSub" that is assigned to the dialog box itself using DLGSETSUB:

! Initialise the dialog
    lret = DlgInit(IDD_BACKCOLOR_DIALOG, gdlg)
    if (.NOT. lret) goto 99999
! Set 'backcolorSub' as the callback routine to be called before the dialog is displayed
! Code in 'backcolorsub' evaluates then stores the dialog control window handles in
! global variables held in module BACKCOLORGLOBALS
    lret = DlgSetSub(gdlg, IDD_BACKCOLOR_DIALOG, backcolorSub)

How to Subclass the Dialog

When the dialog box is initialised and just before it is displayed, the call-back routine BackColorSub is called and within the code for BackColorSub is the following code to subclass the dialog using the Windows API function SetWindowLongPtr:

SUBROUTINE backcolorSub( dlg, id, callbacktype )

  use user32
  use iflogm
  use ifwin
  use backcolorglobals
  use MyDlgMod ! Provides interface to MyDlgProc

  implicit none

  include 'resource.fd'	!Include the definitions of dialog box control IDs

  type (dialog) dlg
  integer id, callbacktype, ret
  integer(HANDLE) hdlg

  hdlg=dlg%hWnd			! Get the handle to the dialog window

! Do the next IF block if the dialog box has just been initialised but not yet displayed  
  if (callbacktype == dlg_init) then
    ret = MessageBox(ghwndmain, "Dialog call back reached..subclassing the dialog"C, &
                     "backcolorsub"C, MB_OK)

! Subclass the dialog by providing the address of the replacement dialog box
! procedure, MyDlgProc, while storing the address of the default procedure in variable
! hDlgProc held in module backcolorglobals.

	hDlgProc=SetWindowLongPtr(hdlg, DWL_DLGPROC, LOC(MyDlgProc))

The last line of code above saves the address of the original default dialog box procedure in variable hDlgProc, whilst supplying the address of the replacement "subclass procedure" as LOC(MyDlgProc). The above code can be found in file backcolor.F90.

Writing a Dialog Procedure

A dialog procedure is called by Windows to process messages directed to the dialog box.  It has a specific interface and, on IA-32 systems, must use the STDCALL calling mechanism.  A typical declaration of a dialog procedure is:

function MyDlgProc(hDlg, message, wParam, lParam)
!DEC$ ATTRIBUTES STDCALL :: MyDlgProc

USE IFWIN

implicit none

include 'resource.fd'	!Defines integer values for the IDs of the Dialog box and 
						!each of its controls

integer(SINT) MyDlgProc   ! Declare the function
integer(HANDLE) hDlg      !  Integer identifying the window handle of the dialog box
integer(UINT) message     !  Integer identifying the window message
integer(fWPARAM) wParam   !  message-specific information
integer(fLPARAM) lParam   !  message-specific information

The function itself takes four arguments.  The first is a handle to the dialog; this value must be passed to any routines that deal with the dialog.  The second is a value that identifies the kind of message this is.  The third and fourth arguments provide additional information about the message.

The !DEC$ ATTRIBUTES STDCALL directive tells the compiler that this routine should use the STDCALL calling convention on IA-32 architecture systems.  It also changes the default argument passing mechanism to be by-value and changes how the routine name is "decorated" for the linker.  On 64-bit systems, there is only one calling convention but other aspects of the STDCALL attribute still apply.

Module IFWIN is referenced to declare Win32 API routines, types and constants.  This module also declares a number of KIND values for variable declarations corresponding to the C "typedefs" used in the Microsoft documentation.  These definitions can be found in module IFWINTY, which is included as part of IFWIN.  The KIND constants are used to declare the kinds of the arguments.  In particular, note the use of HANDLE.  This will be 4 (for INTEGER(4)) on 32-bit systems and 8 (INTEGER(8)) on 64-bit systems, allowing this source to work on both 320bit and 64-bit platforms.

'resource.fd' is an INCLUDE file of Fortran constants corresponding to definitions in the resource file (which declares the dialog.)  As part of the project build, a tool called deftofd is run to convert the resource.h file created by the Microsoft Resource Compiler to Fortran.

The dialog procedure is placed in a module which is then used by the dialog box callback routine.  This allows its interface to be seen without having to write a separate interface block. This is in source MyDlgProc.f90

Which Messages to Intercept?

Just before a dialog control is to be drawn, the control, via Windows, sends a message to the dialog box with one of the following values:

The WM_ message values are all defined in module IFWINTY. (A handle is just an integer that the system assigns a window that permits it to be uniquely identified. A "device context" is a region in memory containing a bitmap matching the window dimensions in pixels on which the window can be drawn, together with information on the colours and styles of ‘brushes' and ‘pens' to be used to fill background and draw lines and text).

N.B. An edit box sends the WM_CTLCOLOREDIT message unless it is disabled or made read-only, in which case it sends a WM_CTLCOLORSTATIC message, so code to colour an edit box must be included to cover both these cases.

How to Intercept and Process the Required Messages

Dialog Box Background

The "message" argument supplied to the procedure is filtered using a SELECT CASE construction. So if you want to substitute one of your own colours for the background of a dialog box, then you must intercept the WM_CTLCOLORDLG message as follows:

select case (message)

! Dialog box drawing message - create  PURPLE background
    case (WM_CTLCOLORDLG)

		hdcControl=wparam
		hwndControl=lparam

		hbackbrush=CreateSolidBrush(RGB(255, 0, 255)) ! Create a PURPLE background brush
		hbkcolor=MSFWIN$SetBKColor(hdcControl,RGB(255, 0, 255))  ! Make the text background the same
!		ret=SetBkMode(hdcControl,TRANSPARENT)	!Alternative to prevent the text background appearing
		MyDlgProc=hbackbrush	! return the dialog box window background brush handle immediately	
		return

N.B. In order to make any text background the same as the window into which it is written, a call to the Windows API function SetBkColor, supplying the control handle and a colour for the background, will do this. However, the reason that a call is actually made to a function MSFWIN$SetBKColor, which takes two arguments, and not to a function with the name of the Windows API function SetBkColor is because the name SetBkColor has been given to a QUICKWIN function SETBKCOLOR that takes one argument, its interface being defined in module IFQWIN. Therefore, in order to avoid confusion, the new name MSFWIN$SetBKColor has been aliased to the standard Windows API function SetBkColor in module GDI32.

An alternative method is to make the text background transparent, which can be done using a call to the function SetBkMode. This is illustrated above but commented out. Its affect can be demonstrated by uncommenting the call to SetBkMode and commenting out the call to MSFWIN$SetBkColor, recompiling and executing the program.

The interface definition for function RGB, which constructs a 4-byte ColorRef value from 1-byte (0-255) Red, Green and Blue components, can be found in module IFWBASE.

Edit Box Background

If you want to substitute one of your own colours for the background of an edit box, then you must intercept the WM_CTLCOLOREDIT message (and possibly the WM_CTLCOLORSTATIC message, see below) and then identify to which edit box the message applies as follows:

    case (WM_CTLCOLOREDIT)

		hdcControl=wparam
		hwndControl=lparam
! Use hwndControl to identify the control

		If(hwndControl.eq.hwndedit1 ) Then

			hbackbrush=CreateSolidBrush(RGB(255, 0, 0)) ! Create a RED brush
! To prevent the text background from showing up, make it the same as the window background
			hbkcolor=MSFWIN$SetBKColor(hdcControl,RGB(255, 0, 0))  ! Make the text background RED
! To prevent the text background from showing up, an alternative is to make it transparent
! using a call to SetBkMode
!			ret=SetBkMode(hdcControl,TRANSPARENT)
			MyDlgProc=hbackbrush	! return the window background brush handle immediately	
			return
		Endif 

This code is found in file MyDlgProc.F90. The handle to the edit box window, hwndedit1, that identifies the particular control of interest in the code above, has been retrieved and saved earlier in the dialog call-back BackColorSub along with handles to all the other dialog box controls of interest.

You should note threethings about the above code:

1. The function return value is the handle to the brush that is to be used to fill in the edit control window's background colour and the value is returned immediately using the RETURN statement. If you comment out this RETURN statement, recompile and rerun the program, you will see that the chosen background colour does not appear in the edit box window.
2. The background for the text that is written into the edit box can be set to be the same as the window background using a separate call to a Windows API function SetBKColor. Otherwise the text appears in its own band of colour (default white) superimposed on the window background, as can be seen in the second edit box in figure 1. An alternative method is to make the text background transparent, which can be done using a call to the function SetBkMode which is shown commented out in the above code.
3. The code for colouring an edit box must be repeated for the case (WM_CTLCOLORSTATIC) section if the edit box is disabled or made read-only.

Static Text Background

If you want to substitute one of your own colours for the background of some static text, then you must intercept the WM_CTLCOLORSTATIC message, as follows:

    case (WM_CTLCOLORSTATIC)

	hdcControl=wparam		!Store handle to control's Device Context - needed when changing colours
	hwndControl=lparam		!Store handle to control's window - needed to identify the control
! Use hwndControl to identify the control

		If(hwndControl.eq.hwndedit1text ) Then

			hbackbrush=CreateSolidBrush(RGB(255, 0, 0)) ! Create a RED brush
			hbkcolor=MSFWIN$SetBKColor(hdcControl,RGB(255, 0, 0)) ! Make the text background RED
			MyDlgProc=hbackbrush	! return the window background brush handle immediately	
			return
		Endif 

		If(hwndControl.eq.hwndedit2text ) Then

			hbackbrush=CreateSolidBrush(RGB(0, 0, 255))	! Create a BLUE brush for the window background
			hbkcolor=MSFWIN$SetBKColor(hdcControl,RGB(0, 0, 255)) ! Make the text background BLUE
			htextcolor=MSFWIN$SetTextColor(hdcControl,RGB(255,255,0) ) ! Make the text YELLOW
			MyDlgProc=hbackbrush	! return the window background brush handle immediately
			return
		Endif
		 
		if(hwndControl.eq.hwndlist1text ) then

			hbackbrush=CreateSolidBrush(RGB(0, 255, 0)) ! Create a GREEN brush

			MyDlgProc=hbackbrush	! return the window background brush handle immediately
			return 
		endif
		
		if(hwndControl.eq.hwndscrollbar1text ) then

			hbackbrush=CreateSolidBrush(RGB(255, 255, 0)) ! Create a yellow brush
! To prevent the text background from showing up, an alternative is to make it transparent
! using a call to SetBkMode
			ret=SetBkMode(hdcControl,TRANSPARENT)
			MyDlgProc=hbackbrush ! return the window background brush handle immediately
			return 
		endif

! Make background to all other static text the same as the dialog background - PURPLE
			hbackbrush=CreateSolidBrush(RGB(255, 0, 255)) ! Create a PURPLE background brush
			hbkcolor=MSFWIN$SetBKColor(hdcControl,RGB(255, 0, 255))  ! Make the text background the same
			MyDlgProc=hbackbrush	! return the window background brush handle immediately	
			return

Note that the WM_CTLCOLORSTATIC messages that arrive for all static text windows that are not specifically identified and given their own If..Endif blocks of code are given the dialog box's window and text background colours by default, which in this case is Purple (RGB(255, 0, 255) ).

List Box Background

The control of the window and text background for a List box is essentially the same as for the edit box.

So if you want to substitute one of your own colours for the background of a List box, then you must intercept the WM_CTLCOLORLISTBOX message and identify to which List box the message applies using its pre-stored window handle, in this case hwndlist1, as its identifier. The following example, taken from MyDlgProc, will show what happens when the text background is not set and so not made the same as the list box window's background (see figure 1):

    case (WM_CTLCOLORLISTBOX)

		hdcControl=wparam
		hwndControl=lparam
! Use hwndControl to identify the control

		if(hwndControl.eq.hwndlist1 ) then

			hbackbrush=CreateSolidBrush(RGB(0, 255, 0)) ! Create a GREEN brush

			MyDlgProc=hbackbrush	! return the window background brush handle immediately
			return 
		endif
!If not one of my list boxes, pass the message on to the default window procedure
		MyDlgProc=CallWindowProc(hDlgProc, hDlg, message, wParam, lParam)

Passing on Messages to the Default Dialog Procedure

Note how, in the last list box example, there is an illustration of what you must do if the intercepted message is not handled by MyDlgProc: the message must be passed on to the default dialog procedure using a call to the Windows API function CallWindowProc. The address of the default dialog procedure is supplied as the integer handle hDlgProc, which was saved as described earlier when SetWindowLongPtr was used to replace it with MyDlgProc.

Running the Program

When executing, the program puts up the informative message box shown in figure 2 when the dialog call-back routine is entered, just before subclassing takes place. Code has been included to initialise the edit and list boxes with informative text. Otherwise, no extra code has been included for responding to changes made to edit box contents or scrollbar slide position. The user is encouraged to try adding code to set text background for the list box, the list box text and the scroll bar text and to see what the effect of omitting a RETURN statement after setting the MyDlgProc return value to a brush handle.

Figure 2: Informative message box displayed on initializing the dialog

Acknowledgements

I wish to give grateful thanks to all those forum members who have given unstinting advice to me over the years that it has taken me to gain some confidence using the Windows API in Fortran. I wish to especially thank Jugoslav Dujic, Paul Curtis and Steve Lionel. I have made much use of Jugoslav's XFLOGM modification to Intel (and Compaq) Visual Fortran's dialog support module in the past, especially his enhancements permitting the addition of context help. I should also mention that his XFLOGM also added capability to modify background colours using DLGSET, and this capability is also present in his XEFFORT package that he has developed over the years and released freely to the community (see WWW.XEFFORT.COM for details).