I've created a popup window with SW_SHOWNA.
The problem is when I move the main window behind the popup window the popup window stays at the same place.
Is there any way to catch the click on the title bar (or other technique) of the main window behind the popup window and to close the popup window?
thanks a lot!
mike.
Yes, just do it. I would however not react to the click, as it makes your behavior mouse-bound. From your description, it seems you want to close the popup on a window move, so trap that message (WM_WINDOWPOSCHANGING) instead. This will catch keyboard-initiated moves as well.
Related
It is possible to set application-switching window as a Modal window (see definition)?
I mean, this window appears when I press Alt+Ctrl+Tab button at the same time and allows me navigate between opened applications typing "tab" key.
The problem appears when I push/click outside the window (Application-switching window lost focus and disappears).
Are there any way to avoid this problem in C++ MFC? I have tried calling:
CWnd* appSwitchingWnd = GetTopWindow();
appSwitchingWnd .SetFocus();
But it doesn't works...
I will appreciate any kind of help.
The question is for GTK+ programing in C++.
I have a main window with a button that activates a dialog window. The dialog window has OK and CANCEL buttons. I did it that way so when I hit the cancel button the dialog is closed. But once it is closed I cannot call it again with the button in the main window.
I have tried to call the dialog delete-event on the button click. I also tried to call the dialog destroy event when the button is clicked. But in both cases the dialog is destroyed and it does not show when I click the button that calls the dialog.
I suppose this is a follow up of your other question on the topic:
How to properly close a dialog made in Glade?
If it was created using GtkBuilder, if you destroy the window, it's really destroyed: GtkBuilder has created the widgets at parsing time, not when you call get_object, and won't create them again. So I think you should just hide the dialog with something like gtk_widget_hide_on_delete, and show it again when you click on the button in your main dialog.
I'm working on a themed ownerdraw button using Win32 native.
Following a tutorial and a sample project on another website, I got my button almost perfect(almost without bug), but there's one which left, and I have a issue in fixing it.
Basically, I'm subclassing using SetWindowLongPtr API the window of the button, and from there, when WM_LBUTTONUP is catched, I would need to call DrawThemeBackground for reset the state of the button, OR, just handle again WM_DRAWITEM. The problem is that WM_DRAWITEM is getting called only when my mouse is on the dialog window, which is not really a problem, if there would be a way for advice the main dialog to handle it when I want it. I tried with InvalidateRect, but it is not making WM_DRAWITEM, but WM_CTLCOLORBTN.
So, my question is:
Is there any way for let WM_DRAWITEM being handled even if the mouse is out of the dialog
OR
Is there any way for advice the main dialog that it should handle again WM_DRAWITEM, evne if the mouse is out of the dialog?
Thanks alot for taking your time in replyng me.
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've a popup window which I show with the SW_SHOWNA flag. If I click parts of this window, I catch the click and then close it, the problem is, there are other parts of the window and I don't want to close the window on click on them, but when I click them the window gets activated and gets the focus, that's bad for me, I want this window to stay not activated, and that other window will remind focused.
any ideas?
thanks,
mike.
If you handle WM_HITTEST and WM_NCHITTEST, watch for the points you're interested in, and return HT_NOWHERE for everywhere else, then I think the window shouldn't be activated (I haven't tested this theory).