Board index » cppbuilder » RichEdit: how to know that we are at the end of the RichEdit

RichEdit: how to know that we are at the end of the RichEdit


2003-11-20 10:27:29 PM
cppbuilder11
Well I guess all is in the subject.
I also guess that we have to deal with SelStart....
But I suppose there will be a bug because SelStart is just an int and so if
the file exceed a certain size, the int will not be able to store the value.
So I want a method which answer is true when the cursor is at the end of the
text without using selstart or use it with guarantee that there will be no
problem if the size is greater than the int capacity.
thx in advance
 
 

Re:RichEdit: how to know that we are at the end of the RichEdit

Hans Galema < XXXX@XXXXX.COM >wrote:
Quote

What kind of monstruous files to you want to handle ?

Do you know the maximum value an int can take ?

According to 'Help' the OS will limit the max RE size somehow
and I guess the OS limit will be less than or equal to the int
limit, so Chris will hit his problem when he tries to overload
his RE, not when he tries to find his cursor with SelStart.
George
 

Re:RichEdit: how to know that we are at the end of the RichEdit

chris wrote:
Quote
Well I guess all is in the subject.
Well that is a bad guess.
Please read:
info.borland.com/newsgroups/guide.html
RULES
<quote>
.... Place all of the information relevant to your post in the message body. Do
not assume that everyone can see or will read the subject line.
</quote>
Quote
I also guess that we have to deal with SelStart....
But I suppose there will be a bug because SelStart is just an int and so if
the file exceed a certain size, the int will not be able to store the value.
What kind of monstruous files to you want to handle ?
Do you know the maximum value an int can take ?
Hans.
 

{smallsort}

Re:RichEdit: how to know that we are at the end of the RichEdit

Quote
What kind of monstruous files to you want to handle ?

Do you know the maximum value an int can take ?
It's not that monstrous. The largest file I've ever made was nearly 10Gb in
size. Needed to use BCB's FileRead and FileWrite functions and __int64s to
get it to work.
G.
 

Re:RichEdit: how to know that we are at the end of the RichEdit

"george" < XXXX@XXXXX.COM >wrote in message
Quote
According to 'Help' the OS will limit the max RE size somehow
By default, a RichEdit is limited to 64K of text. However, that limit can
be increased programmably.
Quote
and I guess the OS limit will be less than or equal to the int
limit, so Chris will hit his problem when he tries to overload
his RE, not when he tries to find his cursor with SelStart.
SelStart is an 'int'. It can handle up to 2 billion characters positions,
or 2GB of text. I seriously doubt anyone would try to load a 2GB text
document into a RichEdit control, the system doesn't have that kind of
memory available in the first place (unless you're really really lucky, and
rich).
Gambit
 

Re:RichEdit: how to know that we are at the end of the RichEdit

"Remy Lebeau (TeamB)" < XXXX@XXXXX.COM >a écrit dans le
message de news: XXXX@XXXXX.COM ...
Quote

"george" < XXXX@XXXXX.COM >wrote in message
news:3fbcdea3$ XXXX@XXXXX.COM ...

>According to 'Help' the OS will limit the max RE size somehow

By default, a RichEdit is limited to 64K of text. However, that limit can
be increased programmably.
Well I do not see this limitation ( I load file that are 25Mo)
Quote

>and I guess the OS limit will be less than or equal to the int
>limit, so Chris will hit his problem when he tries to overload
>his RE, not when he tries to find his cursor with SelStart.

SelStart is an 'int'. It can handle up to 2 billion characters positions,
or 2GB of text. I seriously doubt anyone would try to load a 2GB text
document into a RichEdit control, the system doesn't have that kind of
memory available in the first place (unless you're really really lucky,
and
rich).
Well that is right that 2Go is very big but log files are sometimes very
huge.....
But I recognize I have make a mistake thinking that it can happen because
you are right saying that only rare personn could have such memory.
Nevertheless, I still do not have an answer for my question that, like Hans
said, I should have written in the body (sorry, I had forgotten this
rule....)
So I repeat it here:
How do I know that my cursor is actually positionned at the end of the
RichEdit?
Well I do not see how to corelate SelStart with anything else in the
RichEdit. I surely missed something easy but I do not see what....
thanks for the help
 

Re:RichEdit: how to know that we are at the end of the RichEdit

