EM_HIDESELECTION & the RichTextBox

[Crunchy Cat]

Hi, have found a huge amount of code in this forum dealing
with creating color syntax editors.The general concensus is not to
make one from scratch but to rather use/extend the RichTextBox
control for this purpose. Sample code provided by members such
as Megatron and BuggyProgrammer demonstrate the
fundamentals of syntax highlighting. Other members imroved
upon these basics with a wide variety of nice features.

There is one problem however that nobody seems to have
successfully addressed, and that is the visual flicker caused by
having to reformat text as the user is typing. Various attempts
to minimize this visual annoyance have been made with varying
degress of success (none of them completely successful). Some
examples include:

* Using the LockWindowUpdate () from the Win32 API.
* Only reformatting text which is not of the desired format.
* Reformatting the text in an offscreen buffer and 'streaming'
it back into the control.

These attempts are definately good attempts, but the end result
still lacks a professional looking quality. The flicker problem seems
to stem from automating the selecting (highlighting) of text (not
the actual reformating itself). I tried to test this hypothesis by
sending a EM_HIDESELECTION message to the control but it
seemed to have no affect. Upon further investigation (using
MS Spy++) I discovered that the control was simply not
interpreting EM_HIDESELECTION, thus leading me to believe
that VBs RichTextBox control is an extended RichEdit control
whose windowProc () is sending certain messages into a black
hole.

I would really like to know if anybody has found a solution
to this problem (or even a way to get the EM_HIDESELECTION
message to be recognized). I would also like to know if anybody
has had an positive experiences with creating a pure Win32
RichEdit control on a VB Form and making it useful (through
messages I would presume).

Thanks,

-CC

[Rick Bull]

It's not just that you are using EM_HIDESELECTION wrong is it? I would have thought it should respond to all messages.

[Crunchy Cat]

Well using it 'wrong' could have multiple definitions. So:

Q) Am I using the correct message constant?
A) Yes. 100% sure.

Q) Am I using the message correctly?
A) I am using it according to how its documented in MSDN.
There is of course always a chance that I am mis-interpreting
something, but seeing as how I now have an MFC version of
what I am trying to do actually working I doubt it.

Give it a try for yourself and let me know what you think.

Thanks,

-CC

[Rick Bull]

This seems to work for me. I think it's what you want, I could be wrong though

[Crunchy Cat]

Yep, that puppy works all right. So the message is supported
and I think I understand why it does not work for me. The MSDN
docs for the message don't fully note that it only has an effect
when the control is not focused. I verified this in my editor by
sending a WM_KILLFOCUS before doing any highlighting and then
a WM_SETFOCUS after I was done. Sure enough, the highlights
never appeared... but flickering still does for some reason. My
MFC project was giving me false results because my editor
window was so small. I increased the size and sure enough I
started seeing the higlighter flicker. Anyhow, it looks like I have a
way to make this message work for me (and thanks for helping
me see the light ). I currently still get some flicker though (even
with a LockWindowUpdate ()). It seems to come from repaints
after any color formatting (too bad this control is not double
buffered eh?). I'll still hack at it, but feel free to throw any hints
my way for flicker elimintation.

Thanks,

-CC

[Crunchy Cat]

Speaking of double buffering... what do you think about this?
If I subclass the Window Proc of the RTB and code it something
like this (mind the pseudo-code):

Function wndProc(ByVal hwnd As Long, ByVal uMsg As Long, ByVal wParam As Long, ByRef lParam As Long) As Long

Select Case uMsg
Case WM_PAINT
x = CallWindowProc oldProcAddr, hwnd, uMsg, hOffScreenDC, lParam
BitBlt wParam, dx, dy, dw, dh, hOffScreenDC, sx, sy, SRCCOPY

End Select

wndProc = x
End Function

Basically faking a persistent bitmap. Think it would eliminate
all and any flicker when coloring my list of keywords?

Thanks,

-CC

[BuggyProgrammer]

did you get my code where you could colour code w/o highlighting?

[Crunchy Cat]

Numerous times. It seems like every other question regarding
color syntax coding has your name written all over it . The RTF
codes are pretty well documented in MSDN and your examples
document how to use them quite well. Even pre-formatting the
RTFText as the user enters in text seems to show some flicker.
The VB and VC editor are so smooth in their updates and that
is the quality I am after... but of course if you know any other
tricks or have any comments on my subclass theory send em' my
way!

-CC

[BuggyProgrammer]

VB and VC++ was probably made in C/C++ with some ASM. VB programs are made in, well, VB. it's going to be much slower. they probably made their own text control that would color the text MUCH more efficiently that looping through the words. probably has an array of the postion of the words so it would be faster.

[Rick Bull]

The other alternative is to just find a RTF replacement OCX (with built in highlighting) that doesn't flicker, although I've never been able to find one myself. Well I found one but the download page was dead

[Crunchy Cat]

Just thought I would update you. I made a pretty nice
subclasser to tackle my theory of forcing a double-buffer of
some sort. Here it is if you are interested:

http://www.vbforums.com/showthread.p...hreadid=201650

Anyhow, I guess I should have used Spy++ first because the
WM_PAINT messages have an HDC value of '0'... nothing much
I can do with that. I tried eliminating WM_PAINT messages while
performing color-coding... but there was still some flicker. Why?
WM_PAINT is not called in many instances (rendering happens
directly without any paint messages).

So, while I got to make a great subclasser that facilitated the
creation of all sorts of useful components for me... I also had
the privilage of demonstrating the futility of trying to turn the RTB
into a high quality color syntax editor. Live and learn I suppose.

RICK BULL, I really really really hate using 3rd party components.
As soon as they are no longer made anymore you're stuck (not
to mention you have no control over the bugs).

Now for the good news. I did some preliminary experiments and
discovered that with a little subclassing the PictureBox control
of all things will make a fantastic color editor (very high quality).
The downside is that there is alot of work involved in making
this a fully functional editor (let alone a color editor).

If anybody would like to help me develop this control, now would
be a great time to speak up. Some benefits to helping me with
this are:

* The control gets completed that much quicker.
* You know the ins and outs of the control.
* You get a really good control in the end!
* We can finally put RTB hell to death (along with any 3rd
party-were-gonna-dissappear-on-you temptations such as
the 'codemax' control for which no links work against
anymore).

Thanks,

-CC