Kbase 21540: Behavior Change / Large Editor Widget In 8.3E & 9.1C11
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
15/10/2008 |
|
Status: Verified
FACT(s) (Environment):
Progress 8.X
Progress 9.X
SYMPTOM(s):
Search functionality in procedure editor does not work.
Behavior Change / Large Editor Widget In 8.3E & 9.1C11
Large Editor Widget
CAUSE:
In the past, Progress has used Version 1.0 of the Microsoft RichEdit control to implement the Large Editor widget. Progress now provides the option to use either Version 1.0 or a newer version (2.0 or 3.0, depending on which is available in the Windows system directory).
Users can specify the RichEdit version through an .INI file setting (see the Fix section below). However, using the newer versions of RichEdit introduced bugs in the following patches:
- 8.3D13
- 9.1C11
- 9.1C13 (there is no 9.1C12)
Users will be likely to encounter the bugs because these patches use the newer version of the RichEdit control as the default.
Progress 8.3E FCS also has the bugs, but does not use the newer RichEdit as a default, so the bugs will only show up if a user explicitly directs Progress to use it through the .INI file switch.
Patches subsequent to the ones listed above will default to RichEdit version 1.0 and will not have the bugs even when using the newer version; they may have the two behavior changes described at the end of this summary, however.
These are the bugs that RichEdit 2.0/3.0 causes in 8.3D13, 8.3E, 9.1C11, and 9.1C13. The bugs all stem from the fact that Windows text files usually use the Carriage Return/Linefeed combination to denote the end of a line, and, while RichEdit 1.0 counted each as a separate character, the newer versions of RichEdit count the combination as only a single character.
(Remember that the bugs only show up in 8.3E if you add the UseRichEdit10=no .INI setting described in the SOLUTION, whereas they'll show up in the others if there is no UseRichEdit10 setting at all because 2.0/3.0 is the default.)
1) The SEARCH and REPLACE methods do not work correctly. They will position the cursor in a location that is off by a number of characters equal to the number of lines between the beginning of the file and the place where the cursor should be.
2) The DELETE-LINE method deletes the first character, if WORD-WRAP=NO, or the first two characters, if WORD-WRAP=YES, of the next line.
3) The INSERT-FILE method incorrectly places the cursor after it inserts the file. The cursor is placed as many characters forward as there are linefeeds in the inserted file.
4) The SELECTION-TEXT attribute suffers from the same misplacing errors as those above. It returns the characters to the left of the selected text, off by the number of linefeeds from the beginning of the file to the selection.
5) The LENGTH attribute does not mesh with the CURSOR-OFFSET attribute. The LENGTH attribute will include all characters in the file and count each Carriage Return/Linefeed pair as 2, but the CURSOR-OFFSET of the last position in the file will be equal to the number of displayed characters plus the number of lines (each CR-LF counting as only one character).
In addition, these are behavior changes that are not necessarily bugs but may affect existing 4GL code:
1) The Large Editor's CURSOR-OFFSET attribute returns different values depending upon which version of RichEdit you use. With the newer versions, the value returned will typically be smaller than the value returned in 1.0, depending on how many lines there are between the beginning of the Editor widget's text and the cursor location.
2) Setting the CURSOR-OFFSET attribute may put the cursor farther along in the text when using RichEdit 2.0/3.0 than it would have in 1.0.
FIX:
If you observe this behavior change and need to rely on the older behavior, add the following line to the Startup section of your PROGRESS.INI file (or the registry):
- UseRichEdit10=yes