Handles?

ALL handles have to be 8 byte long ?

What about openr@, readr@, closer@, doserr@, ... ?

Erwin

Only Windows handles are 64 bit integers for 64 bit applications. The ones listed are still as they were (mostly 16 bit integers).

It would make life easier, if ' INTEGER(KIND=CW_HANDLE) :: Name ' would be accetped as well from FTN95 32-bit version.

CW_HANDLE is an integer parameter with the value 7. It is declared in an INCLUDE file such as clearwin.ins or in an equivalent module. It should work OK in 32 bit mode if these are up-to-date.

FTN95/Win32 Ver. 8.00.0

MODULE MsgWin IMPLICIT NONE INTEGER(KIND=CW_HANDLE) :: MessageWindow END MODULE MsgWin

error 172 - Constant expression expected

The compiler does not understand CW_HANDLE. It must be defined either directly or via an INCLUDE statement or a USE statement. For example...

INCLUDE <clearwin.ins>

or an equivalent USE statement.

Paul,

if FTN95 would know CW_HANDLE it would make life easier. In non of my MODULEs I have any INCLUDE or USE file. iFort allows INTEGER(HANDLE) :: ...

I have a lot of problems to decide which variables are handles in your sense and should be int*8. I have handles for windows, buttons, property pages (%ps), fonts, pipes, graphic areas, ... Many CLearWin formats have a 'ctrl'. I found as well 'ctrl is a handle ...' ???

Could you provide a list for int*8 handles?

Erwin

Erwin

Perhaps it would be simpler for you to use the value 7 directly in your code.

INTEGER(7) is required for 'Windows' handles provided by the Microsoft Windows API. These are effectively identifiers for Windows controls and dialog boxes. Examples are %hw, %lc and routines such as GET_WINDOW_LOCATION@.

INTEGER(3) is used for 'handles' that are internal to ClearWin+. For example %lw, %sh, %gr and routines such as SELECT_GRAPHICS_OBJECT@.

The plan is to change the documentation and to use something other than 'handle' for ClearWin+ handles. In the mean time, if in doubt, please ask.

Paul, unfortunately it's not enough to say 'Examples are ...'. I would like to know precisely where I have to use integer*8.

Therefore I extracted all (67) format codes in use from my source code (~90.000 lines) and sorted. For most of them there is no question. Attached a list with open points. Please complete it.

%bm  draw a bitmap                 >>> handle
%bt  insert standard button        >>> ctrl
%cw  insert ClearWin window        >>> handle
%fh  use a Windows API font        >>> handle
%ga  gang radio buttons            >>> ???
%gr  drawing surface               >>> handle   int(3)
%hw  handle of current window      >>> handle   int(7)
%ib  image button                  >>> ctrl
%lc  handle of previous control    >>> handle   int(7)
%lw  return and leave window open  >>> ctrl     int(3)
%mi  caption icon                  >>> handle
%ps  property sheet                >>> sheet ID
%rb  radio button                  >>> ctrl
%sh  create property sheet         >>> sheet ID int(3)
%th  tooltip help                  >>> ctrl
%og  OpenGL graphics region (only win32 ???)

The same questions will arise with the ClearWin functions in use. I hope you can give a list of all functions dealing with integer*8 values!

Furthermore I would like to see a.s.a.p. updated document files where you use e.g. the word 'handle' only for int*8 handles and otherwise 'ctrl'. As we see above in %gr and %hw it's not yet consistent.

I would like to remind you as well to my suggestion to remove all gFortran hints from the standard documentation.

(Up to now I did not yet get any of my 31 programs containing ClearWin elements running under Fortran 64.)

Erwin

Defining all potential 'handles' as INTEGER8 is probably the safest approach, as you then provide 8 bytes to store the information being used. As the windows handles are typically only transferred between routines, and not used locally, this does not cause a problem. For clearwin+ controls, that are integer2 or integer4, providing an integer8 defined value also works.

The only error occurs if returning an integer8 value to an integer2 or integer*4 variable.

I use this approach successfully for %`^gr, %hw and create_graphics_region@, while they may not all be I(7) windows handles. This approach should be robust. If you are not sure, you could initialise the handles first.

John

Here is my list of format codes that use an integer(7) handle...

Format codes that output a Microsoft integer(7) handle...

%hw handle of current window %lc handle of previous control %`cw insert ClearWin window

Format code that require a Microsoft integer(7) handle as input...

%fh use a Windows API font %bm draw a bitmap %dw owner draw graphics %mi caption icon %nw new window

This list is intended to be exhaustive so if I have left anything out then please let me know.

Library routines that return an integer(7) handle always do so via the function name. The Silverfrost standard INCLUDE files clearwin.ins and win32api.ins use integer(7) function return values where appropriate, so these INCLUDE files can be used to determine how the return value should be stored.

Paul,

clearwin.ins does with

      C_EXTERNAL GET_WINDOW_LOCATION@ '__get_window_location' (VAL,REF, REF,REF,REF)

give not any hint that the first VAL should be integer*8

Your hint is insufficient Erwin

Erwin

The first argument for GET_WINDOW_LOCATION@ is an input value. Typically it would be a value returned via %hw or %lc. You only need to know the type for returned values so you will know how to store them in your program.

Paul, here we have call by value. Is this the case for all ClearWin functions? What about ClearWin subroutines? Don't the apply integer*8 values at all? Erwin

Erwin

I am not sure that I understand your question. ClearWin+ routines use a mix of VAL and REF arguments but this does not mean much in this context.

A VAL must be used for input but a REF can be used for input or output or both input and output.

Internally within FTN95, all arguments are REF but VAL is available when calling external routines.

Paul, my thought is that VAL allows int4 or int8 intput regardless what inside the function is used, while REF parameters should have the correct type. Correct? As a result we should have correct type for ClearWin functions and subroutines. Erwin

It is not always necessary but always advisable to match the types of VAL dummy arguments with VAL actual arguments. The same is true for REF arguments.

If you know, for example, that the first argument of GET_WINDOW_LOCATION@ is a Microsoft HWND handle and that the value returned when using %hw is a Microsoft HWND handle then you know that the returned integer(7) value should be used as input for GET_WINDOW_LOCATION@.

Paul, it's frustating, now we are at the starting point again: Please provide a list of subroutines an functions which are changed and have now integer8 parameters or results! For function results in can be extracted BY YOU from the include files. This is YOUR job. You cannot expect that every user has to find out with trial and error by himself where to use int8. For subroutine parameters I did not find any hint. I'm paying since about 20 years for maintenance, and I expect, that you do your maintenance! Without documentation I cannot do serious software developments. Erwin

Erwin

I agree. I am also frustrated that I have not managed to explain that all the necessary information is already available. However I will pass on your request.

Thank you, Paul, where can I find the information - or can you send it by email? Erwin