I'm using the RichTextBox in an app, and it flickers when I type. This is
starting to really annoy me, and I can't seem to do anything about it. I
can't release my app with this flaw in it though, so if anyone has any
advice I'd appreciate it.
And it's not just me - other peoples' applications have the same problem.
One example is a user sample from GotDotNet.com called BossEdit - you can
get it at:
http://www.gotdotnet.com/Community/User/Samples/download.aspx?FileGuid=a6bdc
3de-9eef-4ed8-b888-c6304ffcc0af
Steps to reproduce:
1. Run BossEdit
2. Paste in some text (the text I used to demonstrate this is at the
end).
3. Use the backspace key to delete some characters. (It happens when
you type quickly too.)
4. Watch the control flicker when the key is pressed.
This is nothing against BossEdit (a fine example), it appears in my own
programs and other peoples' too.
There is no complicated events processing going on either. I've removed all
the RTB event handling from my code and it still flickered. BossEdit
doesn't use too many events either (DragDrop, DragEnter, TextChanged and
LinkClicked). So I don't think the problem lies there.
Is there any way to fix this problem? I've also tried some weird things
like LockWindowUpdate () and WM_SETREDRAW, but none fixed the problem.
The thing is, I read in Charles Petzold's book that WordPad is based on the
same control. But WordPad doesn't flicker like this... So is there some
important difference there, or am I (and others) just not doing something
right?
I don't really want to go to the effort of writing my own equivalent of the
RichTextField just to get around this flickering, but I probably will if
there's no alternative. Please help!
Geoff
P.S. the text I used in my testing and demonstration of the flickering was
the first three paragraphs of a dotNET whitepaper on garbage collection
(http://www.gotdotnet.com/team/libraries/whitepapers/resourcemanagement/reso
urcemanagement.aspx)
"Historically, developers have had to be very careful when allocating
resources that require explicit released. For example in C++, all memory
allocated using operator new needs to be released by a call to delete. This
has been a source of numerous code defects.
"CLR (Common Language Runtime) provides support for automatic memory
management that frees developers from the difficult task of managing
allocated memory. Unfortunately, memory is not the only resource that needs
to be released after use. There are others, including database connections,
system handles, etc. These unmanaged resources are not understood by the CLR
and may need to be released manually.
"Sections 1 and 2 of the document are intended for developers using
components that allocate unmanaged resources. The rest of the document is
intended mainly for developers implementing such components. If you are only
a user of such components, you don't need to be concerned with most of the
issues described below section 2."
--
http://www.opinionatedgeek.com/ :: Part of the solution
I found a workaround for the flickering issue. Unfortunately, at this time,
I do not know the repercussions of using this workaround, so try it at your
own risk =). I have a developer working on the problem, and he will tell me
what will happen if you use this workaround, at which point I will post it
here.
My fix is to subclass the RichTextBox control, and remove the WM_USER + 7441
messages, using the following code:
public class UserControl1 : System.Windows.Forms.RichTextBox
{
public UserControl1() : base() {}
protected override void WndProc(ref Message m)
{
if (m.Msg != 0x2111) // WM_USER + 7441... not sure what this does yet
{
base.WndProc(ref m);
}
}
}
Good luck,
Bri
.NET Client Test Lead
--
Windows Forms Team
This posting is provided "AS IS" with no warranties, and confers no rights.
"Geoff" <ge...@blackhole.opinionatedgeek.com> wrote in message
news:10370415...@ananke.eclipse.net.uk...
apologies for the delay in getting back to you.
That works a treat! The redrawing is really solid now. I'm a bit concerned
about throwing away that WM_USER message when I don't understand the
repercussions, but so far my quick tests have all been fine.
Many thanks,
Geoff
Windows Forms Team <wfc...@microsoft.com> scribbled:
:: Hi Geoff,
"bRAINsaw" <mag...@dreamscape.no> wrote in message
news:un1vQ#huCHA.2028@TK2MSFTNGP11...
> Hi,
>
> I tried filtering on that message and ignoring it, with the results that
> OnVScroll event is not thrown anymore.
>
> Reproduce:
>
> Extend a RichTextBox, filter on wm_message 0x2111, override OnVScroll or
add
> eventhandling for the VScroll event and your event will never be
triggered.
>
> However, the contents in the RichTextBox are scrolled. So if you're not
> using custom OnVScrolling code this might work for you.
>
> It seems that the scrolling is handled internally anyway.
>
> I don't know if OnHScroll or the HScroll event is triggered, but that's
for
> you MS to test :)
>
> You can also add custom code self to handle the VScroll event like i did,
or
> just add your
> own VScrollBar, I believe. :)
>
> At least, you know :)
>
> best regards,
> Magnulf Pilskog
> Systemdeveloper
> Tarantell.Com
>
>
> "Geoff" <ge...@blackhole.opinionatedgeek.com> wrote in message
> news:ufzux5rpCHA.2480@TK2MSFTNGP12...
I tried filtering on that message and ignoring it, with the results that
OnVScroll event is not thrown anymore.
Reproduce:
Extend a RichTextBox, filter on wm_message 0x2111, override OnVScroll or add
eventhandling for the VScroll event and your event will never be triggered.
However, the contents in the RichTextBox are scrolled. So if you're not
using custom OnVScrolling code this might work for you.
It seems that the scrolling is handled internally anyway.
I don't know if OnHScroll or the HScroll event is triggered, but that's for
you MS to test :)
You can also add custom code self to handle the VScroll event like i did, or
just add your
own VScrollBar, I believe. :)
At least, you know :)
best regards,
Magnulf Pilskog
Systemdeveloper
Tarantell.Com
"Geoff" <ge...@blackhole.opinionatedgeek.com> wrote in message
news:ufzux5rpCHA.2480@TK2MSFTNGP12...