1. bug in the EditText Area
posted by: a.admin at myway.it
To Derek,
I have met a new problem with an EditText Area ver. 0.59.1 8):
createEx(EditText,"",ChildWin,5,25,0,0,{WS_CHILD,WS_VISIBLE,WS_VSCROLL,ES_M=
ULTILINE},3 )
that is:
normal edit operations (copy, cut, paste etc.) cannot be performed if the t=
ext/file size overcomes 25-30Kbytes.
For more help, a popup men=F9 behaves the same, inserting two strings befor=
e and after a portion of text:
setSelectedText( fTextArea, Tag[1..i-1]&text&Tag[i+1..length(Tag)])
works fine with a text less than 25K; from 25K to 30K (approx.) the 1st Tag=
is pasted, but the last 3 bytes of the original word are cut (mean deleted=
).
If I delete more text, I can paste two or more times the same string, until=
30K are reached (this is the visible size of the saved file); after cannot=
paste anything else.
If the loaded file exceeds the 30K no operation is possible.
Hope you can fix this in the new version (waiting for too).
Antonio Alessi
2. Re: bug in the EditText Area
Not a bug!
Value of wParam. Specifies the new text limit, in bytes. If this parameter is 0,
Windows sets the maximum text limit.
The maximum text limit is 32,766 bytes for a single-line edit control, and
65,535 bytes for a multiline edit control.
i.e: void=sendMessage( control, EM_SETLIMITTEXT, 0, 0 )
That, incidentally, is why the old NotePad always went to WordPad for larger
files.
3. Re: bug in the EditText Area
posted by: a.admin at myway.it
Hello again, Wolf
After set VOID = sendMessage( fTextArea, 197, 0, 0 ) the situation improv=
es, but some problems remain.
A 62K file may be edited with 'curious' restrictions: can cut/paste undo/re=
do through all the file, but if the use of setSelectedText() is needed, it =
works fine in almost all the file, but bad at its last lines, where a strin=
g may be tagged before and after, but the string itself is replaced with an=
other, taken somewhere else in that text or from the clipboard.
This doesn't look like a 'normal' behaviour, and may be somewhat dangerous.=
By the way, this problem arised from the use of a popup men=F9, which Derek=
said "is built into Windows and not win32lib, so playing with it will requ=
ire lots of trickery somewhere.."
The same for larger files, now editable once loaded, but without any contro=
l on what the editor is going to do, depending on where the text is being m=
odified, beginning-of-file (just before the 64k limit?) or not.
Every action may be done or not done, but the success cannot be predictable=
: a user may not to realize that, before it's too late.
I know that the programmer can prevent this situation (even if not so easy)=
, but this is the programmer's job; the system before all should do its one=
correctly. So I think there is a bug somewhere :()
Antonio
