December 1, 2016 at 10:38 pm #22572
I have managed in most ways to get ME 2008(11.04) to work in Windows 10, but have noticed that when I open files as “binary”, the CR and LF characters no longer display as a “generic box”. Instead, they do not display in any way, which means that if I then open such a file in “hex mode”, the hex characters no longer match up with the corresponding ANSI characters after the first place where a CR and/or LF occur.
This same effect is apparent in the ASCII Table; most non-display ASCII characters are represented by a “generic box” figure, but not characters x02, x09, x0A, and x0D. This still works properly in ME 2008 in Windows XP, so I would guess something changed by the time MS released Win10.
Any suggestions as to how those common characters can be given a “box” placeholder in ME 2008?
I created an image of what I am seeing, but saw no way to upload it.
Thanks in advance for your assistance,
Bob KreycikDecember 2, 2016 at 5:53 pm #22573
Not having win 10 I cannot test this. I might hazard that you may need to change the editing font. In Tools-Customize-Editing do you have the ansi or oem font selected?
ClayDecember 2, 2016 at 6:50 pm #22574
Thanks for the quick response! I have tried every mono-width font listed when I click the ANSI button (both for the ASCII table and Default Editing ANSI font), and they all display — or in this case, fail to display — identically for the hex values I listed. I did try using the OEM Editing font instead, and that does supply a “generic box” placeholder character, so I could do this as a last resort. Those OEM characters are not nearly as easy on the eyes, though.
Feel free to correct me if I am mistaken, but it does not appear to me that the “generic box” is actually supplied as part of the font file, but is supplied by some macro in Multi-Edit? I tried opening the same example file in a hex editor I downloaded, and it uses periods to represent non-printable characters; thus, the assumption that the “box” is supplied by Multi-Edit so that each existing character is accounted for in the binary view.
Any other ideas or corrections?
Bob KreycikDecember 5, 2016 at 8:10 pm #22579
I’m on win 8 and in hex mode don’t see a box for CR/LF either. But if you see the box by switching to oem then the box is not a Multi-Edit thing, it is a font thing. I guess each application developer picks a substitute printable character to represent an unprintable one. I tried playing with switching files to binary format, no joy.
ClayDecember 6, 2016 at 12:37 am #22580
Thanks for verifying this issue in Win 8, Clay. I was beginning to think it was just me!
So, if it is true that the ANSI fonts themselves once contained a generic box to represent non-printable characters, but no longer do so consistently, then I suppose my options are either to find a customized ANSI font that does contain a generic placeholder for all non-printable characters, or to modify macros within Multi-Edit so that an existing generic character gets used to display something in the place of every non-printable character?
Bob KreycikDecember 7, 2016 at 11:51 pm #22587
Depending on your screen resolution, you can try these special terminal fonts that have ALL 8 bit chars defined.
They are rather handy for seeing control chars hiding in sourcecode , that can throw invisible compiler errors. (ME has all the chars except newline in the buffer, just the don’t show unless the font includes them)
Unfortunately they are fixed sizes, so may not work for hi-res screens.December 20, 2016 at 4:14 pm #22606
Thanks for the info!
You must be logged in to reply to this topic.