Unstable %eb behaviour with user_colours in FTN 8

I'm having problems with a multi-line edit box when compiling with FTN 8.1 that did not occur with previous versions. When using a %eb edit box with user_colours and a callback, if I attempt to scroll the box using the vertical scrollbar thumb text within the box is selected, and the text display flickers, sometimes corrupts and also the application can cash. A similar thing happens if I attempt to select a block of text using mouse click and drag. This was all working fine up to FTN 8 (compiling as x86 code in Windows 10)

Here's some demo code:

! Demonstrates problem with combination of user_colour edit box and use of
! CLEARWIN_STRING@('CALLBACK_REASON'). Scrolling the box causes strange behaviour
! and attempting to select text and scroll with mouse causes similar behaviour
! and intermittent crashing. Removal of user_colour or CLEARWIN_STRING@ from
! callback fixes the behaviour
winapp

! Info block for edit box
module TestMod
  integer*4 info(24), &
            eb_h_position, eb_v_position, eb_last_line, &
            eb_buffer, eb_buffer_size,  eb_max_buffer_size, &
            eb_current_position, eb_selection, eb_selected, &
            eb_vk_key, eb_vk_shift,  eb_active, &
            eb_modified, eb_closing, eb_n_chars_to_colour, &
            eb_text_to_colour, eb_text_colours, eb_background_colours, &
            eb_reserved(6)
  equivalence &
    (eb_h_position, info(1)), (eb_v_position, info(2)), &
    (eb_last_line, info(3)), (eb_buffer, info(4)), &
    (eb_buffer_size, info(5)), (eb_max_buffer_size, info(6)), &
    (eb_current_position,info(7)), (eb_selection, info(8)), &
    (eb_selected, info(9)), (eb_vk_key, info(10)), &
    (eb_vk_shift, info(11)), (eb_active, info(12)), &
    (eb_modified, info(13)), (eb_closing, info(14)), &
    (eb_n_chars_to_colour, info(15)), (eb_text_to_colour, info(16)), &
    (eb_text_colours, info(17)), (eb_background_colours, info(18)), &
    (eb_reserved, info(19))
end module TestMod

use mswin
use TestMod

external StartCB
external EbCtrlCB

i = winio@('%ww[no_border,independent,not_fixed_size]&')
i = winio@('%ca[FTN Test]%nd&')
i = winio@('%sc&',StartCB)
i = winio@('%pv%100.60^`eb[read_only,hscrollbar,vscrollbar,user_colours]','*',0,info,EbCtrlCB)

end

! Setup some text in the EB on window startup
integer function StartCB()
  use mswin
  use TestMod

  integer:: i
  do i = 1, 200
    call AppendLine('(eb_h_position, info(1)), (eb_v_position, info(2)), (eb_last_line, info(3)),'// &
                    '(eb_buffer, info(4)),  (eb_buffer_size, info(5)), (eb_max_buffer_size, info(6))')
  end do
  StartCB = 2
end function StartCB

! eb CB handler
integer function EbCtrlCB()
  use mswin
  character*32 rstr
  rstr = CLEARWIN_STRING@('CALLBACK_REASON')  ! presence of this call along with user_colours causes redraw problems during thumb scroll and click-drag text selection scrolling
  EbCtrlCB = 0
end function EbCtrlCB

