Hyperion Entertainment Message Boards

================================================================================
NotePad 53.10 (20/11/11)
Written 2003-2004 by Stephan Rupprecht
================================================================================
Report_2014.02.17.0001_NotePad_53.10
By: Alexander Benedictov
[email protected]
================================================================================
When pasting a single string or block of text
with ASCII characters 0x7F in them into NotePad,
characters 0x7F are deleted from resulting string
or block of text in NotePad.

CLI 52.4 (10/05/07) and TurboText from AmigaForever
2012 do paste strings with 0x7F correctly -
the resulting strings contain 0x7F.
================================================================================

AlexBene wrote: When pasting a single string or block of text
with ASCII characters 0x7F in them into NotePad,
characters 0x7F are deleted from resulting string
or block of text in NotePad.

No problem here. Works from CLI, Timberwolf, other NotePad....

I'm not sure if you can call it a bug. I think notepad does filter out some chars which are control chars (0x00 - 0x1f, 0x7f - 0x9f). It is a text editor after all.

I had troubles copy & pasting UTF-8 strings with notepad.

This version of NotePad has another bug, the first time a file is saved, it does not check if the file already exists and just overwrites it.
to reproduce
1) copy 2 files to RAM:
2) Open NotePad (I did via AmiDock)
3) type some garbage
4) click save
5) in ASL go to ram: and by accident click on one file name you previously copied
6) save
The file is overwritten without notice

if you then modify the file in notepad again, select "Save as.." and choose the second file previously copied to RAM, an info requester asks for confirmation.

scary!

This has been fixed internally, and is available from Notepad 53.11

Simon

gazelle wrote:I'm not sure if you can call it a bug. I think notepad does filter out some chars which are control chars (0x00 - 0x1f, 0x7f - 0x9f). It is a text editor after all.

I had troubles copy & pasting UTF-8 strings with notepad.

Correct UTF-8 has 0x7F mapped as a control character (US-ASCII Delete) and the correct behaviour interprets it as a character delete operation from a Keyboard event,

I do not know of it being valid for a non keyboard input so filtering non-glyph character codes with control and not whitespace meaning would appear correct to my understanding at least.

UTF-8 Encoding would have values 128-192 when not a glyph in the first 0-127 range or the marker codes of 0xC0-C3 0xE0-EF and 0xF0-F7

I do however understand that the ISO-2022-CN/JP/KR series is more trouble in being escape code prefixed double-octet per glyph strings with 16 bits per glyph giving higher chances of strange behaviour on misunderstanding,