Question on Derived Type

[Paul_Curtis]

This has now been modified in IVF 8.1.021:

Code:

TYPE T_TVINSERTSTRUCT
SEQUENCE
 integer(HANDLE) hParent !HTREEITEM
 integer(HANDLE) hInsertAfter !HTREEITEM
 STRUCTURE /fDUMMYUNIONNAME/ DUMMYUNIONNAME
    UNION
    MAP
      TYPE (T_TVITEM) item
    END MAP
    MAP
      TYPE (T_TVITEMEX) itemex
    END MAP
    END UNION
 END STRUCTURE
END TYPE 

So I had code with

TYPE(TVI_INSTERTSTRUCT) :: tvis

TYPE(TVI_ITEM), POINTER :: tvi

tvi => tvis%item

which worked fine with v19, butcrashes in v21(no such component), and the assocation now has to be modified as follows:

tvi => tvis%dummyunionname%item

This works, but no longer looks like a proper Win32 data type. I really see no reason why the extra naming should be required in order simply to access Win32 items from fortran.

Why does aMAPrequire a surroundingunion within a named structure, to be included in a derived type?CVF was very loose on this point, andallowed UNIONs to be contained directly within derived types, without requiring STRUCTUREs at all. This seemed to follow the suggestion that STRUCTURE should be deprecated in favor of derived types.

TIA for any comments

[Paul_Curtis]

The forum editor ate part of my post; the first part showed the original structure of this type in v8.1.019:

Code:

 TYPE T_TVINSERTSTRUCT
  SEQUENCE
  integer(HANDLE) hParent !HTREEITEM
  integer(HANDLE) hInsertAfter !HTREEITEM
  TYPE (T_TVITEM) item
 END TYPE

This has been changed in v21 (see original post)

[Steven_L_Intel1]

The former definition of this type was wrong - it failed to include the field that was added in NT4.

However, as you note, the enclosing STRUCTURE is not required here and its presence requires source changes. I will report this to the RTL team and ask that they remove the errant STRUCTURE - ifort can handle this just fine. Of course, that will mean that you have to change the code back...

[Paul_Curtis]

Steve, thanks for the reply. The issue with my (and anyone else's) Win32 calls is not that the code needs to be "changed back", but rather that with the correct F90 Win32 interfaces,the code need not be changed at all, and will continue to "look correct" in the standard Win32 sense, as well as function.

Perhaps your RTL group might eliminate all such instances of superfluous STRUCTUREs within Win32 types.

[Steven_L_Intel1]

I'm not entirely sure of what you just said. If the RTL group had added the UNION in the proper manner, then indeed you would not have noticed and people who wanted to use the itemex field could have. I've let them know that they should watch out for that in the future.

Please name some specific types that you think shouldn't have nested structures. Sometimes it is necessary.