|
|
Post by Stefan on Apr 23, 2019 14:05:11 GMT -5
Slight display corruption observed in versions 10.1.9014 and 10.2.19107. Not tested with prior versions.
When applying the data shift (>>) line command to a colorised file, words flagged in the AUTO profile as AUTOCAPS will appear underlined after the shift.
There's no adverse effect to the data in the file and the effect does not reappear when the file is reloaded.
PS... In case this is relevant, I'm using Font RASTER, Pitch 16
|
|
|
|
Post by George on Apr 25, 2019 9:08:51 GMT -5
Robert: Stefan: I'll add this to my To-Do to check out. I don't like seeing bugs, but hearing they've been around for a while un-reported is annoying.
George
|
|
|
|
Post by George on Apr 25, 2019 12:58:12 GMT -5
Robert: Whatever the error is, it's not wrong at a pixel level, color attributes don't work that way. It looks like the attributes are simply not being set and residual data gets interpreted as a bunch of bit flags. The attr has 3 bit flags and two color numbers all stored together in one wide character.
George
|
|
|
|
Post by Stefan on May 3, 2019 12:41:04 GMT -5
I'm not sure I quite follow Robert's Apr 24 description above, although it sounds related but different. To clarify, the effect I've noticed...
- only happens if a line is shifted using >/>> line commands
- only affects those words that are defined in the .AUTO colorise file with AUTOCAPS instead of WORD
- such words appear in their new correct (shifted) location on the line, but are now underlined in their respective highlight color.
- any colorised words on the same line which are defined with WORD, even those entered in capitals, show correctly and are not underlined.
Perhaps the new AUTOCAPS implementation introduced with the change from using SCHEME numbers over 100 to achieve the capitalisation in prior versions?
|
|
|
|
Post by George on May 4, 2019 10:24:31 GMT -5
Stefan: Thanks for the extra clues. I just haven't got to this yet.
George
|
|
|
|
Post by George on May 4, 2019 11:35:40 GMT -5
OK, I believe this is now fixed. Robert: The DataShift routines you wrote are the weirdest to work with. Frankly, I've never even been clear just what the << and >> shift routines are supposed to do. I've never used them.
The error was in a temp variable used when you re-build the text and attribute lines. When I made the colour changes for V10, I missed converting one of the temp working variables from STRING to WSTRING. So at one point attribute data was copied to a a normal STRING variable, destroying it, and then merged back into the normal attribute WSTRING. And of course gets misinterpreted by the display process.
George
|
|
|
|
Post by George on May 5, 2019 10:37:28 GMT -5
Robert: Better explanation. I went to the Help and looked at Data Shifts, but the page and a half of dense text just scared me off. It's always the way, some relatively simple things take an enormous number of words when written out.
George
==> Yeah, and the page and half of dense text is probably my fault doing, so blame me :-) |
|
