%eb with edit information

I am using %`eb with edit informations. Do I have to define the edit_info-array with type integer(kind=7) ? Ralf

The safest way is to use the TYPE edit_info that is defined in clearwin.ins and the corresponding module.

You can find further information in the document NotesOn64BitFtn95.txt and in FTN95.chm.

I tried to use the TYPE edit_info, but have still program crashes. See the following example:

Program Test_EditBox

 use eb_module

 integer :: winio@, iw, ierr  
 real*4  :: xyz(4)

  allocate(xyz_save(4),stat = ierr)
  xyz_save = 1.
  xyz = xyz_save

  iw = winio@ ('%pv%20.10`eb[read_only]&','*',0,info_eb)

  xyz = xyz_save

  iw = winio@ (' ')

 stop
end  

with module:

module eb_module      

  INCLUDE <clearwin.ins>
  TYPE(edit_info) info_eb

  real*4,ALLOCATABLE,DIMENSION(:)   :: xyz_save

end module eb_module      

When I debug this program, the values of array xyz_save are changed to 'Illegal Pointer' when the edit box is created

Paul,

I debugged my Problem once again and checked the edit_info-structure. The program runs fine, when I increase the size of the structure, by defining the last entry ('reserved') as an Array. I can see, that the first 8 items of the integer*2-array 'reserved' are changed when %eb is called. So I changed the type structure of edit_info to:

      TYPE edit_info
        SEQUENCE
        INTEGER*4 ::h_position
        INTEGER*4 ::v_position         
        INTEGER*4 ::last_line          
        INTEGER(7)::buffer             
        INTEGER*4 ::buffer_size        
        INTEGER*4 ::max_buffer_size    
        INTEGER(7)::current_position   
        INTEGER(7)::selection          
        INTEGER*4 ::n_selected         
        INTEGER*4 ::vk_key             
        INTEGER*4 ::vk_shift           
        INTEGER*4 ::active             
        INTEGER*4 ::modified           
        INTEGER*4 ::closing            
        INTEGER*4 ::n_chars_to_colour  
        INTEGER(7)::text_to_colour     
        INTEGER(7)::text_colours       
        INTEGER(7)::background_colours 
        INTEGER*4 ::modification_count 
        INTEGER*4 ::modification_flag  
        INTEGER*2 ::reserved(8)           
      END TYPE

and my program runs fine. The other items of edit_info seem to have reasonable values, but currently I am not using any of them.

I have not been able to reproduce your fault.

It is just possible that ClearWin+ has been changed so you could try using the new DLLs that you can download from here...

https://www.dropbox.com/s/eg8a7k9j4x9ysbt/newDLLs32.zip?dl=0

I don't get the crash but there does seem to be a fault in SDBG64 which sometimes gives a false error report for the array xyz_save.

I replaced the DLLs with the new ones but have still the same program crash (Access Violation), no matter if I compile it with /debug or not, or using sdbg64 or not. Funnily enough the contents of the 32byte that are written on info_eb%reserved is four times 'BAADF00D', when displaying it in hexadecimal. For completeness, here are my makefiles:

ftn95 /64 module_eb.f95
ftn95 /64 test_eb.f95
slink64 @lw

with lw: lo module_eb lo test_eb windows file Test_eb

I don't know, if it makes any difference, but my OS is Windows 10 Enterprice, Version 1709. Do you think that there may be any disadvantage, if I extend the type structure in the way I explained before?

There should be no problem when you increase the size of TYPE edit_info. It just has to be a block of memory large enough for the internal workings of ClearWin+.

If you want to access the information from your program then you will need to know the offset from the beginning of the structure to the information you need. Otherwise you could go back to using an integer array provided its size is increased to accommodate the new INTEGER*8 addresses.

There is no explicit reference to 'reserved' in the ClearWin+ code so at the moment the fault remains unexplained.

Hi Ralf, Paul,

Thank you for the information in the preceding posts. Thus I was able to transfer some %eb related code from 32-bit to 64-bit.

Testing the 32-bit program version after this modification, I detected serious trouble. The winio@ call with the %eb format code and the grave accent obviously writes to addresses behind the edit_info block address ending in incorrect results and unpredictable program execution.

Therefore I assume that Ralf's increase of the TYPE size is not only no disadvantage but really necessary. I suspect that at least 16 bytes are required for the last item of the structure. Therefore I changed my clearwin.ins file correspondingly.

All the previous posts date back to 2019. Meanwhile we are using version 8.80 of ftn95 but the clearwin.ins file still contains the old structure. Can we expect to receive an updated clearwin.ins together with the next ftn95 version or must the correction be repeated after any new update?

Thomas

