Public Group

# Hi Need some help understanding this function :o)

This topic is 2758 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi!

Well some of you may remember I posted a lot of topics recently about callback functions. Well I got the answers I needed to roughly understand how they work from 10,000 feet but now I am actually trying to understand the guts of this particular callback function itself. It is rather large as it is the interface where users can choose which graphics device they want to use to run the graphics engine.

It's a monster to be honest so I'm going to analise it piece by piece. It starts off with some declarations then proceeds to fill out some handles with the GetDlgItem function which I assume is native to windows? Then it really begins when it initiates a switch statement with three possible cases, and one nested switch statement.

Here's the first part:
#include <windows.h>ZFXDEVICEINFO g_xDevice; // user defined variable typeD3DDISPLAYMODE g_Dspmd; // not sure if this variable type is defined in DirectXD3DFORMAT g_fmtA; // not sure if this variable type is defined in DirectXD3DFORMAT g_fmtB; // not sure if this variable type is defined in DirectX// this part is weird I thought CALLBACK's were supposed to// return a variable of type INT_PTR ?BOOL CALLBACK ZFXD3D::DlgProc(HWND hDlg,                              UINT message,                              WPARAM wParam,                              LPARAM lParam){    DIBSECTION  dibSection;    BOOL        bWnd = FALSE;    //get Handles    HWND hFULL          = GetDlgItem(hDlg, IDC_FULL);    HWND hWND           = GetDlgItem(hDlg, IDC_WND);    HWND hADAPTER       = GetDlgItem(hDlg, IDC_ADAPTER);    HWND hMODE          = GetDlgItem(hDlg, IDC_MODE);    HWND hADAPTERFMT    = GetDlgItem(hDlg, IDC_ADAPTERFMT);    HWND hBACKFMT       = GetDlgItem(hDlg, IDC_BACKFMT);    HWND hDEVICE        = GetDlgItem(hDlg, IDC_DEVICE);    switch(message)    {        // preselect windowed mode        case WM_INITDIALOG:        {            SendMessage(hWND, BM_SETCHECK, BST_CHECKED, 0);            m_pEnum->Enum(hADAPTER,                          hMODE,                          hDEVICE,                          hADAPTERFMT,                          hBACKFMT,                          hWND,                          hFULL,                          m_pLog);            return TRUE;        }    ......}
Ok quite a function, and this is only the start of it. I have the following questions:

1)How exactly does a CALLBACK function work? What calls it? I'm guessing that it can be triggered either by a change in user input, or it can be/is called when the dialog box initiates, hence all this initiation that's going on above. Is this correct?

2)I believe that the large block of HWND declarations with the GetDlgItem is linking stuff defined in the resource.h file with these handle declarations. The hDlg being a handle to the file/window (not sure which) which contains the relevant resource data. I am correct here?

3)The switch(message) part is obviously initiated when the function is called. Is the case WM_INITDIALOG: part a windows variable that is passed to the function whn the dialog box is initiated?

4)What does the SendMessage(hWND, BM_SETCHECK, BST_CHECKED, 0) function do? I don't recognise the BM_SETCHECK or BST_CHECKED variables what are they? They showed up as recognised words in my IDE so I guess these are windows specific variables - but I don't know what they are or how they relate to the SendMessage call.

5)Is it ok to have a callback return a BOOL variable? I thought it should be INT_PTR although I don't even know what an INT_PTR variable is.

That's enough for now or I'll get overwhelmed. The final part - the mpEnum stuff I'm ok with for now as it is an instance of a user defined class called ZFXD3DEnum which I think is responsible for storing the user's inputs. I'm not toally sure about this for now, but it's ok to skip this bit fo the time being, mainly because this is very specific to the book I'm working with and I wouldn't expect anyone to know anything about that - that's up to me to find out ;o)

Thanks in advance, as always for any help anyone can offer - cheers and Merry Christmas ;oD ;o)

##### Share on other sites
As suggested in some of your other posts, if you want to learn the Windows API, you really should get good docs for it, such as Windows Programming by Petzold.

In addition, Microsoft has page after page of information on the Windows API.

