Problem with SendMessage

Using SendMessage I want to send a click to my graphics Window using

    C_EXTERNAL SENDMESSAGE 'SendMessage' (VAL,VAL,VAL,VAL) : INTEGER*4
::
::
  CALL SendMessage ( GR_HANDLE, WM_LBUTTONDOWN, MK_LBUTTON, 10 + ISHFT(10, 16) )

Compilation provides: Compiling file: DrawOnScreen.f90 D:\Bgo_7.2\Replo\DrawOnScreen.F90(42) : error 904 - Return type is expected. Found (VAL,VAL,VAL,VAL):INTEGER*4 Compilation failed. What's wrong?

You are calling a FUNCTION subprogram as if it were a SUBROUTINE. The call does not match the interface. You could do something similar to

integer :: iret
...
iret = SendMessage(...)
...

The interface for SendMessage is provided in win32api.ins as

      STDCALL SENDMESSAGE 'SendMessageA' (VAL,VAL,VAL,VAL):INTEGER(7)

Notice the A at the end of SendMessageA.

According to the definitions in

\Program Files (x86)\Silverfrost\FTN95\include\WINDOWS.F90 or \Program Files (x86)\Silverfrost\FTN95\include\WINDF95.INS

the C_EXTERNAL definition should be ok.

I tried at first that what you recommend and I got

Compiling file: DrawOnScreen.f90 D:\Bgo_7.2\Replo\DrawOnScreen.F90(42) : error 904 - Return type is expected. Found (VAL,VAL,VAL,VAL):INTEGER*4 D:\Bgo_7.2\Replo\DrawOnScreen.F90(1218) : error 645 - SENDMESSAGE is a SUBROUTINE so cannot be used as a FUNCTION Compilation failed.

Paul, I tried that as well earlier, but using:

INCLUDE  <clearwin.ins>
INCLUDE  <win32api.ins>
INCLUDE  <win32prm.ins>

:: INTEGER*8 iResult :: STDCALL SENDMESSAGE 'SendMessageA' (VAL,VAL,VAL,VAL) : INTEGER(7) :: iResult = SendMessage ( GR_HANDLE, WM_LBUTTONDOWN, MK_LBUTTON, 10 + ISHFT(10, 16) )

provides:

Compiling file: DrawOnScreen.f90 D:\Bgo_7.2\Replo\DrawOnScreen.F90(43) : error 904 - Return type is expected. Found (VAL,VAL,VAL,VAL):INTEGER(7) D:\Bgo_7.2\Replo\DrawOnScreen.F90(1219) : error 645 - SENDMESSAGE is a SUBROUTINE so cannot be used as a FUNCTION Compilation failed.

There is no STDCALL for 64 bits but FTN95 allows it. STDCALL is needed for 32 bits.

      STDCALL SENDMESSAGE 'SendMessageA' (VAL,VAL,VAL,VAL):INTEGER(7)
      INTEGER(7) hwnd,lparam,wparam,ans
      INTEGER msg
      INTEGER,PARAMETER::WM_LBUTTONDOWN = Z'201'
      INTEGER,PARAMETER::MK_LBUTTON=Z'1'
      hwnd   = 0 !Your value for hwnd
      msg    = WM_LBUTTONDOWN
      wparam = MK_LBUTTON
      lparam = 0 !Your value for lparam
      ans = SendMessage(hwnd, msg, wparam, lparam)
      END

    INCLUDE  <clearwin.ins>
    INCLUDE  <win32api.ins>
    INCLUDE  <win32prm.ins>
::
    STDCALL    SENDMESSAGE 'SendMessageA' (VAL,VAL,VAL,VAL) : INTEGER(7)
       INTEGER(7) lparam, wparam, iResult 
       INTEGER    msg
       INTEGER, PARAMETER :: WM_LBUTTONDOWN = Z'201' 
       INTEGER, PARAMETER :: MK_LBUTTON = Z'1' 
::
       msg     = WM_LBUTTONDOWN
       wparam  = MK_LBUTTON
       lparam  = 10 + ISHFT(10, 16)
       iResult = SendMessage ( GR_HANDLE, msg, wparam, lparam )

