开发者

dialog context - how to save?

开发者 https://www.devze.com 2023-03-23 21:11 出处:网络
I\'m wondering how to provide context for dialog procedures? Up to now, I declare static or global variables to provide whatever context I need knowing that the dialog procedure can only be active on

I'm wondering how to provide context for dialog procedures?

Up to now, I declare static or global variables to provide whatever context I need knowing that the dialog procedure can only be active one time. However, I find this pretty ugly and wonder if I can pass the context to the dialog procedure through the DialogBoxParam/WM_INITDIALOG/LPARAM mechanism saving it in the INITDIALOG handler using SetWindowLog/GWL_USERDATA?

A few experiments show this might work but I notice that the dialog procedure gets at least one message (namely 30h) before it gets the INITDIALOG message.

So. I'm left with a dilemma. One of the following occurs to me...

  • return FALSE to any message received while GetWindowLong/GWL_USERDATA is zero. But do I know its initial value will be zero?

  • return FALSE to message 30h. But are there any other message sent b4 WM_INITDIALOG?

  • Start in a procedure which returns FALSE until it gets a WM_INITDI开发者_JS百科ALOG, then change the dialog procedure using SetWindowLong/GWL_WNDPROC.

I'm also concerned about what other system calls or other uSoft software (stuff I find in the MSDN) might do with GWL_USERDATA.


There are actually quite a few ways to store context for your window procedures, and dialogs are simply a special case of windows, so these techniques apply.

One way, as you mentioned, is to use GWLP_USERDATA/GetWindowLongPtr()/SetWindowLongPtr() to store a pointer to the dialog context. Note that the functions are prefixed with Ptr(). These functions will work with 32-bit and 64-bit code. The "non-Ptr()" functions only work with 32-bit code, so they should not be used.

According to the documentation for GetWindowLongPtr(), the GWLP_USERDATA value is initially set to zero. So you can always rely on checking if GetWindowLongPtr() returns zero and returning FALSE from the dialog procedure in those situations.

A dialog procedure using these functions might look something like this:

// MyDialogProc is a static function in MyDialogClass. Can also be a global function.
INT_PTR CALLBACK MyDialogClass::MyDialogProc(HWND hwndDlg, UINT uMsg,
    WPARAM wParam, LPARAM lParam)
{
    MyDialogClass* target = 0;
    if(uMsg == WM_INITDIALOG)
    {
        target = reinterpret_cast<MyDialogClass*>(lParam);
        ::SetWindowLongPtr(hwndDlg, GWLP_USERDATA,
            reinterpret_cast<LONG_PTR>(target));
    }
    target = reinterpret_cast<MyDialogClass*>(
        ::GetWindowLongPtr(hwndDlg, GWLP_USERDATA));
    if(target != 0)
    {
        // Something like this
        return target->ProcessMessage(hwndDlg, uMsg, wParam, lParam);
    }
    return FALSE;
}

And your dialog creation code passes the pointer to an instance of MyDialogClass using a member function, possibly like this:

void MyDialogClass::Create()
{
    // ....
    // Use CreateDialogParam() or friends to create a dialog and pass
    // the context pointer.
    HWND h = ::CreateDialogParam(hInstance, lpTemplateName, hWndParent,
        &MyDialogClass::MyDialogProc, reinterpret_cast<LPARAM>(this));
    // ....
}

If you prefer a different method (because you're worried that someone else will write over GWLP_USERDATA), you can use GetProp()/SetProp()/RemoveProp() and come up with a unique name to identify the pointer. GetProp() returns zero if it can't find the property, so again you can rely on checking if it returns zero. This is the method that I use in my library/framework.

A dialog procedure that uses the property functions may look something like this:

const wchar_t* myDialogClassContextPtrName = L"MyDlgClsCxtPtr"; // Unicode
// const char* myDialogClassContextPtrName = "MyDlgClsCxtPtr";  // ANSI

// MyDialogProc is a static function in MyDialogClass. Can also be a global function.
INT_PTR CALLBACK MyDialogClass::MyDialogProc(HWND hwndDlg, UINT uMsg,
    WPARAM wParam, LPARAM lParam)
{
    MyDialogClass* target = 0;
    if(uMsg == WM_INITDIALOG)
    {
        target = reinterpret_cast<MyDialogClass*>(lParam);
        ::SetProp(hwndDlg, myDialogClassContextPtrName,
            reinterpret_cast<HANDLE>(target));
    }
    target = reinterpret_cast<MyDialogClass*>(
        ::GetProp(hwndDlg, myDialogClassContextPtrName));
    if(target != 0)
    {
        // Something like this
        INT_PTR returnValue = target->ProcessMessage(hwndDlg, uMsg, wParam, lParam);
        if(uMsg == WM_NCDESTROY)
        {
            ::RemoveProp(hwndDlg, myDialogClassContextPtrName);
        }
        return returnValue;
    }
    return FALSE;
}

As you have experienced, there are messages that are sent before the WM_INITDIALOG message (or the WM_NCCREATE message for non-dialog windows). In my experience these messages are inconsequential and will not affect the functionality of your procedure in any way. You can return FALSE for the messages that you receive before WM_INITDIALOG.

0

精彩评论

暂无评论...
验证码 换一张
取 消