Hi, I have a completed, and very well working app that I use regularly, but I would like to improve it slightly. here is the issue:
The app records and processes astronomical observations. When it is made, a copy of each observation record appears in a Rich Text Box. Each obs. appears on a new line in the RTB. So far, so good.
If I make quite a few observations (the norm, even in the UK!) eventually the RTB acquires a vertical scroll bar. That's fine too - but what I would REALLY like is for the text to move upwards when the RTB is full vertically, so rather than the most recent observations being 'below' the bottom of the RTB and thus invisible (unless I use the scroll bar) I would like to see them in the RTB. That does mean that the earlier obs will now themselves be invisible, 'above' the top of the RTB but that is not a problem, as I've already seen them!
I am using VB6 on an XP laptop (yes I know it's ancient, but the laptop is only used for this one purpose!)
Question: Do you need an RTB, or can you use another control, like a listbox or a flexgrid, for example? With those suggestions, you can easily put the last item added on the TOP ROW.
What Phill says will work (the RTB will be 'scrolled' to that entry), but it won't be on the top row, which is what I THINK you want.
Question: Do you need an RTB, or can you use another control, like a listbox or a flexgrid, for example? With those suggestions, you can easily put the last item added on the TOP ROW.
What Phill says will work (the RTB will be 'scrolled' to that entry), but it won't be on the top row, which is what I THINK you want.
With the other controls you would get the same result, because if you were able to set the last row to the top, you would always see only one row (the last added).
Hi Phill,
Thanks for your helpful idea. But I have just discovered that what actually happens is that the data goes to a text file, and then the text file is loaded into the RTB - rather than each line of text being written directly to the RTB. Sorry about that - but the laptop is normally in my observatory rather than in the house! I am assuming that the various kind replies I have had won't actually work now! Again, sorry about that. I suppose I can write to both the text file AND directly to the RTB too, in which case your idea could be put into operation!
... the data goes to a text file, and then the text file is loaded into the RTB ...
Very common.
Have your code keep a note of the size (length) of the file.
Periodically, poll the size of the file. If it's changed, open the file, Seek to the position you "remembered", then read the rest of the file and make a new note of the new file length.
Add the text you've just read in onto the end of your RTB.
Phil's code in post #2 should still work.
After the file is reloaded in the RTB, then set the select start position to the end of the textbox.
Of course, jj2007 code will also work, you just have to add a bit of API declaration and look up a constant.
"Anyone can do any amount of work, provided it isn't the work he is supposed to be doing at that moment" Robert Benchley, 1930
But I have just discovered that what actually happens is that the data goes to a text file, and then the text file is loaded into the RTB - rather than each line of text being written directly to the RTB.
If I wanted to leave that nasty behavior in place, and I wanted to keep using an RTB, etc. then I'd probably just use TOM with it instead. TOM will probably reload this data faster than anything else but raw API calls, and it can easily be used to move the insertion point to the end or even just above the end (which is probably what you really want: no blank line at the bottom).
Tons of threads here and in the CodeBank on TOM usage with a RichTextBox.
Yes, there are many things that are "wasteful" in programming, but it does not worth (or even makes sense IMO) to optimize things that do not need to be optimized.
Unless he has many thousands of lines, there will be no practical inpact.
I believe that programming, as almost anything in life, needs balance. In this case it is a balance between simplicity and optimization.
I think it is more important in a case like this to resolve the issue in three lines, than applying complex code in the sake to optimize 10 milliseconds.
It worked - as you guys promised it would! Many thanks for your collective help. I used Phill's nice and simple solution in the end, so once again thanks Phill and others.