:: Compiling file: DrawOnScreen.f90 D:\Bgo_7.2\Replo\DrawOnScreen.F90(43) : error 904 - Return type is expected. Found (VAL,VAL,VAL,VAL):INTEGER(7) D:\Bgo_7.2\Replo\DrawOnScreen.F90(46) : error 1011 - WM_LBUTTONDOWN has already been declared with the PARAMETER attribute D:\Bgo_7.2\Replo\DrawOnScreen.F90(46) : warning 520 - WM_LBUTTONDOWN has been declared more than once with the same type (see line 2420) D:\Bgo_7.2\Replo\DrawOnScreen.F90(47) : error 1011 - MK_LBUTTON has already been declared with the PARAMETER attribute D:\Bgo_7.2\Replo\DrawOnScreen.F90(47) : warning 520 - MK_LBUTTON has been declared more than once with the same type (see line 1286) D:\Bgo_7.2\Replo\DrawOnScreen.F90(1226) : error 645 - SENDMESSAGE is a SUBROUTINE so cannot be used as a FUNCTION Compilation failed.

next trial with:

    STDCALL    SENDMESSAGE 'SendMessageA' (VAL,VAL,VAL,VAL) : INTEGER(7)
       INTEGER(7) lparam, wparam, iResult 
       INTEGER    msg
!!!       INTEGER, PARAMETER :: WM_LBUTTONDOWN = Z'201' 
!!!       INTEGER, PARAMETER :: MK_LBUTTON = Z'1' 

:: Compiling file: DrawOnScreen.f90 D:\Bgo_7.2\Replo\DrawOnScreen.F90(43) : error 904 - Return type is expected. Found (VAL,VAL,VAL,VAL):INTEGER(7) D:\Bgo_7.2\Replo\DrawOnScreen.F90(1226) : error 645 - SENDMESSAGE is a SUBROUTINE so cannot be used as a FUNCTION Compilation failed.

There are several problems with your posted pieces of code, as well as with your posting style.

1. When you post only a code fragment, and then display error messages issued by the compiler, it is difficult to associate the line numbers in the error messages with the code fragments.

2. I don't see why you are giving duplicate nonstandard declarations for the Windows API functions, once in an included .INS file and again in your code. For instance, SendMessage is declared in win32api.ins and again in your code.

3. Do you really have source lines with '::' in columns 1 and 2? What for, and are your sources fixed or free form?

I will make a note to investigate if the error report in this context can be improved.

'error 904 - Return type is expected' appears because the interface for SENDMESSAGE has already been provided (in the INCLUDE file).

Thanks, Paul and sorry: I was not aware that the definition is as well in win32api.ins. I had found it in MSWINMOD.F90 and WINDOWS.F90.

The problem I have is: In my with %pl and %mg created graphics window I cannot zoom in or out unless I did a left mouse click into the graphics window. To overcome this I tried to send a left-click (button down / button up) to that window after creation but it did not help.

My earlier 32-bit version does not have this problem. Any idea?

Try calling the Windows API function SetFocus using the HWND of the %pl control.

it did not help

The only other suggestion I have is to try calling SetFocus using the HWND of the main Window (from %hw).

no success. I have to get it running without this stupid first left-click.

There seems to be anything wrong with

INCLUDE <clearwin.ins> INCLUDE <win32api.ins> INCLUDE <win32prm.ins>

I changed everything back to INCLUDE <windows.ins> Now my program works fine without any SendMessage or left-click to start.

It's good that it is now working for you although it can't have anything to do with the INCLUDE files.

I was going to suggest that you try using %if. This causes the following control to have the initial focus when the Window is opened.

A problem that appears 'out of the blue' and then disappears, equally mysteriously, after a fresh recompile is a difficult one to track down, and wastes a lot of time looking for the reason, which may never be found. From my own experience, there are at least a couple of causes that are worth checking against.

One is the use of a variable that has not been properly initialised - but it needs to be one that isn't very important, or the error may be experienced after a recompile. Another reason is when you link in a superseded version of one or more routines, usually by accident and a misspelling of a path.

However, the one that really got me some years ago and led to me writing a post entitled 'When is a handle not a handle' was a misunderstanding of what a handle is when applied to a Clearwin+ graphics area. For most controls in a Windows application that have a handle, this is allocated by Windows, and CW+ simply reports it back. CW+ graphics areas need to be provided with a handle - or did. This applies to %gr and %pl. If you assume, wrongly, that a handle is passed back, then you will get anything that resides in the handle variable when the program runs. Needless to say, this makes moving between graphics areas quite difficult, as in some cases they may even have the same value for the handle.

Paul did some work on this (see items 407 and 408 in cwplus.enh) but my bet is on this as a cause. To get a handle passed back you need to give the option [handle]. But it never hurts to assign the user-supplied handle and work that way.

Eddie

The original error message described at the start of this thread has now been changed. In future you will get a warning that the routine has already been declared.