I am not aware of any faults with the size of the EDIT_INFO TYPE and it is up-to-date in the current clearwin.ins and the corresponding modules. Here is the current entry...

      TYPE edit_info
        SEQUENCE
        INTEGER*4 ::h_position
        INTEGER*4 ::v_position         
        INTEGER*4 ::last_line          
        INTEGER(7)::buffer             
        INTEGER*4 ::buffer_size        
        INTEGER*4 ::max_buffer_size    
        INTEGER(7)::current_position   
        INTEGER(7)::selection          
        INTEGER*4 ::n_selected         
        INTEGER*4 ::vk_key             
        INTEGER*4 ::vk_shift           
        INTEGER*4 ::active             
        INTEGER*4 ::modified           
        INTEGER*4 ::closing            
        INTEGER*4 ::n_chars_to_colour  
        INTEGER(7)::text_to_colour     
        INTEGER(7)::text_colours       
        INTEGER(7)::background_colours 
        INTEGER*4 ::modification_count 
        INTEGER*4 ::modification_flag  
        INTEGER*2 ::reserved           
      END TYPE

Please send me sample code for any faults that you know about.

Paul,

it's always difficult to prepare a code example which reproduces the error but is not too complex. I could reduce the source code to 51 lines which were extracted from a significant larger application.

Program Test_EB
Implicit None
!include <clearwin.ins>
TYPE edit_info
     SEQUENCE
     INTEGER*4 ::h_position
     INTEGER*4 ::v_position
     INTEGER*4 ::last_line
     INTEGER(7)::buffer
     INTEGER*4 ::buffer_size
     INTEGER*4 ::max_buffer_size
     INTEGER(7)::current_position
     INTEGER(7)::selection
     INTEGER*4 ::n_selected
     INTEGER*4 ::vk_key
     INTEGER*4 ::vk_shift
     INTEGER*4 ::active
     INTEGER*4 ::modified
     INTEGER*4 ::closing
     INTEGER*4 ::n_chars_to_colour
     INTEGER(7)::text_to_colour
     INTEGER(7)::text_colours
     INTEGER(7)::background_colours
     INTEGER*4 ::modification_count
     INTEGER*4 ::modification_flag
     INTEGER*2 ::reserved!(8)
END TYPE

Integer, External      :: SE_Aus_Exit

Integer, Parameter     :: MaxBF = 100!00
Character (len=MaxBF)  :: BUFF
Integer                :: ANS
Double Precision       :: FAK_TS, TS
Type (Edit_Info)       :: EBINFO

ts     = 1.0d0
fak_ts = 1.0d0
buff   = '12345'

ANS = WINIO@ ('%ca['//' Ergebnisausgabe]&')
ANS = WINIO@ ('%ww[no_maxminbox,thin_border,maximise]&')
ANS = WINIO@ ('%mn[&Beenden]&',SE_Aus_Exit)
ANS = WINIO@ ('%24.5'//'`eb[vscrollbar,' // 'read_only]',BUFF,MAXBF,ebinfo)

End Program

Integer Function SE_Aus_Exit()
Implicit None
SE_Aus_Exit = 0
END

Analysis:

I compiled and linked with the 32-bit versions. The variable TS changes its value from 1.0 to 0.0 after the edit-box is closed, although TS is not invoked. I have the impression that the final winio@ call writes to ebinfo exceeding the allocated address space. Thus TS, probably with an address behind ebinfo, becomes modified. The error disappears if I remove the '!' in the last type item of edit_info, i.e. with

INTEGER*2 ::reserved(8)

instead of

INTEGER*2 ::reserved!(8)

This corresponds to a prior description of the parameter with an Integer array with size 24, where the last 6 array elements 19-24 a 'Reserved for future enhancements'. Two of them are now used. For the remaining 4 the necessary address space shall be provided.

Thomas

I don't get the same behaviour, for me the value of TS is not changed. But I don't recall any recent changes to ClearWin+ in this context that would make a difference.

As far as I know at the moment, the 'reserved' member is not used by ClearWin+ but it is quite possible that its size has an impact on the outcome.

In fact the size in the C language of the 'reserved' member (in clearwin.h) is char reserved[16] so (if only for compatibility) the Fortran should be something like INTEGER*2reserved(8) or CHARACTERreserved(16).

I will apply this correction for future releases of the standard header files and modules.

As you will probably know, you only need the grave accent on %eb when you need to access one or more of the members of the EDIT_INFO structure such as the 'modified' member. Otherwise you should omit the grave and avoid the user instance of EDIT_INFO.

Thank you for your support and advice,

We at Steinmueller are now using a modified version of clearwin.ins as work-around and expect the problem to be resolved with the next ftn95 release.

Possibly you can update the help instructions for the %eb format code, where the EDIT_INFO block is still declared as

INTEGER info(24)

Yes, we are aware of the optional grave accent requiring the EDIT_INFO structure as additional parameter. We use this very helpful and powerful option to check addresses (current_position, selection) and to determine if the buffer was modified. Unfortunately, when using the old structure in combination with /64 some parameters are shifted due to address length changes. Therefore it's advisable to make use of the new structure.

Thanks also to Ralf. Your forum post was very helpful for us.

OK. Will do.