in c# we can use IntPtr hWnd = this.Handle to get the window handle that the control is bound to.
which control we can use in vb6 to gets the window handle that the control is bound to?
You can use the hWnd property of the Form object to get the window handle of the form or control.
Dim hWnd As Long
hWnd = Form1.hWnd
You can also use the hWnd property of other controls, such as buttons, labels, and text boxes, to get their window handles.
Related
I have such 3D scene in a window which was created using GLFW:
Now I'd like to have some buttons and lists and input fields in here too. WinAPI provides those. How do I achieve this and add controls to my window?
I checked the Internet, and I don't see much questions about using WinAPI controls with GLFW window. As far as I remember, GLFW does not appreciate when someone tries to snatch HWND of its window (I think, it's protected, since they strive for cross-platform implementation of their library). I have seen a question when someone tried to embed a GLFW window into another window, which does not fit my idea. I completely appreciate if GLFW handles an input on scene - mouse clicks on scene, drags, key presses and other events, but controls, of course, should be reachable as well. Alternatively I may go with Dear ImGui, and use those controls in my window, if adding WinAPI controls to GLFW window appears too complicated.
You have to do a better research. Instead of checking the Internet, why didn't you just visited the most relevant sites: WinAPI and GLFW
As far as I remember, GLFW provides a Native access.
For example, to create a button, you'll need the HWND of the parent window (see here):
HWND glfwGetWin32Window(GLFWwindow *window);
and then (see here)
HWND hwndButton = CreateWindow(
L"BUTTON", // Predefined class; Unicode assumed
L"OK", // Button text
WS_TABSTOP | WS_VISIBLE | WS_CHILD | BS_DEFPUSHBUTTON, // Styles
10, // x position
10, // y position
100, // Button width
100, // Button height
m_hwnd, // Parent window
NULL, // No menu.
(HINSTANCE)GetWindowLongPtr(m_hwnd, GWLP_HINSTANCE),
NULL); // Pointer not needed.
After you've created the button, listen to the incoming events and act properly.
I have a main window which allows to display a child modal dialog. That dialog window is created based on the resource file using DialogBox function. It contains a few controls and a horizontal splitter which are repositioned/resized when handling WM_SIZE and WM_MOUSEMOVE messages. I use BeginDeferWindowPos, DeferWindowPos and EndDeferWindowPos functions. It looks like that everything is repainted correctly. Should I also call InvalidateRect after EndDeferWindowPos ? Is there any scenario where it may be necessary ? I don't handle WM_PAINT message.
The documentation for the DeferWindowPos function would strongly suggest that, so long as you don't have the SWP_NOREDRAW bit set in the uFlags argument, you do not need to call InvalidateRect after you have called EndDeferWindowPos:
SWP_NOREDRAW 0x0008 Does not redraw changes. If this flag is set,
no repainting of any kind occurs. This applies to the client area, the
nonclient area (including the title bar and scroll bars), and any part
of the parent window uncovered as a result of the window being moved.
When this flag is set, the application must explicitly invalidate or
redraw any parts of the window and parent window that need redrawing.
What is the difference between WindowProc and CallWindowProc ?
I can imagine when registering a new window class I can specify my own WindowProc for it.
This leaves the question: When and what for do I use CallWindowProc ?
When you subclass a window using SetWindowLong/Ptr(GWL_WNDPROC) to assign a new WindowProc() to the window, the replacement WindowProc() uses CallWindowProc() when it needs to call the window's original WindowProc():
Subclassing a window
The preferred way to subclass a window is to use SetWindowSubClass() instead:
Safer subclassing
See msdn. CallWindowProc is used for subclassing.
I have a parent window (MFC dialog) with some controls on it (editbox, button, etc.), which looks like this:
At runtime (OnInitDialog), I create another child window which covers and hides all the other controls in the dialog, using this code:
RECT r;
GetClientRect(&r);
m_layer.Create(NULL, NULL, WS_CHILD | WS_VISIBLE, r, this, 0);
The m_layer object is an instance of a class CLaywerWnd inherited from CWnd. In this class I override the following method:
BOOL CLayerWnd::OnEraseBkgnd(CDC* pDC)
{
CBrush b(RGB(0, 100, 100));
RECT r;
GetClientRect(&r);
pDC->FillRect(&r, &b);
return TRUE;
}
Now my window looks like this:
The problem is that when I move the mouse cursor or click on this new child window the messages are forwarded to the parent window (I checked this using Spy++), and the other child controls are redrawn over the new child window, like bellow.
I don't understand why this happens and I want to know how to avoid this behavior.
I may well be wrong, but I wonder if you've mixed up in your code the handles to the two dialogs, such that you're posting messages to the wrong dialog?
One easy way to avoid it takes two steps:
Change the state of all the hidden controls to disabled, so they won't react to any messages.
Make sure the overlay window is at the top of the Z-order. You can do this when you create the window or later using SetWindowPos.
How can I get the same effect as SetLayeredWindowAttributes for windows created with WS_CHILD style? Is there any workaround? From MSDN:
To create a layered window, specify the WS_EX_LAYERED extended window style when calling the CreateWindowEx function, or call the SetWindowLong function to set WS_EX_LAYERED after the window has been created. After the CreateWindowEx call, the layered window will not become visible until the SetLayeredWindowAttributes or UpdateLayeredWindow function has been called for this window. Note that WS_EX_LAYERED cannot be used for child windows.
The child window cannot be layered - this style has effect for the windows with WS_POPUP style only. One possible way (not so elegeant) to resolve this problem is create a window with WS_POPUP style and syncronize its position when the "parent" window is being moved.
Before you set transparent of child do it:
First set for the MDI Main window of it (SetWindowLong & SetLayeredWindowAttributes),
then it will work for the child directly .