CCommonDlg CDN_INITDONE Not working as expected

Question

0.00/5 (No votes)

See more:

, +

Hey out there,

i'm using a CCommonDlg based FileOpen Dlg.
I wan't to do some stuff with the CListCtrl (for example selecting an item) after the Dialog has been created.

So i add my additional functionality into my OnInitDone() function which i called this way from the OnNotify:

C++

BOOL CMyFileDialog::OnNotify(WPARAM wParam, LPARAM lParam, LRESULT* pResult)
{
	// ...

	OFNOTIFY* pNotify = (OFNOTIFY*)lParam;
	switch(pNotify->hdr.code)
	{
	case CDN_INITDONE:
		OnInitDone();
		return TRUE;
	case CDN_SELCHANGE:
		OnFileNameChange();
		return TRUE;
	case CDN_FOLDERCHANGE:
		OnFolderChange();
		return TRUE;
        // case for all other "CDN_" messages
        }

        // ...
}

But into the OnInitDone function it seems like the Control doesen't exsist.
When i call FindWindowEx in the following way it always returns 0x0:

C++

HWND hwndParentDlg = ::GetParent(this->m_hWnd);
HWND hwndShellDllDefView = ::FindWindowEx(hwndParentDlg, NULL, "SHELLDLL_DefView", NULL);
HWND hwndSysListView = ::FindWindowEx(hwndShellDllDefView, NULL, "SysListView32", NULL);

I played a little bit around and checked if i can get the HWNDs in OnFolderChange(). At the first look it seems everything is ok here, i get a valid HWND from the SysListView32.
But at the secound look it seems like the Control exists but have no items.
So i put my code into the OnFileNameChange() for checking if i put my code at the "wrong place" or if my code is faulty.
Here inside the OnFileNameChange() everything is cool. The HWND is valid and i can access to the items in the SysListView32.

The problem is, i want to do my little adjustments after the Dialog has been created and not if the user select a new file.

So please help me and please forgive me my bad english.

Thank you so much guys for helping me!!!!

Posted 19-Mar-14 0:40am

C3D1

Add a Solution

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Jochen Arndt · Accepted Answer · 2014-03-19T01:57:00

Solution 1

Google is your friend. I found this discussion: https://groups.google.com/forum/#!topic/comp.os.ms-windows.programmer.win32/r3-_zzD-ElY[^]
Cite:

Quote:
Note that there is no listview control in the template; instead, there's a
listbox control (lst1). That's a placeholder control to tell the COMMDLG
code where to put the SHELLDLL_DefView window, which COMMDLG apparently
creates *after* the CDN_INITDONE notification has been processed. So the
SHELLDLL_DefView window hasn't been created yet when your CDN_INITDONE
handler is called.

When you get the CDN_FOLDERCHANGE notification, the list view has been created but has not been filled so far.

Posted 19-Mar-14 1:57am

Jochen Arndt

Comments

C3D1 19-Mar-14 10:23am

Hey,

thanks for your reply.
I checked the discussion at your link, but WM_ENTERIDLE didn't work on my Win8.1 machine.
check my source:

UINT CALLBACK HookProc(HWND hWnd, UINT nMessage, WPARAM wParam, LPARAM lParam)
{
// ...

if( nMessage == WM_ENTERIDLE )
{
// Do some other stuff here and place a breakpoint at this line
}

// ...
}

The breakpoint is never reached.
Is there an other solution?

Thanks a lot for your answer!

PS: i know google and if i found something what helped me, i wouldn't ask here ;)

Jochen Arndt 19-Mar-14 10:36am

I'm sorry, I have no other solution. The problem is that the implementation of the common dialogs has been often changed with the Windows version. It seems that you just discovered another difference to prior versions.

I would not invest too much time into changing the behaviour. Especially if you have to account for different Windows versions. Use the OPENFILENAME structure to achieve as much as possible. Another point is that your application behaves like all other Windows applications.

C3D1 19-Mar-14 10:43am

Thank's alot!
In my oppinion you could not fix my problem exactly but close enougth to accept your solution

Jochen Arndt 19-Mar-14 10:48am

Thank you for accepting the answer.