Strange problem with LNK files and CFileDialog

Hi everybody,

I have a problem with a CFileDialog on some PCs running Windows 7 while it works correct on some other PCs, even running Windows 7. Since I yet wasn't able to find any differences between those PCs I want to ask if maybe anyone here already had similar problems and/or can provide me with any helpful information.

I am able to reproduce the problem by simply creating a standard MFC MDI application with VisualStudio 2010.

The  problem is about links (LNK files): When I create a LNK file for a file registered as document type for my application in a folder I can see the correct icon and file-type description in Explorer, i.e.: LNK files in Explorer(Verküpfung is german for Link)

But when I open the same folder from in the CFileDialog shown by CWinApp::OnFileOpen first the LNK files aren't shown at all, I need to enter i.e. a *.* to the filename edit box to get them shown, but then they don't have the correct icon and file-type description. Even LNK files referencing other registered file types aren't shown correctly:Incorrect shown LNK files in CFileDialogWhen I open such a LNK file in the CFileDialog the path passed to CWinApp::OpenDocumentFile is the path to the LNK file, not the path to the referenced file allthough when I open a file via double-click on the same LNK file in Explorer the path passed to CWinApp::OpenDocumentFile is the correct path of the referenced file.

When I do the same on my other PC it is shown correctly without the need to enter *.* and the path passed to CWinApp::OpenDocumentFile is even correct:LNK files shown correctly on other PCI suspect this is caused by some kind of Windows configuration or policies or something else since the codes and binaries I tested on both PCs are equal. The two PCs I used to test are setup quite similar, almost all software installed there is equal.

Does anyone have an idea what might be the cause and/or a solution?

Thanks in advance,

best regards,

ZOPPO


[Edited: Additional info] I found some other strange problem: From within the file open dialog I cannot use UNC paths (an error message like 'can't access' with error code 0x80004005) and the folder list is either messed up or doesn't show network at all: Strange OpenFile dialogFurther instead of my above mentioned guess it's a Windows configuration thing I found the problem doesn't occur in older builds of my program. But I have absoluteley no idea what might have been changed in my project which could affect the behavior of CFileDialog this way.
LVL 31
ZoppoAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

ZoppoAuthor Commented:
Ok, the problem is solved! After a lot of research I found a colleague of mine implement some kind of registry redirection to allow our 32 bit application can register itself as DDE server even on 64 bit OS. Therefore at startup of the program he implemented something like this:
	HKEY hKey;
	
	if ( ERROR_SUCCESS == ::RegOpenKeyEx( HKEY_CURRENT_USER, _T("Software\\Classes\\"), 0, KEY_READ | KEY_SET_VALUE, &hKey ) )
	{
		::RegOverridePredefKey( HKEY_CLASSES_ROOT, hKey );
		::RegCloseKey( hKey );
	}

Open in new window

This redirects the registry key for the lifetime of the process without resetting it, the problem is this even seems to affect system functionality like common dialogs or ShellExecute (we found this even failed).

The solution was simple - I moved that code to be called before RegisterShellFileTypes is called and reset the registry redirection using ::RegOverridePredefKey( HKEY_CLASSES_ROOT, NULL ); afterwards.

ZOPPO
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
sarabandeCommented:
the following code was executed when calling CWinApp::OnFileOpen:

void CDocManager::OnFileOpen()
{
	// prompt the user (with all document templates)
	CString newName;
	if (!DoPromptFileName(newName, AFX_IDS_OPENFILE,
	  OFN_HIDEREADONLY | OFN_FILEMUSTEXIST, TRUE, NULL))
		return; // open cancelled

Open in new window


BOOL CDocManager::DoPromptFileName(CString& fileName, UINT nIDSTitle, DWORD lFlags, BOOL bOpenFileDialog, CDocTemplate* pTemplate)
{
	CFileDialog dlgFile(bOpenFileDialog, NULL, NULL, OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT, NULL, NULL, 0);

Open in new window


that means the OFN_NODEREFERENCELINKS flag is not set and neither OFN_EXPLORER flag which could be responsible for differences between computers. also the template pointer was passed as NULL pointer what is strange as one way to determine the filters is to pass a valid doc template.

so, from that code I have no idea why it goes wrong. can you check whether your application class has an overload of OnFileOpen which passes different flags to the CFileDialog?  

generally, the file dialog is only explorer-like but does not have full explorer behavior. because of that i didn't use it if i can avoid.

for the UNC paths I found a call of AfxFullPath with a comment that file paths must not be longer than _MAX_PATH (what is 260). i don't know whether that applies to your files but it could be possible that AFX cannot handle UNC paths at all.

finally, you could check which dll and ocx files are registered on your systems. I found comdlg32.dll (21/11/2010), comdlg32.ocx (09/03/2004) in my syswow64 folder (win7 pro).

Sara
0
ZoppoAuthor Commented:
Thanks for your comment, Sara, but as written above I found the problem, it was a regsitry redirection which anyhow confuzed shell-related functions. After changing this as explained everything works fine again.

BTW, the  OFN_NODEREFERENCELINKS isn't set, we use the flags set as default by CFileDialog constructor.

Thanks for the effort anyway ...

Have a nice day,

best regards,

ZOPPO
0
sarabandeCommented:
congratulations for solving the issue, Zoppo.

i missed your answer at last refresh but am happy that you could find it as the behavior was indeed strange.

Sara
0
ZoppoAuthor Commented:
Thanks again :o)

And yes, it was one of the strangest things I had the last some years, especially the different behavior on the different machines made me crazy ...

Best regards,

ZOPPO
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Development

From novice to tech pro — start learning today.