Child window (CEdit) losing focus - c++

I am programming in C++ using MFC Document/View architecture. I have been trying to achieve something similar to MFC CEdit lose focus handler. I processed the message EN_KILLFOCUS as the answer suggests.
Basically, I'm doing this: I have text drawn in the view. When the users clicks the area of the text in the view, I position and show the CEdit window on top of it so users are able to edit the text. When the edit loses focus, I get the CEdit text and save it in the document. Then invalidate the view.
However, I seem to only receive the EN_KILLFOCUS message when the view loses focus. I have to click somewhere else, e.g. a docking window, or the toolbar, to make the CEdit lose focus. I want it to happen when I click anywhere else on the view, outside the CEdit box.
I am creating the CEdit with WS_CHILD style. I tried WS_POPUP but still the same problem.
Any help would be appreciated.

Create a CEdit derived class/control. And create an instance of this class in your View
Handle the EN_KILLFOCUS in the derived class. You will be able to handle this message once user clicks outside the edit control window.
Keep your editbox as WS_CHILD.
Set focus to view on view's mouse down, call SerFocus() on view's LButtonDown.

Related

Win32: Combobox loses focus when clicking its child window

I have a c++ Win32 application with a node-based GUI where I create a dynamic combobox with CreateWindowEx when the user presses a certain key within the GUI. I want the user to be able to click outside of the combobox Rect in order to make the combobox disappear.
To do this, I'm currently destroying the combobox inside a WM_KILLFOCUS notification of its DlgProc (so any click outside of it destroys it). However, it seems that the WM_KILLFOCUS notification is sent anytime one of its child windows gains focus. For example, if I click in the combobox's edit text region, the combobox itself loses focus since that child gains focus. Given my setup, this causes the combobox to be removed when clicking within it's Rect.
How can I prevent this behavior? Basically I want to be able to detect when anything other than the combobox or its child windows gains focus, rather than simply detecting if the combobox itself loses focus.
You can determine, whether focus moves to a different control from inside the WM_KILLFOCUS handler. This message receives
[a] handle to the window that receives the keyboard focus.
through its wParam argument.
Use the CB_GETCOMBOBOXINFO message to retrieve a COMBOBOXINFO structure, that contains window handles to all contributing windows (hwndCombo, hwndItem, and hwndList). Comparing the wParam value to all of those window handles allows you to determine, whether focus moves inside the combo box or outside.
While this answers the question that was asked, the real solution would be to handle the CBN_KILLFOCUS notification instead. It is sent to the control parent when the combo box loses keyboard focus, ignoring focus change events internal to the combo box control.

scrollbars of a CScrollView in a CDockablePane are disabled