In addition, assuming you're using something like Visual Studio and have an SDK, all of the functions and constants are described (similar to msdn) in the SDK documentation.

In addition, googling for "windows dialog box" results in over 15,000,000 hits, many of which describe the very concepts you're asking about.

Just to get you started, the dialog procedure is essentially the same as a window procedure, except it's for a dialog. It's not any more of a "monster" than most window procedures.

##### Share on other sites
I was hoping to God I would be able to avoid buying any more text books or trawling online to get past this latest hurdle, but it seems you are right - I am going to have to get that book. I'll try doing some Google research but I think I'll opt for that textbook instead I always find them more appealling for some reason than doing online research.

Thanks ;o)

##### Share on other sites
Quote:
 Original post by adder_noirHi!Well some of you may remember I posted a lot of topics recently about callback functions. Well I got the answers I needed to roughly understand how they work from 10,000 feet but now I am actually trying to understand the guts of this particular callback function itself. It is rather large as it is the interface where users can choose which graphics device they want to use to run the graphics engine.It's a monster to be honest so I'm going to analise it piece by piece. It starts off with some declarations then proceeds to fill out some handles with the GetDlgItem function which I assume is native to windows? Then it really begins when it initiates a switch statement with three possible cases, and one nested switch statement.Here's the first part:*** Source Snippet Removed ***Ok quite a function, and this is only the start of it. I have the following questions:1)How exactly does a CALLBACK function work? What calls it? I'm guessing that it can be triggered either by a change in user input, or it can be/is called when the dialog box initiates, hence all this initiation that's going on above. Is this correct?2)I believe that the large block of HWND declarations with the GetDlgItem is linking stuff defined in the resource.h file with these handle declarations. The hDlg being a handle to the file/window (not sure which) which contains the relevant resource data. I am correct here?3)The switch(message) part is obviously initiated when the function is called. Is the case WM_INITDIALOG: part a windows variable that is passed to the function whn the dialog box is initiated?4)What does the SendMessage(hWND, BM_SETCHECK, BST_CHECKED, 0) function do? I don't recognise the BM_SETCHECK or BST_CHECKED variables what are they? They showed up as recognised words in my IDE so I guess these are windows specific variables - but I don't know what they are or how they relate to the SendMessage call.5)Is it ok to have a callback return a BOOL variable? I thought it should be INT_PTR although I don't even know what an INT_PTR variable is.That's enough for now or I'll get overwhelmed. The final part - the mpEnum stuff I'm ok with for now as it is an instance of a user defined class called ZFXD3DEnum which I think is responsible for storing the user's inputs. I'm not toally sure about this for now, but it's ok to skip this bit fo the time being, mainly because this is very specific to the book I'm working with and I wouldn't expect anyone to know anything about that - that's up to me to find out ;o)Thanks in advance, as always for any help anyone can offer - cheers and Merry Christmas ;oD ;o)
For what its worth, this link from MSDN has some good information on Dialog Boxes.

1. Generally the OS will initiate these types of CALLBACK functions. For a more general look Wikipedia has a good synopsis.

2. Yes, usually. It is possible to do this programmatically though (covered in the first link above).

3. The switch is based on the "message" parameter of the CALLBACK function as you noticed. Windows defines hundreds of events that can be generated. Its possible to make your own user-defined events! MSDN of course has lots to say on the matter. In the first link I provided above WM_INITDIALOG would likely be sent very soon after you call "DialogBox" or "CreateDialog", as the case may be. However it happens is an implementation detail and if it matters it will be documented.

