Board index » cppbuilder » Same property-values of a TMemo, but different behaviour. Why is this the case and how to avoid ths?

2007-01-12 09:15:18 PM
cppbuilder112
I'm having a TMemo-component.
At start it is empty.
When I enter e,g. 1<RETURN>2 and try to use the cursor to go down into
the third line this is not poosible.
When inspecting the Lines-property Count is (as expected) 2,
Strings[0] cotains "1", Strings[2] contains "2".
All as expected.
Than (e.g. by a click on a button) executing the following code:
Memo->Lines->Clear();
Memo->Lines->Append("1");
Memo->Lines->Append("2");
results in the same property-values of Lines:
Again Strings[0] cotains "1", Strings[2] contains "2".
All as expected.
But to my surprise when entering the memo, just by miving the cursor I
am able to scroll down to the third line.
Setting the cursor behind the 2 and pressing DEL some times results in
the behaviour of the first case.
Where is the difference between the two cases and how do I have to
change my code for case 2 to get the behaviour of case 1.
Thanks,
Michael
 

<MR>wrote:
property or it's Lines::Add method.
~ JD
 

Memo->Lines->Clear();
Memo->Lines->Add("1");
Memo->Lines->Add("2");
instead does not make any change. I still can reach the third line by
just using the cursor-down-key.
Thanks,
Michael
 

{smallsort}

<MR>wrote:
but that's not practical if there's alot of text because
of the excessive overhead. This also worked:
Memo1->Lines->Clear();
Memo1->Lines->Add("1");
Memo1->Lines->Add("2");
Memo1->SelStart = Memo1->Text.Length();
Memo1->SetFocus();
keybd_event( VK_BACK, 0, 0, 0 );
keybd_event( VK_BACK, 0, KEYEVENTF_KEYUP, 0 );
~ JD
 

<MR>wrote in message
to go after the second line.
inserts a line break to the end of the string. So you are now
entering 2 line breaks instead of 1. Thus the extra room for the
cursor to move to the third line.
would have the same behavior.
removing the space for the third line.
You would have to use the SelStart and SelText properties instead of
Add/Append(). Then you have more control over whether the line breaks
appear. For example:
Memo->Lines->Clear();
Memo->Lines->Append("1");
Memo->SelStart = Memo->GetTextLen();
Memo->SelText = "2";
Or:
Memo->Lines->Clear();
Memo->SelStart = 0
Memo->SelText = "1\r\n";
Memo->SelStart = Memo->GetTextLen();
Memo->SelText = "2";
Or:
Memo->Lines->Clear();
Memo->SelStart = 0
Memo->SelText = "1\r\n2";
But why would you want to do that in the first place? This is
standard behavior. You shouldn't really mess with it.
Gambit
 

"JD" < XXXX@XXXXX.COM >wrote in message
Gambit
 

"JD" < XXXX@XXXXX.COM >wrote in message
Memo1->SelStart = Memo1->GetTextLen();
By using the Text property, you are copying the entire contents of the
Memo into a temporary AnsiString. Very inefficient for large amounts
of Text. The Memo() internally knows its full length, so there is no
need to touch the actual content.
Memo at any time before the calls to keybd_event() are finished. If
you are going to send keystrokes, then you should be posting WM_KEY...
and WM_CHAR messages directly to the Memo's window instead.
Gambit
 

"Remy Lebeau \(TeamB\)" < XXXX@XXXXX.COM >schrieb:
What I didn't remember was, that there is a property TMem::Text, from
which property Lines is evaluated.
As it seems for each '\n' ('\r\n') in Text a new Line[] is 'created'
with one exception: if '\r\n' is at the very end. Than no new line is
created.
The first case was the one with no terminating '\r\n', the second was
the case with the terminating '\r\n'. So Lines is the same, Text is
not.
So thank you, as sauid all works now fine.
Michael
 

<MR>wrote in message
over-quote the original messages being replied to.
Gambit