On 3/26/2014 10:50 AM, Jeff Young wrote:
RDi 9.0.0
I have a large number of source members that have a Hex attribute character
(usually x'22' in column 5 of the source member for when SEU was the
primary source editor being used.
In RDp 8.5, this showed as a reverse image square in column 5 and the rest
of the source line being displayed properly.
In RDi 9, the source line is shifted one column to the left, and no
indication that the line has a special character in column 5.
Is this an Eclipse change or did something change in the LPEX editor?
I tend to think of RDi as 'a program' but really, it is an interlocking
ecosystem of Rational plugins, Eclipse base functionality and the
ever-changing Windows universe featuring DLL hell. If I had some spare
time, I'd be very interested in sussing out which parts of the ecosystem
contribute which behaviour.
I scrounged a bit of free time this morning, and did some poking. I
came close, but not close enough.
I opened a source member with these embedded non-display characters
(EBCDIC X'22' and friends). By hovering the mouse over the editor tab,
I could see the full path to the cached file on my PC. Using Notepad++
and the Hex Editor plugin from
http://sourceforge.net/projects/npp-plugins/?source=dlp I looked at the
ASCII value of the non-display characters.
Wht is x'c282'
Red is x'c288'
Pnk is x'c298'
Trq is x'c29a'
Ylw is x'16'
LPEX allows displaying whitespace characters (Preferences > LPEX Editor
Appearance > Whitespace Characters) as well as /defining/ what
'whitespace characters' might be.
It turns out that specifying my own hex value for the 'Whitespace
Character' is disallowed. Specifically, if I put 0XC282 in the
Whitespace Hex Value' box, I see the error 'Unsupported whitespace
hexadecimal value'. It turns out that any value greater than ASCII
'space' 0x0020) is unsupported. The only supported values are in the
drop down 'Whitespace Character' box. Which means I can set up
'Synchronous Idle' (0x0016) and display say an underscore (0x005f) and
lo and behold, it works; for that one attribute (yellow), I see an
underscore rather than a zero-width, non-display character.
Perhaps this will help someone else understand the odd case where
spaces/tabs are confusing the issue. It doesn't appear useful for these
attribute character issues.
--buck
midrange.com
