Welcome back to Interactive Controls and Layouts. We are now in Lesson 2, and our application is starting to feel much more like a real desktop program. In the previous lesson, we placed a label and a button inside the main window. In this lesson, we will connect those two pieces with something essential: an Edit control.

By the end of this lesson, we will know how to create an Edit control, give it its own identifier, and style it so it looks like a proper input box. This is a very practical step, because once a program can accept typed text, it can start collecting names, search terms, messages, and many other kinds of user input.

A label can show information, and a button can trigger an action, but neither one can hold text that the user types. That is the role of the EDIT control. It is the standard WinAPI text box, and Windows already knows how it should behave, so we can create it by using the built-in system class name EDIT.

It helps to think of this control as a familiar input field from everyday apps. A search box, a login form, and a chat window all rely on text entry. In WinAPI, we add that same ability by creating another child window inside WM_CREATE. The interesting part is not just making it appear, but choosing styles that make it pleasant to use.

Before we create the new input field, we extend the list of control IDs. As we may recall from the previous unit, these IDs help us tell one child control from another. They become especially useful once we want to read the text later.

There are two things worth noticing here. First, #include <windows.h> still gives us access to all WinAPI types, messages, and functions. Second, ID_EDIT_INPUT is the new piece in this lesson. We assign it the value 103, which keeps it distinct from the label and the button. That unique value gives the text field its own identity inside the window, so later code can refer to the correct control without guessing.

Just like our earlier controls, the Edit control should be created when the main window itself is being set up. That is why we return to the WM_CREATE branch. We also retrieve the application instance handle exactly as before, because every child control creation call needs it.

This setup gives us the same solid starting point from the previous lesson. hwnd is the parent window that will own the controls, and hInstance identifies the running application instance. We do not create the input box somewhere random in the procedure; we place it in WM_CREATE so the interface is assembled in one clear stage. That makes the layout easier to understand, and it keeps the program structure clean as the window grows.

The text field will make the most sense if it appears under a short instruction. For that reason, the label from the previous lesson remains part of the layout. It gives the user context before they start typing.

Even though this line is familiar, it now has a clearer role in the interface. The label sits near the top of the window at position (20, 20), and it prepares the user for the text box that comes next. This is a small design choice, but it matters: controls feel easier to use when their purpose is explained right beside them. In other words, we are not just adding widgets; we are shaping a simple, readable flow.

Now we add the main feature of this lesson: the editable text box. This call creates a child window of class EDIT, gives it empty starting content, and applies styles that make it look and behave like a normal single-line input field.

This call is worth reading carefully, because each argument shapes the user experience.

1. L"EDIT" tells Windows to create the built-in text input control; L"" means the box starts empty.
2. WS_CHILD and WS_VISIBLE make it a visible child of the main window; WS_BORDER draws the box outline.
3. ES_AUTOHSCROLL lets the visible text shift horizontally when the typed content becomes longer than the field width. Without this style, a single-line Edit control will physically stop accepting new characters once the text reaches the right edge, rather than simply hiding the overflow.

Once the input field is in place, the button still belongs underneath it. This keeps the interface arranged in a natural top-to-bottom order: first the instruction, then the place to type, then the action to submit.

This part is mostly unchanged from the previous lesson, but its meaning is stronger now. Before, the button existed without any input to act on. Now it sits below a real text field, so the interface begins to resemble a form. The return 0; at the end is also important: it tells Windows that WM_CREATE has been handled successfully, and the child controls were created as intended.

The rest of the procedure handles closing and destruction in the same way as before. Even though this logic is not new, it is still part of the finished program, so we should keep it in view as the interface grows.

Here, WM_CLOSE starts the shutdown by calling DestroyWindow(hwnd). After the window is actually being destroyed, WM_DESTROY posts a quit message so the main message loop can exit. Finally, DefWindowProcW handles every message we do not process ourselves. That default call remains essential, because it preserves the standard behavior Windows expects from a normal application window.

In this lesson, we expanded our interface from simple display and action controls into something interactive. We kept the label and button from the previous unit, added a new control ID, and created an Edit control with CreateWindowW. We also used WS_BORDER to make the field look like an input box and ES_AUTOHSCROLL to keep typed text usable even when it becomes longer than the visible width.

This is an important step in WinAPI development, because text input is at the center of many desktop programs. In the practice tasks ahead, we will reinforce this pattern so we can place editable fields with confidence and start building windows that truly respond to user input.