4. Adds a message to the message queue for the associated window handle (in this case hwnd is probably for a checkbox based on the type of message being sent. In fact, each of those HWND variables are probably for different checkboxes for different checkbox options. When the Dialog Box is initialized that code probably sets a particular checkbox to Checked. Based on these assumptions I would further guess that m_pEnum->Enum holds all of those HWND variables and checks for the checkbox state of each checkbox in order to set the options when the dialog box closes/is applied.

5. BOOL is apparently incorrect according to MSDN although it will work for 32-bit applications. For 32-bit applications BOOL and INT_PTR are typedefs for the same variable: int. If compiling as a 64-bit application INT_PTR becomes a typedef for '__int64' while BOOL remains of type int.

##### Share on other sites
Download the MS SDK and learn to use the documentation. It's worth 100 books on windows programming, not to say that Petzold book will not be worth your money. It definitely is. You may want to get a book on C/++ programming though first and lower your ambition slightly.

Not to insult but being frank, you are still battling with general programming, but you are attempting to understand a pretty complex bit of code. Windows programming is a challenge to learn for practiced programmers and DirectX is just (alot) more fuel on the fire.

Take a step back and work on developing your general programming skills further.
Callbacks are a fairly advanced concept, so I would not expect you to 'figure it out yourself', but given the complexity of the code you are asking about, I would expect you to know how to lookup definitions in your source code or API documentation for things like WM_INITDIALOG, SendMessage, BM_SETCHECK, BST_CHECKED and INT_PTR. This tells me you aren't quite ready for Windows programming, definitely shouldn't be confusing yourself with DirectX yet and maybe you should even avoid C++ for now and stick to C.

SDL is a great way for you to get wet without having to dive in head first.
It is FAR simpler to deal with than Windows GUI and DX, and cross-platform too as a bonus.

In any case, I strongly suggest you hone your search-fu and accept the fact that the internet is your best source for information to learn programming. If books are how you learn best, that's great but they do not even come close to the value and breadth of all the info at your fingertips.

I apologize if this all sounds like an attack. It is not, but hopefully constructive advice for you. I'd be happy to help you in the right direction if you send me a private msg, but it is pretty clear that you are biting off more than you can chew with the code you posted.

Merry Christmas. Cheers!

##### Share on other sites
Quote:
 Original post by GaticusNot to insult but being frank, you are still battling with general programming, but you are attempting to understand a pretty complex bit of code. Windows programming is a challenge to learn for practiced programmers and DirectX is just (alot) more fuel on the fire.

That's positively a relief to hear! I thought I was up against it quite a bit, it's nice to hear it confirmed by someone with much more expertise!

I've had quite a good introduction to DirectX as that's where I started learning C++ - weird route I know but it's a long story!

I've read alot of beginner's books cover to cover and I'm ok with things like abstract classes used as interfaces with pure virtual functions and stuff like that. Hitting windows stuff though has been like being introduced to real man's programming and as you say I am finding it very difficult.

I had hoped I would be able to just understand this dialog box stuff only and then progress onwards with my book, but it seems destiny is steering me towards having to learn alot more of the windows specific stuff than I'd wanted to. I think it's time to maybe invest more faith in online searching and downloading some SDK's - not really something I'm familiar with as all my education was done the old fashioned way with books - most of the time there wasn't a computer in sight! ;o)

I don't have much if any choice at the moment I simply have to go on I'm not at a time in my life where I can back off something because it's hard.

I'm going to take your advice and start doing some online research and I'm going to order Petzold's book too. Guess there's no easy way around this one but to accept I will have to follow a bit of a diversion from my original plans into windows specific stuff here.

@nobodynews - thanks for a very detailed and helpful reply (as always!) that will go a long way towards aiding my understanding.

Ok I'm off to go do some research and some more work. If I have anything useful to post I will return here with some sort of progress report rather than a heap of questions I can probably fnd the answers too myself with a bit of faith ;o)

Thanks & Merry Christmas ;o)

##### Share on other sites
Quote:
 Original post by adder_noirI've had quite a good introduction to DirectX as that's where I started learning C++ - weird route I know but it's a long story!

Unfortunately it's not weird, but it's a steep learning curve. You have to experiment with what interests you though. Nobody is interested in making 1000 variations of hello world :)

Quote:
 Original post by adder_noirHitting windows stuff though has been like being introduced to real man's programming and as you say I am finding it very difficult.

I'd say it's more like peering inside an insane mans brain. :P
The biggest headache about windows programming is that there is so many different ways to accomplish the same thing. This is the same reason why I don't recommend relying on books as a primary source. They are by nature, always dated information and offer you only a single perspective.

Quote:
 Original post by adder_noirI don't have much if any choice at the moment I simply have to go on I'm not at a time in my life where I can back off something because it's hard.

