View previous topic :: View next topic |
Author |
Message |
Ralf
Joined: 30 Aug 2007 Posts: 50 Location: munich
|
Posted: Wed Mar 13, 2019 7:40 am Post subject: %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 |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7928 Location: Salford, UK
|
Posted: Wed Mar 13, 2019 8:43 am Post subject: |
|
|
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. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
Ralf
Joined: 30 Aug 2007 Posts: 50 Location: munich
|
Posted: Wed Mar 13, 2019 5:04 pm Post subject: |
|
|
I tried to use the TYPE edit_info, but have still program crashes.
See the following example:
Code: | 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:
Code: | 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 |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
Ralf
Joined: 30 Aug 2007 Posts: 50 Location: munich
|
Posted: Tue Mar 19, 2019 8:17 am Post subject: |
|
|
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:
Code: | 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. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7928 Location: Salford, UK
|
Posted: Tue Mar 19, 2019 2:37 pm Post subject: |
|
|
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. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
Ralf
Joined: 30 Aug 2007 Posts: 50 Location: munich
|
Posted: Wed Mar 20, 2019 7:47 am Post subject: |
|
|
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:
Code: | ftn95 /64 module_eb.f95
ftn95 /64 test_eb.f95
slink64 @lw |
with lw: Code: | lo module_eb
lo test_eb
windows
file Test_eb |
|
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
Ralf
Joined: 30 Aug 2007 Posts: 50 Location: munich
|
Posted: Wed Mar 20, 2019 7:55 am Post subject: |
|
|
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? |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7928 Location: Salford, UK
|
Posted: Wed Mar 20, 2019 8:18 am Post subject: |
|
|
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. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
Thomas
Joined: 18 Feb 2005 Posts: 56 Location: Gummersbach, Germany
|
Posted: Mon Mar 21, 2022 12:24 pm Post subject: Type structure of edit_info |
|
|
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 |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7928 Location: Salford, UK
|
Posted: Mon Mar 21, 2022 1:39 pm Post subject: |
|
|
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...
Code: | 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. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
Thomas
Joined: 18 Feb 2005 Posts: 56 Location: Gummersbach, Germany
|
Posted: Mon Mar 21, 2022 5:41 pm Post subject: Code sample with %eb |
|
|
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.
Code: |
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
Code: |
INTEGER*2 ::reserved(8)
|
instead of
Code: |
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 |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7928 Location: Salford, UK
|
Posted: Tue Mar 22, 2022 10:56 am Post subject: |
|
|
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*2::reserved(8) or CHARACTER::reserved(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. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
Thomas
Joined: 18 Feb 2005 Posts: 56 Location: Gummersbach, Germany
|
Posted: Wed Mar 23, 2022 1:09 pm Post subject: Edit_Info type for %eb |
|
|
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
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. _________________ Thomas |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7928 Location: Salford, UK
|
Posted: Wed Mar 23, 2022 5:31 pm Post subject: |
|
|
OK. Will do. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
|