Whenever I resize my controls in my window, in response to a WM_SIZE message, they resize and redraw themselves fine. But my combobox control (a dropdown list) disappears whenever I give it a resize message, until I hover over it to bring it back.
There are two possibilities, either it is not redrawing when I resize it, or it is being hidden by my tab control. So how would I solve this problem?
I think the problem is probably the tab control hiding your control.
You can use SetWindowPos to set its z-order with specifying SWP_NOMOVE and SWP_NOSIZE.
You can also use BringWindowToTop to bring the combobox to the top of your z-order.
Related
Recently, I've got stuck over strange UI issue, found a solution, but still unsure about problem cause.
Preconditions:
MFC MDI application has 2 modeless dialogs opened, both has a child third-party grid and CToolTipCtrl. Dialog windows crosses each other borders (i.e. active dialog is overlapping part of inactive one). CToolTipCtrl is similar to example, the only tool set for tooltip is grid. Parent of tooltip is There is the corresponding dialog's grid, TTS_ALWAYSTIP style is set to allow tooltips on inactive dialog.
Issue:
When mouse is hovering on inactive dialog's grid, tooltip is appearing and inactive dialog is drawn over active one. In other words, inactive window is brought to top without activating. It's drawn completely, including caption, buttons, grid, etc.
I've checked Z-order and found that inactive dialog is still inactive, even when shown on top. No Z-order changed. Then I gathered message log using Spy++ for whole inactive dialog while tooltip is appearing and found no WM_ACTIVATE, WM_FOCUS, WM_MDIACTIVATE, etc. Then I performed search about how to bring window up without activating and logged SetWindowPos calls - the only calls are performed for CToolTipCtrl's window. So, no SetWindowPos for dialogs called. No BringToTop() called as well.
Solution
I've changed tooltip's parent window from dialog's grid to dialog itself - and that fixed problem. However, I still have no idea what was happened and why changing parent attribute matters.
Question
Could anyone give me a hint about what I'm missing? Maybe, tooltip causes repaint of grid, and that repaint has a bug causing repaint over active window, but I haven't found any proofs yet.
Haven't found something specific about tooltip's parent property in MSDN as well. Maybe, I have to read somenting about Windows GDI?
In MFC, I've made a resizing dialog in MFC and I put one control on a dialog like slider.
After the build, I found that the slider does not move when I resize the dialog.
So I made OnSize() then I set the position. It works.
However, there is one problem which is the different between control's first position and second position in Onsize().
So I want to make so that there is no difference in control's position between the first run dialog and after resizing.
How to set the control's initial position in dialog in MFC?
Ignore all WM_SIZE messages you receive until OnInitDialog is executed...
WM_INITDIALOG is fired when the dialog ist just before to be shown or was already shown (if it has the visible style).
I have created a borderless window using these styles: WS_VISIBLE | WS_POPUP | WS_OVERLAPPED
The problem is that the window can't be moved. I know that I could do something like getting mouse click position, and then calculate where the window would end up everytime there comes a WM_MOUSEMOVE.
But this solution is not stable, because when I move my mouse too fast, it gets out of the window, and then it won't react. I dont want to set up a hook, because they are too slow. I have searched the internet, but nothing came up at all.
What I ideally want to, is to create a window, that is able to be moved without borders or captions, where I don't need to track the mouse myself, but where Windows does it for me, like making the whole window a caption.
I know that I could do something like getting mouse click position, and then calculate where the window would end up everytime there comes a WM_MOUSEMOVE. But this solution is not stable, because when I move my mouse too fast, it gets out of the window, and then it won't react.
You can fix that by calling SetCapture when you receive the mouse click. You then will continue to receive WM_MOUSEMOVE even after the mouse cursor leaves your window. When the user is finished dragging and release the mouse cursor, you then should call ReleaseCapture.
What I ideally want to, is to create a window, that is able to be moved without borders or captions, where I don't need to track the mouse myself, but where Windows does it for me, like making the whole window a caption.
If you really want to do that, you could respond to the WM_NCHITTEST message and return HTCAPTION.
try PostMessage(hwnd,WM_SYSCOMMAND,SC_SIZE+9,0) on WM_LBUTTONDOWN.
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.
I have a window with its own H and V scrolling. I'm handling the event like this:
case WM_VSCROLL:
SetScrollPos(hWnd, SB_VERT, (int)HIWORD(wParam), TRUE);
break;
all I want is for the position of the scroll bar to stay once I release my mouse but what it's doing is just going back to the top after. What am I doing wrong?
Thanks
The wParam parameter of the WM_VSCROLL message is either SB_TOP, SB_BOTTOM, SB_PAGEUP, SB_PAGEDOWN, SB_LINEUP, SB_LINEDOWN, SB_THUMBPOSITION, or SB_THUMBTRACK, where the names ought to explain themselves.
SB_TOP and SB_BOTTOM means that the scrolling window is to go to the top or bottom, respectively. These messages can be sent by right-clicking a vertical scroll bar and selecting "Top" and "Bottom". (Look in Windows Notepad, Win XP+, for instance.)
SB_PAGEUP and SB_PAGEDOWN means a page (screen) up or down. These are sent if you click somwhere on the scrollbar beside on the thumb or the up or down arrows, or if you use the scrollbar's right-click menu.
SB_LINEUP and SB_LINEDOWN are sent when the user clicks the up and down buttons on the scrollbar, or selects the appropriate right-click menu commands.
SB_THUMBTRACK is sent continuously when the user scrolls by dragging the thumb of the scrollbar.
SB_THUMBPOSITION is sent when the user has released the thumb.
See the MSDN article WM_VSCROLL for more information.
So, when you receive a WM_VSCROLL message, you first need to do the scrolling itself. If, for instance, you are writing a text editor, then you need to redraw the text, but with a different row at the top of the window. Then you need to update the scrollbar to its new position, preferably by means of SetScrollInfo, but you can also use the old SetScrollPos function.
In the case section, the system is processing a WM_VSCROLL message. It will run the default window procedure after your SetScrollPos. In the default window procedure, the system itself will set the scroll bar's thumb position. So, although SetScrollPos takes effects, the system change the thumb position after that anyway. I think you should do your SetScrollPos after calling the default window procedure, i.e., maybe after returning this funciton, and then you can SetScrollPos.