I did not mean you should give up, certainly not. I mean you should reconsider your learning path. Sometimes it's faster to go around the mountain than over it.

There is nothing that demands you use OOP to learn windows programming for example. IMO, C++ is just alot of boiler plate and abstraction when you are still trying to learn core programming concepts. Same is true about windows dialog's and resources. As well, callbacks are not specific to windows programming, or C++. You can experiment with them without having to confuse yourself with DX and GUI code at the same time.

Just try to simplify whatever it is you are trying to examine. What is the simplest code you can make to demonstrate the concept you are experimenting with? This is an essential practice for programmers. For learning, for development and for debugging.

##### Share on other sites
Quote:
 Original post by adder_noirWell some of you may remember I posted a lot of topics recently about callback functions. Well I got the answers I needed to roughly understand how they work from 10,000 feet but now I am actually trying to understand the guts of this particular callback function itself. It is rather large as it is the interface where users can choose which graphics device they want to use to run the graphics engine.It's a monster to be honest so I'm going to analise it piece by piece. It starts off with some declarations then proceeds to fill out some handles with the GetDlgItem function which I assume is native to windows? Then it really begins when it initiates a switch statement with three possible cases, and one nested switch statement.Here's the first part:*** Source Snippet Removed ***Ok quite a function, and this is only the start of it. I have the following questions:1)How exactly does a CALLBACK function work? What calls it? I'm guessing that it can be triggered either by a change in user input, or it can be/is called when the dialog box initiates, hence all this initiation that's going on above. Is this correct?

First, scan the msdn headers looking for the definition of the CALLBACK token. Iirc, it's an alias for WINAPI which is an alias for _stdcall (or variant). The CALLBACK token sets the calling convention for the function while naming it's role as a callback. A callback function works exactly the same as any other function - at least as far as cleaning up the stack before returning goes - and as much as any function is like any other function. There are many different kinds of callbacks. The microsoft windows gui callback is only one kind. The CALLBACK token indicates that a reference to the function might be passed as a argument to another function and that the function might be invoked through this reference (i.e. function pointer).

On Windows, one function that calls the callback is DispatchMessage. In response to various input events, windows puts a MSG Structure into the thread message queue. The thread message loop polls the thread message queue and when new messages arrive it dispatches them. The MSG has a hwnd. A hwnd has a class and thus a wndproc. You can retrieve a pointer to the wndproc of a hwnd using GetWindowLong and GWL_WNDPROC, and invoke it using CallWindowProc. DispatchMessage does all this for you, more or less.

Quote:
 Original post by adder_noir2)I believe that the large block of HWND declarations with the GetDlgItem is linking stuff defined in the resource.h file with these handle declarations. The hDlg being a handle to the file/window (not sure which) which contains the relevant resource data. I am correct here?

IDC_ADAPTER et al. are resource identifiers doubling as child window ids. Child windows are assigned an identifier rather than a menu. The hDlg variable holds the window handle for the dialog window, the window that is parent to the various child windows obtained using GetDlgItem. Resource data is stored in the executable and is available process wide. You need an hinstance to access it not a hwnd.

Quote:
 Original post by adder_noir3)The switch(message) part is obviously initiated when the function is called. Is the case WM_INITDIALOG: part a windows variable that is passed to the function whn the dialog box is initiated?

WM_INITDIALOG is a token for a number. A WM_INITDIALOG message is passed to the dialog during initiation. The switch directs program flow to the message handler associated with the specific message. In this case the handler is all of the code between the brackets following the "case" statement.

Petzold's book explains a lot of this. I recommend it too.

##### Share on other sites
These are such good replies thanks so much to all for taking the time to write them, they will be very helpful!

I am going to order Petzold's book anyway but a quick question some copies on Amazon go back 20 years! Do I need the latest edition, the most recent I could find is about windows 95 and was published in 1996. Is this recent enough?

Thanks ;o)

1. 1
2. 2
Rutin
21
3. 3
JoeJ
18
4. 4
5. 5

• 14
• 40
• 23
• 13
• 13
• ### Forum Statistics

• Total Topics
631719
• Total Posts
3001886
×