I've designed a toolbox control. It's inside a CDockablePane object. Since the tools inside it may need to be scrolled, I've created a CScrollView as a child of the pane and have inserted the tools inside it as children. Based on the pane size, scrollbars of the CScrollView object appear properly, but clicking on them doesn't scroll the view. It seems that they're disabled. When I use SS_NOTIFY style when creating the CScrollView, the CScrollView object receives mouse clicks, but when i don't use the style, it doesn't. But it seems that the scroll bars inside the view control don't receive clicks. When mouse hover over them, no visual effect in scroll bars appears. It seems that the scroll bars are disabled, while I've not created nor manipulate them.
What's wrong?
mouse wheel works. click on scrollbars is received by the scroll view, not by the scrollbars. inside handler, i wrote this code:
CScrollBar *pScroll = GetScrollBarCtrl(SB_VERT);
if (pScroll->GetSafeHwnd())
{
...
if is not true. this means that the scroll view has not a scroll bar, but if so, how is it shown?!
any idea?
...
since i didn't get answer, i'm going to clarify my question with a sample code:
https://dl.dropboxusercontent.com/u/4829119/930501%20-%20t3.zip
in this sample, how can i scroll my view as i do with other views like class view and file view?
the sample code screenshot:
https://www.dropbox.com/s/7pu5chpyj9hqeal/Screenshot%202014-07-23%2003.40.26.png
Did you initialize by calling SetScrollSizes? The scroll bars are enabled only when the sizeTotal is larger than the view window size.

MFC floating CDialog control clipping issue

I am making an SDI MDF application that uses a frameview to provid the user with a set of controls (buttons, editboxes and such). The view also owns a set of CDialogs used to desplay aditional controls that can be can be shown or hidden via a tabcontrol and other means. Untill recently the dialogs have been staticly placed at creation to be in their proper location on the screen but I wanted to add a dialog that the user could move around but is still a child of the view. When I created a dialog with a caption and sysmenu that the user can move around the issue I am running into is that when the window is placed over another control owned by the view, (lets say a button) when the paint method is called on the button, it draws over the dialog. The dialog is still on top and the dialogs controls can still be interacted with but the button is drawn over them untill the dialog is repainted. I have tryed to change the clipchild and clipsiblings settings of the dialog and have been able to get the dialogs to properly clip eachother but can not seem to get the child dialog to properly clip the parent view controls. Does anyone have any ideas on what setting might fix this clipping issue.

Use dialog controls without stealing focus

I have a modeless CDialog that contains controls, some CButtons and a CScrollbar. The CDialog is parented off of an edit box that I want to keep focus at all times. The problem is that whenever the user uses the controls, clicking a button or on the scrollbar, the control steals focus from the edit box, causing both the parent window to draw without focus (grayed-out header bar), and causing the control to take all the keyboard input. Is there a way for the controls to respond to mouse actions but not steal focus?
The controls and the dialog are all created with WS_CHILD. The controls are parented off the dialog, and the dialog is parented off of the edit box.
I've tried setting focus back after the controls are used, but that causes the parent window to flicker as it loses and then regains focus. Basically I want something that works like a combo box, where the scroll bar can be clicked or dragged around, but keyboard input still goes to the dialog itself, not just the scroll bar, and the whole thing never loses focus.
I haven't done anything like this for a long time, so I'm sure there are a million little details, but I think the starting point is to override the handling of WM_MOUSEACTIVATE.
I am a little confused about child-parent relationship you described.
Can you explain what do you mean by:
The CDialog is parented off of an edit box that I want to keep focus at all times
Any window hosting other windows inside of the client area is a parent of those windows. It is impossible to create window without WS_CHILD that is contained by other window.
Therefore all dialog’s controls are children of this dialog. It is also possible that child window hosts another child window.
CDialog is just an MFC representation of a dialog window; the same applies to other controls. For example CButton is an MFC class that wraps handle of the window’s window that is predefined as window button control.
Dialog never has focus unless is empty (does not have any controls). If dialog contains even one control, this control always has focus.
What focus means is that any given window receives mouse and keyboard messages. Only one control can have focus at any given time. In order for scroll bar to process mouse click or keyboard to move slider, scroll bar must have focus; therefore some other control must give it up.
Combo box drop box (I think this is what you are referring to) is not a child of the dialog. It is a popup window that for the duration has keyboard focus and captures mouse. When it drops down, dialog is deactivated and once dropdown hides, dialog state is changed back to active hence focus never changes, it returns to the control that had focus when dialog was deactivated.
What you are trying to do is probably possible but it would require a lot of coding. Probably hooking messages would do the job but I think it would be going against the stream.

Custom dropdown for CComboBox

I'm trying to create a custom dropdown for a derivative of CComboBox. The dropdown will be a calendar control plus some 'hotspots', e.g.
So I figure the best way to achieve this is to have a simple CWnd-derived class which acts as the parent to the calendar control, and have it paint the hotspots itself.
The window needs to be a popup window - I think - rather than a child window so that it isn't clipped. But doing this causes the dialog (on which the combobox control is placed) to stop being the topmost (foreground?) window, leading to its frame being drawn differently:
alt text http://img693.imageshack.us/img693/3474/35148785.png
This spoils the illusion that the dropdown is part of the combobox since its acting more like a modal dialog at this point. Any suggestions on how I make the custom dropdown behave like the regular dropdown?
Are there any other pitfalls I need to watch out for, e.g. focus and mouse capture issues?
When you create your popup window, you need to specify its owner. Owned popup windows will activate their owner when you activate them. Not specifying an owner will cause your window to get activated, which causes the change in the owner you're seeing.
Yeah I had this problem once. A quick google makes me suspect I solved this by using CreateWindowEx() and specifying WS_EX_NOACTIVATE. I have some other code that achieves the same effect by making the window with WS_EX_TOOLWINDOW rather than as a popup window, but I'm not sure of why that was done that way, my intuition would say that making it a popup window would be the way to go.
You can find in the following links two sample project that put in the CComboBox dropdown window a CTreeCtrl or a CListCtrl controls ... similar, you can put whatever you need there. Here is the links:
Tree ComboBox Control
and
List ComboBox Control
I hope this help you.