! Append new line to eb
subroutine AppendLine(instring)
  use mswin
  use TestMod
  character(len=*), intent(in):: instring
  call EDIT_MOVE_BOF@(info)
  call INSERT_EDIT_STRING@(info, instring(1:LEN_TRIM(instring))//char(13)//char(10))
end subroutine AppendLine

I should also mention this is on a high dpi display, although adding SetDpiAwareness@(0) make no difference.

Alan

I have made a note that this needs investigating.

I have tested this code and it works OK for me for Win32. I am using v8.2 of FTN95 and the corresponding ClearWin+ library. However, I don't know of any relevant changes in ClearWin+ since this thread was started.

The Fortran code presented above has not be adapted for 64 bit compilation. As it is, it doesn't run well under 64 bits but that is not surprising since there are important changes that must be made to the code for a 64 bit executable.

Unfortunately this is still a problem with 8.2. On further investigation it appears to occur only on certain mouse hardware (in my case a Logitech G602), with or without specific mouse drivers. It's repeated on different OSes (Win 8.1 and 10 at least) and PCs and even happens when the test program is run on a different PC via Remote Desktop. The behaviour is the same in all cases, scrolling up and down using a mouse on the vertical thumb causes random left/right scrolling, selection of text, flickering and eventually a crash. The crash doesn't always occur in the same place within salflibc.dll although it looks like it is generally related to the WM_MOUSEMOVE event handler. Using a different mouse doesn't cause the same problem (even with the G602 plugged in at the same time).

The G602 is a gaming mouse so maybe it's in some way related to a higher frequency of mouse events? MS Spy++ shows an awfully large number of WM_MOUSEMOVES and WM_TIMER events being fired. I've not come across anything similar in Windows or any other apps using this mouse.

This isn't a problem when compiled under compiler versions prior to 8.00 so it looks like some interaction between the data from the mouse and a change in ClearWin+ between 7.2 and 8.0.

If there is any more info or testing I can do (or a version of salflib with debug symbols maybe?) let me know.

Thanks, Alan

Alan

At the moment I am not able to reproduce the problem.

Can you confirm

1. you are using the Win32 platform and not x64 (64 bits)
2. the problem only occurs when using [user_colours]
3. the problem only occurs when %eb has a callback.

Paul,

1. Yes, Win32 compilier, running on Windows 10, 8.1 and 7 x64
2. Yes, delete user_colours and its fine
3. Yes, actually it is only the combination of user_colours and a call to CLEARWIN_STRING@('CALLBACK_REASON') within the CB. Just commenting out the function call in the fixes it.

I have just found another system with the problem with lots of different mice. This is an old iMac with Windows 7 x64 BootCamp and various different wired MS mice. It crashes almost immediately with a ClearWin Access Violation stack trace:

Access Violation
The instruction at address 1004760f attempted to read from location 00000004

 1004741d locate_mouse(<ptr>structÄedit_buffer,int,int)#70 [+01f2]
 10047c90 edit_procedure@16 [+08e5]
 749662fa routine at address 749662FA [+0000]
 74966d3a routine at address 74966D3A [+0000]
 749677c4 routine at address 749677C4 [+0000]
 7496788a routine at address 7496788A [+0000]
 7498d31e routine at address 7498D31E [+0000]
 749830a9 routine at address 749830A9 [+0000]

eax=018a0038   ebx=03811c20   ecx=00000000
edx=00000010   esi=03812e08   edi=03811c20
ebp=03609d68   esp=03609d24   IOPL=1
ds=002b   es=002b   fs=0053
gs=002b   cs=0023   ss=002b
flgs=00010246 [NC EP ZR SN DN NV]

 1004760f  mov      eax,[ecx+0x4] 
 10047612  mov      [ebp-0x20],eax 
 10047615  mov      edi,[ecx+0x8] 

This is an old Core2 system so looks like it might be related system performance vs the rate at which the CB is fired maybe.

Try a different return value for EbCtrlCB.

You are currently using 0 as the return value.

I had to change my callback return value from a 1 to a 2 to get a list view control to work without flickering while I navigated around the box, selected rows, etc.

Using the above traceback, I have made a guess at the likely cause of failure and applied a fix. This should prevent the crash but may not remove the flicker etc..

The fix will be in the next release of the DLLs.

Quoted from wahorger I had to change my callback return value from a 1 to a 2

When I started coding clearwin+ I used callback values of 0 or 1. Where is the documentation of providing other values ? It looks like I will have to review my old code to update ?

It's a bit of a worry that my clearwin+ coding is becoming obsolete !

John

Unfortunately the callback return values don't fix the problem - %eb has specific CB return requirements and it's more than just redraw flicker really as I get random apparent mouse clicks, text selection and other fun stuff!

Paul, that sounds promising, when do you think you'll release the updated DLLs? If you want me to have a quick go then I'm happy to test something out if it will help.

John - to add some more callback excitement, in the case of %eb the value of 0 should be returned if the callback doesn't handle the response to control keys (Delete, Backspace etc.) so not the same as the general behaviour which would be to close the window.

Alan

Normally I would release intermim DLLs quite quickly but we probably need to wait till most of our users are up to date with version 8.2 of FTN95.