mfc RichTextBox2.0 grayed

1
votes

I'm using mfc in C++ app. I had CEdit controls and changed them for CRichEditCtrl. App is graph editor with internal code in nodes where TextBox is holding the code in dialog in separate window from wnd with graph. If node is clicked, that wnd and dialog is showed (different nodes have different wnds and are hidden when inactive)

My problem is that if I have some longer text in that text box whole area of the text box is grayed. Text is still there, caret can be set by mouse click but nothing is visible until I do something special. For example: by selecting text by mouse click&drag, lines containing the text are once again white and text visible. Other possibility is scrolling, lines that get out of scope will be fine.

I managed to fix this by calling Invalidate on this control but:

  1. I don't really understand why this is happening
  2. I have implemented search and selecting found words in the text but this graying still occurs instead of selecting first text. When selecting second word in that node and control, whole text box is again clean and working as it should but when going out and in with the search result situation repeats.

On the picture, you can see the rich text box between red fields (BG of dialog holding the controls). On the left the control is nice white control with text. On the right is the same control after search but grayed and after clicking into it and selecting some text with two "unrevealed" pieces of code.

Any advice why this is happening and/or how can I get rid of this behavior?

Compare fine state and messed up grayed state of RichtextBox

Strange thing is that when I experimented with some solutions Calling Invalidate() made it behaving well for some cases but calling UpdateWindow() after invalidate messed thing up again.

1
c++mfcrichtextbox
My guess is its something related to the tab control. Perhaps a z-order issue with the tab control behind the rich edit control? Is the rich edit a child of the tab control or a sibling? If you switch back to a CEdit do you have the same problems? Can you duplicate what order of events you need to do to get the display issue, or events that don't have the display issue? – uesp
RichEdit is child to dialog. Tab doesn't have any children (its there only to have something to click on and change text of edit box). It shouldn't be like tab is over edit box as I can select and change content of the editbox. What I do is: ActivateDlg (Select Correct Tab, UpdateData on dlg, ShowWindow - hide/show), SetFoccus, SetSel Maybe one more thing: when the control is going to be grayed for just a moment the content is showed as it should but is grayed after that brief moment (~0.5s) – Marcel Fyrgon Marciš
It is likely something specific to your app as a simple test with a rich edit over a tab control seems to work fine for me. Its going to be hard for anyone to give you specific advice without a SSCCE(sscce.org). I would do more testing in your program to see exactly what behaviour/events cause it and see if you can duplicate that in a short test program can could be posted here. – uesp
I'm not really able to reproduce it on small scale according to SSCCE (thx for the link anyway, might be handy) but I have a new repro for this. It also happens when I copy paste or write text into the richtextbox that is too long for it to show whole so it shows vScrollBar on the bottom edge. Text and the scrollbar are both grayed now. Control is defined as: CONTROL "",IDC_STATEEDIT,"RichEdit20A",ES_MULTILINE | ES_AUTOHSCROLL | ES_WANTRETURN | WS_VSCROLL | WS_HSCROLL | WS_TABSTOP,3,52,133,218 – Marcel Fyrgon Marciš

1 Answers

0
votes

OK I finally got it.

Sry for messing things here, looks like what I described problem wasn't really a clue to solve this.

I found the culprint behind all this in calling this CWnd method for my text box

SetWindowPos(&CWnd::wndBottom, 0, 0, width, height, SWP_NOMOVE);

When I've used MoveWindow(left,top,right,bottom,repaint) it was working fine but when I left at least one SetWindowPos (set some other control) it was screwed.

I don't really understand why this is such an issue for the CRichEditCtrl that was just OK for CEdit so if you know guys, let me know please.