Welcome back to Interactive Controls and Layouts. We have reached Lesson 4, which is a significant milestone in the course: our window already displays controls, accepts typed input, and responds to button clicks. Now, we will connect those components so the interface can transfer text from one control to another.

In this lesson, we will read the current text from an edit control and place that text into a static label when the button is clicked. This is a small feature, but it teaches a very important concept in GUI programming: interactive data flow inside the window procedure.

The main logic still resides inside the window procedure. We begin the same way as before by checking which message arrived, then preparing the interface during WM_CREATE.

The function signature is the standard form for a WinAPI WindowProc. hwnd identifies the main window, and uMsg indicates which event Windows is reporting. When that message is WM_CREATE, the window is being set up for the first time. We also read the instance handle with GetWindowLongPtr because the child controls created in this branch require that GWLP_HINSTANCE value.

Once we have the instance handle hInst, we create the label, the edit box, and the button. The layout is familiar, but several details now support the text update behavior we want.

The starting text L"Waiting for input..." makes the label appear active even before any typing occurs. The EDIT control begins empty, providing a blank space to type. The button text, L"Update Label", clearly describes the action. Most importantly, each control receives its own ID through HMENU, so the parent window can later locate the specific controls it needs using GetDlgItem.

Now, we move to the interaction step. In the previous lesson, we learned that WM_COMMAND carries both the control ID and the notification code. Here, the code checks those values directly inside one condition.

This if statement is very precise. LOWORD(wParam) == ID_BUTTON_ACTION confirms that the message originated from our button, and HIWORD(wParam) == BN_CLICKED confirms that the event was an actual click. Once both tests pass, we use GetDlgItem to retrieve the child window handles.

The function GetDlgItem translates a control ID back into a usable HWND. It takes the handle of the parent window (hwnd) and the unique ID of the child (the HMENU value we passed to CreateWindowW). Although "Dlg" stands for "Dialog," this function works with any parent-child window relationship. This is a best practice in WinAPI development because it allows you to retrieve a handle exactly when you need it, rather than cluttering your application with global variables to store every button and label handle.

With the edit control handle ready, we need a place to store the text we read. In WinAPI, this usually involves preparing a character buffer and passing it to a text retrieval function.

wchar_t textBuffer[256] creates room for up to 256 wide characters. The use of wchar_t matches the Unicode version of the API, which is why the function name GetWindowTextW ends in W. Then, GetWindowTextW copies the current edit box text into that buffer. If the edit box is empty, the buffer will simply hold an empty string. If it contains text, the buffer acts as a bridge between input and output.

Once the text has been copied into the buffer, the final step is simple: send that same text to the static control. This is where the interface visibly changes.

SetWindowTextW replaces the label's current text with whatever is stored in textBuffer. Even though the label is a STATIC control, its displayed text can still be changed at runtime. Thus, if we type Hello into the edit box and click the button, the label changes from L"Waiting for input..." to Hello. That immediate feedback makes the window feel interactive.

In this lesson, we completed a full interaction cycle within the interface. We maintained the familiar layout, detected the button click with WM_COMMAND, located the edit box and label using GetDlgItem, copied the typed text with GetWindowTextW, and updated the label with SetWindowTextW.

This is a major step forward because the window is no longer just reacting to a click — it is now moving user data through the interface. In the upcoming practice tasks, we will reinforce this flow so that reading from controls and updating them feels natural and dependable.