chris wrote:
Quote
How do I know that my cursor is actually positionned at the end of the
RichEdit?
if ( RichEdit1->SelStart == RichEdit1->GetTextLen() )
{
// the cursor is at end of the text
}
If you want to set the cursor at the end of the text:
RichEdit1->SelStart = RichEdit1->GetTextLen();
Hans.
 

Re:RichEdit: how to know that we are at the end of the RichEdit

"chris" < XXXX@XXXXX.COM >wrote in message
Quote
Well that is right that 2Go is very big but log files are
sometimes very huge.....
Log files that large are not usually displayed in normal text editors. If
they are, the user gets when he deserves. For such massive files, It is
better to use an actual log viewer that supports large files, or just write
your own viewer using a virtual ListView, which can handle billions of
entries with minimal memory overhead, especially if you perform some file
buffering as well so you don't instill the overhead of performing file I/O
all the time..
Quote
How do I know that my cursor is actually positionned at the end
of the RichEdit?
That has already been answered the first time - the SelStart property is the
only way to know where the caret is located. Simply test its value against
the return value of the GetTextLen() method to see if the caret is at the
end of the text. You will be limited to 2GB, so if that bothers you, you
could always limit the RichEdit itself to 2GB as well so that it does not
attempt to load more text than that. You could always pre-test the file to
see what its actual file size is before you try to load it, and then warn
the user if the file is too large.
Gambit
 

Re:RichEdit: how to know that we are at the end of the RichEdit

"Hans Galema" < XXXX@XXXXX.COM >a écrit dans le message de news:
XXXX@XXXXX.COM ...
Quote
chris wrote:

>How do I know that my cursor is actually positionned at the end of the
>RichEdit?

if ( RichEdit1->SelStart == RichEdit1->GetTextLen() )
{
// the cursor is at end of the text
}

If you want to set the cursor at the end of the text:

RichEdit1->SelStart = RichEdit1->GetTextLen();

Thanks.
I was sure I miss something very simple, and that something was
GetTextLen(); :)
 

Re:RichEdit: how to know that we are at the end of the RichEdit

"Remy Lebeau (TeamB)" < XXXX@XXXXX.COM >a écrit dans le
message de news: XXXX@XXXXX.COM ...
Quote

"chris" < XXXX@XXXXX.COM >wrote in message
news: XXXX@XXXXX.COM ...

>Well that is right that 2Go is very big but log files are
>sometimes very huge.....

Log files that large are not usually displayed in normal text editors. If
they are, the user gets when he deserves. For such massive files, It is
better to use an actual log viewer that supports large files, or just
write
your own viewer using a virtual ListView, which can handle billions of
entries with minimal memory overhead, especially if you perform some file
buffering as well so you don't instill the overhead of performing file I/O
all the time..
As it will be my future task (writing a log viewer), I will remember this
story of virtual ListView.
I do not know what it means know, but I hope it will be clearer when I do
it....
Quote

>How do I know that my cursor is actually positionned at the end
>of the RichEdit?

That has already been answered the first time - the SelStart property is
the
only way to know where the caret is located. Simply test its value
against
the return value of the GetTextLen() method to see if the caret is at the
end of the text.
Well the function that I was seraching for was GetTextLen and this was not
given in the first post.
Quote
You will be limited to 2GB, so if that bothers you, you
could always limit the RichEdit itself to 2GB as well so that it does not
attempt to load more text than that. You could always pre-test the file
to
see what its actual file size is before you try to load it, and then warn
the user if the file is too large.
Thanks, that is what I am going to do.
 

Re:RichEdit: how to know that we are at the end of the RichEdit

"chris" < XXXX@XXXXX.COM >wrote in message
Quote
As it will be my future task (writing a log viewer), I will remember
this story of virtual ListView. I do not know what it means know,
but I hope it will be clearer when I do it....
All a virtual ListView does is allows you to store the ListItem data
elsewhere in memory rather than inside the TListView itself. Whenever the
ListView needs to display or access a particular item, its OnData event will
be triggered, and you provide the data for the requested item at that
moment. You can store the data whereever you want (an in-memory buffer, a
database, a file, anywhere you want. This allows you, not the ListView, to
manage the memory for the ListView items. Why would you do this? Because
if you let the ListView manage it, it will load *all* items into memory at
one time, which for millions to billions of records, will bring the system
to a crawl or even crash. But if you manage it yourself, you could buffer
the data more efficiently, such as keeping a buffer that is large enough
just for the items that are actually visible onscreen, and re-buffering the
data only when the user actually scrolls through the ListView.
Gambit