We have a modification of that scenario: we implemented one more function, say F_TIM, which will be executed, if the user hits a push button (format code "%bt"). F_TIM contains a while loop which retrieves and prints out the mouse position. The while loop may be left by depressing the right button of the mouse.

Why use while loop for getting the mouse info? It will effectively block the rest of the program as the loop runs.

We are aware of being able to process mouse button events in %gr callback and we have tried to state that this works (for 32 bit and 64 bit) in our previous post.

However, we try to port a big existing application from 32 bit to 64 bit. This application has been designed using the scenario with function F_TIM described in the previous post and which does not behave in the same way for 64 bit as under 32 bit. We would try to change as less as possible in the port and that's why we tried to use the F_TIM scenario which works under Salford (32 bit) to our satisfaction.

I'm astonished that the function works anywhere outside of a %gr or %dw area, because when I read FTN95.CHM it clearly states "To obtain the position of the mouse, the mouse buttons, and the keyboard shift keys at the time when the last owner-draw (%^dw) or graphics region (%^gr) call-back function was called." and "This routine should be called immediately on entry to the call-back function. It does not make sense to call this function in other contexts. "

There is a certain obviousness that the function is tied to a %gr or %dw by the origin of coordinates, and any %bt is certainly external to a graphics area.

Hence Jalih's suggestion relates to the way that Clearwin+ seems to be intended to work.

No doubt the button could be triggered by a key press while the mouse pointer remains in the %gr area, but whether triggered by a key press or a mouse click, the %gr has lost the focus. While you are in the callback for the button, the %gr region cannot reclaim the focus. As a result, I repeat that I am surprised that your approach works in 32 bit FTN95 mode

If I was programming your application, I might put a popup menu in the %gr region with options for "start mouse tracking" and "stop mouse tracking", and keep GET_MOUSE_INFO@ entirely within the graphics callback.

However, we try to port a big existing application from 32 bit to 64 bit. This application has been designed using the scenario with function F_TIM described in the previous post and which does not behave in the same way for 64 bit as under 32 bit. We would try to change as less as possible in the port and that's why we tried to use the F_TIM scenario which works under Salford (32 bit) to our satisfaction.

I previously mentioned, that your do while loop is taking up the cpu and blocking the handling of window messages in the application.

Add a call to TEMPORARY_YIELD@() function at the bottom of the do while loop and it should probably work.

Thanks to all who helped in this topic, especially to Jalih. Jalih's information to call TEMPORARY_YIELD@() function at the end of the while loop was right and made our test application also work for 64 bit as we expected (and this for ifort and gFortran).

Although our proceeding might not be the correct one, we would use it since it seems to work and thus we do not have to do so many code changes.

Also besides call temporary_yield@ look at simultaneous use of PERMIT_ANOTHER_callback, might be very helpful for complex GUI.
You can call it many times, i do not know the limit, never had any problems with that

A Fortran/Clearwin application ported from 32 bit to 64 bit makes use of the calls

A=WINIO@('%hw&',IHDLW1)
A=WINIO@('%lw',LHDLW1)

(in sequence). The output value for IHDLW1 is 0 for both the 32 and the 64 bit application (where the names WINIO@ have been mapped to WINIO$ for the 64 bit version). However, the output value for LHDLW1 is -1 for the 32 bit application and 0 for the 64 bit application. IHDLW1 and LHDLW1 are of type integer*4. The winio@ calls mentioned above are preceded by other winio@ calls of the form

A=WINIO@(<format code ending with &>,...)

The 64 bit application has been built with the Intel Fortran Compile environment (compiler ifort.exe) and is linked against the ClearWin+ 64 bit dll.