which function would be more efficient to use, to redisplay all the characters in the window ?
i have no real TAB characters in the text (all converted to spaces)
With DrawText, it would process the CRLFs, OR i could use TextOut or something, in a loop which
only drew upto the amount of characters in each line, that fit in the width of the window,
through each cycle of the loop.
am thinking that with DrawText there'd be some overhead & I'd be supplying the entire
text block from the first char in the window to the last char.(They say in the SDK
though, that DrawText is more efficient for drawing multiple lines in the borders of a rectangle).
- Or some other txt function maybe ? (all this is for purely text data)
When i wrote this post it was with things in mind like having to rewrite all the text in
the window when the caret movement keys caused the caret to go beyond the borders
of the window, or for a pageup/pagedown etc. - but would be interested in any advice related
to other text editing operations where I'd have to write/rewrite/remove the text.
am new to this, & any feedback & tips relating to this would be much appreciated.
basically would just like to arrive at the fastest/most efficient way of doing this
at the same time using something that would offer some versatility.. that might come
in use.
Thanks a lot!
-
RainStorm,
An application sends an EM_SCROLLCARET message to scroll the caret into view in an edit control.
-- Paul
Paul, am not using any edit control for the text
thx.
Take a look at ScrollWindow - that will save you from needing to redraw much of the text, most of the time.
Then I would probably go for TextOut, as it tries to do less then DrawText.
When scrolling (through caret movement, scrollbars..), use ScrollWindow to 'move' the portion of currently visible text, then you only need to redraw the 'new' text that wasn't visible before, e.g. if you scroll right 10 chars, shift the right-hand rectangle to the left edge (using ScrollWindow), the you'll have a 10 char wide rectangle on the right in which you'll need to draw the newly visible chars; scrolling vertically is conceptually a little easier.
Other cases (pg-up/down) will require a full redraw, so you'll just have to fill the window with the new text.
tedd, that was very helpful thx., the example you gave helped some in understanding the scrollwindowex function
in the ScrollWindowEx function what is the hrgnUpdate member for actually ?
the invalidated portion iss already returned in prcUpdate , right ?
-
Quote from: Rainstorm on June 22, 2008, 02:55:45 AM
in the ScrollWindowEx function what is the hrgnUpdate member for actually ?
It's for you to provide a region-handle - the region will enclose the area that needs to be redrawn, upon returning. I wouldn't bother using it though.
Quote
the invalidated portion iss already returned in prcUpdate , right ?
Yes. However, if you give either SW_INVALIDATE or SW_ERASE, you'll receive the area in a WM_PAINT message - which you should probably be handling anyway. That is, you should redraw the invalidated area in WM_PAINT, not necessarily the whole window every time.
tedd wrote..
QuoteThat is, you should redraw the invalidated area in WM_PAINT, not necessarily the whole window every time.
just need some advice on how this is done, should i do something like mantain a global variable, that i check in the WM_PAINT processing,.to decide what kinda action to take.. ? - since the WM_PAINT procesing would be different in different cases.
Just another thing, i was fooling around with the draw functions & I realised that DrawText isn't gonna be much help in most of this stuff since if it doesn't find a CRLF before the clipping rectangle border, the rest of the text won't be drawn. - i think mostly i'd have to use TextOut or ExTextOut maybe in my own loop & draw the lines one by one
So far from what i've tried coding wise, it kinda seems easier to just draw whatever text is needed in my own loop, Since even with ScrollText, I'd anyhow have to do pretty much the same amount of work (if not more) calculating what needs to be written in the invalidated region, & without using ScrollText i'd be doing the same calculations, just be drawing from a different offset in the line, which corresponds to text in the buffer,corresp to the leftmost collumn, in the window.- [primarily horizontal scrolling that i've been trying] dunno about efficiency wise..
thx
Quote from: Rainstorm on July 11, 2008, 11:05:39 AM
just need some advice on how this is done, should i do something like mantain a global variable, that i check in the WM_PAINT processing,.to decide what kinda action to take.. ? - since the WM_PAINT procesing would be different in different cases.
There's no need to do anything special - the area that needs updating is indicated in the paintstruct (rcPaint) after you call BeginPaint. Always check what that rectangle is and only update that area (when the whole client area needs redrawing it will be the whole area.)
Quote
Just another thing, i was fooling around with the draw functions & I realised that DrawText isn't gonna be much help in most of this stuff since if it doesn't find a CRLF before the clipping rectangle border, the rest of the text won't be drawn. - i think mostly i'd have to use TextOut or ExTextOut maybe in my own loop & draw the lines one by one
Draw the text one line at a time.. (Amongst other things, you also have the choice of whether to word-wrap or not.)
Quote
So far from what i've tried coding wise, it kinda seems easier to just draw whatever text is needed in my own loop, Since even with ScrollText, I'd anyhow have to do pretty much the same amount of work (if not more) calculating what needs to be written in the invalidated region, & without using ScrollText i'd be doing the same calculations, just be drawing from a different offset in the line, which corresponds to text in the buffer,corresp to the leftmost collumn, in the window.- [primarily horizontal scrolling that i've been trying] dunno about efficiency wise..
Yes, you'll have to do a bit more coding to handle this, obviously. But it's less work overall - gdi operations are slow, so it's not a bad idea to reduce the amount of work done by it.
If you draw the lines one by one, then for vertical scrolling (which will be the most common) you can cut out a lot of the drawing with ScrollWindow and only draw the text lines that really need to be drawn. For horizontal scroll, you're right, there's a bit more to handle - so it's up to you to decide if you think it's worth just drawing the whole of each line, or only the section of characters that need to be drawn.
Tedd,
i'll check out ScrollWindow for the vertical scrolling.
much appreciate all the info & advice...... will post here soon.