A couple questions I have for anyone that knows WINAPI as Im trying to learn it right now..
I usually program in .Net Managed and the basic console stuff.

First: Is there a designer for WinAPI like there is in Visual Studio Form App Editor? Or is it just outright hard as hell?
Second: If there is no Form Designer, How do you know where to place buttons and stuff?
Third: Does everything I need to do go in: LRESULT CALLBACK WindowProcedure ? Because it really seems that way.. There is no "Body" to my program?

Fourth: How do I call a function in WinAPI? I don't want it in WinMain because it freezes my program..
Fifth: Where in the world do I put if-else statements.. In WinMain or the WindowProcedure thing?
Sixth: How do I make stuff execute in a specific order?? You know like in a console it goes:

int main()
  cout<<"This executes first\n";
  cout<<"This executes second.. \n";
  count<<"And finally I execute second to last..\n";
 return 0; //Last thing to execute.

Edited by triumphost: n/a

5 Years
Discussion Span
Last Post by caut_baia

First: there is, though not directly, you can use resource editor to create dialogs visually. just add new resources and visual studio (assuming you're using it) should show you a blank dialog with 2 buttons. just play around like you do in .NET

Second: Adding to the first, you can manually specify each controls' position in the desired window. For more details, look up CreateWindowEx() or CreateWindow in msdn.

Third: body is still winmain, however, all actions are handled in the callback function. if you notice, in the winmain, there's the message loop, this is the main loop of the application. So whenever you do something, the message is translated, then dispatched, depending on the message, an action is performed based on the stuff you have in the callback function.

Fourth: I'm not too sure if this is the best way since I'm also relatively new to WINAPI, but just do it like you always do. call the functions in callback() since that's where the action takes place after messages are dispatched.

Fifth: WindowsProcedure or the callback. actually, use switch case rather than if-else.

Sixth: order of execution is still the same. for example if you have this in one of your cases:

switch (message)
    case WM_COMMAND:
    switch (LOWORD(wParam))
       case EVENT_BTN_CLICKED:

      case CLOSE_WINDOW:
    return DefWinProc(hwnd,message,wParam,lParam);

when the event button is clicked (EVENT_BTN_CLICKED) the first function is called first then the second. I hope my code is accurate, I might have missed a thing or two.


If you use visual studio the structure of the program will already be created.A program must register a CREATESTRUCT structure in which you initialize a pointer the main window procedure and several other mandatory variables.Then the class is registered through the RegisterClassEx function.Then the window gets created with the CreateWindowEx function in which you specify the size of the window among other things.Next comes the message loop which dispatches the messages receieved by the window procedure from the operating system (WM_PAINT,WM_CREATE,WM_COMMAND etc).Keep in mind that everything you do must be declared in the body of the main window procedure in which everything takes place.When you create a button for example , which is just another window class , the handle of the window must be declared in the main procedure's scope.Initialization and creation takes place when the window receives a WM_CREATE message so that is where you must place your CreateWindowEx call with the specific arguments ("button" for example in case you create a button or "edit" in case of an edit control).To define an action that should take place in case you push the created button you must handle a WM_COMMAND message where you receive the window identifier of the button by extracting the low order word of the wParam argument given to the window procedure

   switch LOWORD(wParam)  {
      case BUTTON_ID:
         //call some function or whatever.

The program exits in case of a WM_DESTROY message and usually terminates with a call to PostQuitMessage(0).Also don't forget the call to DefWindowProc() which handles all the other message which you don't.There is much more but you should probably read Petzhod's book.Good luck

Edited by caut_baia: n/a

This article has been dead for over six months. Start a new discussion instead.
Have something to contribute to this discussion? Please be thoughtful, detailed and courteous, and be sure to adhere to our posting rules.