The tooltip docs say that
A tooltip control always has the WS_POPUP and WS_EX_TOOLWINDOW window
styles, regardless of whether you specify them when creating the
control.
Meanwhile, the way to custom draw a tooltip is through WM_NOTIFY/NM_CUSTOMDRAW, which would require a parent.
So how is custom-draw performed if the tooltip is always a popup?
Related
I am building and maintaining a Win32 app using Visual Studio.
I have recently edited the .rc file adding WS_THICKFRAME to my dialog STYLE line for all dialog windows to allow them to be resizable.
My current problem is, when I resize a window, its content remains fixed to the left. How can I make the window's content remain centered when resizing using the border?
Pointing to any relevant documentation on this would also be helpful, as I have not had lucky finding that.
If you only want to reposition (rather than resize) the individual controls, an easy way would be to create a non-modal container dialog to hold the controls, make that dialog a child of the resizable dialog, and then when you handle WM_SIZE for the outer dialog, you only have to reposition that one non-modal dialog.
Your new position is ((newWidth- controlDlgWidth) / 2, (newHeight-controlDlgHeight)/2), where controlDlgWidth, controlDlgHeight are the width and height of the child dialog.
I say to use a non-modal dialog for this, so that you can continue using a resource script, rather than needing to add a whole bunch of explicit CreateWindow() calls.
Background: In a certain dialog there are several controls in a row. I would like all of them to have the same apparent height. However for a combobox with the CBS_DROPDOWNLIST style and no CBS_OWNERDRAW* I am having trouble changing the apparent height.
Question: How can I change the apparent height of such a DROPDOWNLIST combobox?
I am aware that the combobox does not allow changing the height with SetWindowPos. I was however under the impression that sending a CB_SETITEMHEIGHT message with wParam= -1 should modify the height. This method does work for comboboxes with the CBS_OWNERDRAWFIXED style set (I wanted to avoid setting this style though to preserve the "button-like" look).
Environment: My Win32 application uses Common-Controls 6.0 and I am concerned about the appearance in an environment where visual styles are enabled (Windows 7, Aero).
I don't think this is possible.
As you mention, neither SetWindowPos nor MoveWindow work like you expect. That's because the height of a ComboBox includes the height of the drop-down. The control automatically resizes itself according to the size of the font it uses. So to change the size, change the size of the control's font by sending it a WM_SETFONT message.
But I don't understand why this is a problem. You say that you want a series of controls to have the same height, but unless you're changing the height of the other controls, they should already match. Since all controls on a dialog generally use the same font, combo boxes and text boxes should all have the same height already. When you use v6 of the common controls and Visual Styles are enabled, they'll be applied to all of these controls and they should have a uniform appearance. You shouldn't have to mess with the heights manually.
I tried SetMenuInfo with MIM_BACKGROUND, but it doesn't work. I found it is because the Visual Style is enabled. But I don't want to disable the Visual Style by SetWindowTheme(hwndMain, L"", L"") becauuse it will change the appearance of the title bar and border...etc.
Is there any way to change, and only change the background color of the menu bar, without disalbe Visual Style of the main window. By "only change", I also mean that I don't have to draw the menu items myself, like I can use custom draw for change only the background color of toolbar, tab...etc. (But I can find custom draw for menu bar!).
You just set MainMenu's OwnerDraw Property to true, and Menu is automatically close Menu's theme, but don't close Window's theme!
With themes there is no official way to change the color. However you can take advantage of some undocumented window messages to implement the custom drawing yourself. https://github.com/adzm/win32-custom-menubar-aero-theme
I have created a custom (themed) NSWindow, by creating a borderless window and then recreating all elements of the window border/background inside the content view. I've created the window widgets (close box, zoom box, minimize box) on top of my own fake title bar using -standardWindowButton:forStyleMask:.
Trouble is, when a sheet is presented on top of my custom window (e.g. "save changes...", those buttons do not receive the clicks.
Does anybody know how I can tell NSWindow not to intercept the clicks in my minimize box? It works with a standard NSWindow. When a sheet is up, I can still send both of them to the dock, or zoom the window out.
I thought maybe there's special code in the content view that ignores clicks in subviews while a sheet is up. But it seems as if -hitTest: is called on the content view and returns the minimize widget, but the widget's action never gets triggered.
I guess I could just replace the content view and perform the action in the content view's hitTest if it is the minimize widget ... but that seems a bit ugly.
I created a tab control with TCS_TOOLTIPS style, hence when mouse is over tab items, it displays a tooltip which shows some information.
The tooltip always has the same x-position as the cursor and below the cursor.
I want to make the y-position of the tooltip exact at the bottom of the tab control. In this case, I need to increase the x-position of the tooltip also, in order to avoid the cursor and the tooltip overlap.
But I can not find any information to adjust the position of a tooltip of a tab control.
Is this related to TTM_TRACKPOSITION flag of TOOLINFO? When I created this tab control, I knows only : get hwnd of tooltip by sending TCM_GETTOOLTIPS message ; Treat WM_NOTIFY message and fill TTN_GETDISPINFO structure to display the tooltip. But I didn't find any information about the position.
Sub-class the tooltip control and modify it's position by catching the WM_WINDOWPOSCHANGING message.