Page 1 of 1

setFocusView( ) and setWantsFocus( ) with CTextEdit control

Posted: Wed Jan 04, 2017 6:55 pm
by willpirkle
I've had a drag-and-drop VSTGUI editor running for a few years now (Windows only, which is why I was curious about a standalone version for both Win/Mac). It currently has one issue that I have not been able to fix involving the CTextEdit control. In my software, when the user hovers the mouse cursor over the control, it will select the control with:


where m_pSelectedView is a CView* (here, the CTextEdit control). This places the red outline around the control as it should.

However, if the CTextEdit control is inside a CViewContainer, the CTextEdit control turns into a solid-filled rectangle with the text color filling the box. The figures here show what I am talking about:

Normal CTextEdit, no parent CViewContiner:
CTextEdit, inside of a CViewContiner with knob and label:
In both shots, the cursor is hovering over the control, or CViewContainer - it is invisible because of the screen capture operation.

Additionally, if the CTextEdit control is inside a CViewContainer that is inside another outer CViewContainer, selecting the outer CViewContainer will also cause the CTextEdit to become a filled rectangle. This is only ever an issue with the CTextEdit object - all other VSTGUI4 objects render as expected, including the related CTextLabel.

I've tried re-ordering the lines of code above, as well as omitting the setWantsFocus( ) call with no luck. Is there anything I can do to get rid of this selection anomaly?

Thanks in advance,


Re: setFocusView( ) and setWantsFocus( ) with CTextEdit control

Posted: Fri Jan 20, 2017 1:06 pm
by willpirkle
Though I still don't know why this is happening at the root level, I tracked it down to the CTextEdit::takeFocus( ) method; when the edit control takes focus while its parent is selected, it redraws the background, even if it is transparent, causing that block to appear. My solution was to subclass the control and disable the takeFocus( ) method -- this creates a "dumb" control that can not accept input, but in this application that is exactly what I need. It also prevents the control from trying to change the cursor from the arrow to the caret (for entering text) while the control is being touched/dragged. If there is a more elegant solution I'd love to hear it, but this solution is working for me now.

- Will