CEdit or CRichEditCtrl text highlighting

[jonnyair<>_]

I want a control to handle basic Notepad functionality (input
characters, cut, copy, paste) but also want to highlight a line of text
much like stepping through code in Visual C++ editor. Changing the
color and it's background if possible.

I have experimented both with RichEdit and Edit controls but it seems
like each one has it's pit falls. On that note I have a couple
questions to ask:

1. When adding a Edit control, I automatically have popup functionality
(right click, then a popup menu with clipboard options, Cut, Copy,
Paste) but with a RichEdit I don't. Is there something in the RichEdit
properties that is needed to get this functionality? Do I need to do it
by hand?

2. I understand how to change text color in a RichEdit control but it
seems like it's a pain with Edit, am I perceiving this wrong? (My
opinion is based on examples found on Code Project and Code Guru.)

My app:
* wizard built MFC MDI with one FormView
* using Visual Studio v6 with SP6

Note to the curious: There is only one FormView but multiple instances
can be opened to communicate to different PCI peripherals but no two
instances per one peripheral.

Jonny

[Joseph M. Newcomer]

Adding the right-click to a rich edit isn't all that hard. Just create the menu, and in
the WM_CONTEXTMENU handler, just do

CMenu menu;
menu.LoadMenu(IDR_EDIT_POPUP);
CMenu * popup = menu.GetSubMenu(0);
TrackPopupMenu(x, y, ..., this);

Because of the 'this' specification, the messages are routed to your own window. Then you
can call the Copy, Cut or Paste members the rich edit control. Use the same IDs for your
popup as were used in the Edit menu on your main menu bar.

void CMyDialog::OnCopy()
{
c_Text.Copy();
}

If you have more than one control, you may have to use GetFocus to determine which window
to send the message to; in my app, I had only one rich edit (and therefore only one
edit-capable) control which filled each CFormView, so it was easy.But I think you can
experiment a bit if you need this for multiple controls.

You cannot selectively change text color in an ordinary edit control; that's why we tend
to use rich edit. You can't change the background color unless you use the 2.0 version,
and my recollection is that this still isn't easy because the 2.0 structure isn't
supported in MFC, but my memory may be wrong. I just finished a syntax-highlighting app,
but we only needed to change text color.
joe

Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

[jonnyair<>_]

I'm not sucking up here but I can't believe I got one of the "masters"
to reply to my post. I frequent visit your site and read your postings
(thank you Google for archiving newsgroups). And now embarrassed to say
that I was able to answer my questions after it was sent off looking
through some books I forgot I had.

What I did was create a custom RichEdit class inheriting from
CRichEditCtrl adding in WM_RBUTTONDOWN message and (by hand) adding in
message macros and inline functions to make the calls to the clipboard
members. And last created a (popup) menu resource.

Doing it this way I shouldn't have to worry about which control needs to
receive the "right click" message. (Correct me if I'm wrong.)

In your syntax-highlighting app, what color(s) did you use or find to be
the best ones visually?

Thanks,
Jonny

[Joseph M. Newcomer]

Using the derived class is where I would have put the WM_CONTEXTMENU or WM_RBUTTONDOWN
handler I showed below.

For colors, I chose some colors sort-of-looked-nice, but gave the user a way to change
them. What I did was a a table which had the color value, an IDS_ code from the
StringTable describing the color, a pointer to a table of words/symbols that would use
that color (operators, keywords, reserved words, etc.). When the user chose "Select
Colors", I presented a dialog which had the list of all color values as a combo box
"Text", "Window", "Keyword", etc. Choosing one of these put all the associated values in
another combo box so the user could see what keywords/symbols would be used. Finally,
there was a rich-edit control in the dialog which showed the selected window background
color and each of the color descriptor words in their selected color, that is, it had text
that said "Text comments operators reserved", each word in its correct color. Finally
there was a button that popped up a color-selector dialog. When this dialog closed, the
colors were all updated to show what they would look like.

Be sure of one thing: whatever colors you choose, you will be wrong, by the estimation of
at least one user.

I used my Registry classes to store these in the Registry when the color-change dialog
closed. I then reloaded the color table and re-highlighted the window(s) by having my
mainframe send a UWM_I_CHANGED_COLORS message to all the views.

Unfortunately, most of this code is proprietary and I can't publish it or give it away.
I've got permission to "sanitize" the syntax highlighting code, but it will be a while
before I have a chance to publish this.
joe

[jonnyair<>_]

Thanks Joe for the syntax/color input. I will be implementing user
color/font selection too but deep down inside I hoping that there would
be a color that universally accepted but I guess you can't please 100%
of the users 100% of the time.

Just to clarify, WM_RBUTTONDOWN is in the derived class. Re-reading my
last post, it didn't sound all that clear.

jonny