Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Commondialog show thumbnails by default? 2
- Thread starter tedsmith
- Start date
-
2
- #2
- Thread starter
- #4
dilettante
MIS
There is a cleaner and more reliable way that uses callbacks, but it is messy and won't work with the CommonDialog control. You have to use the GetOpenFilename(), etc. entrypoints in comdlg32.dll to make it work.
The method shown is clever, but it relies on timing and worse yet "hopes" that only one dialog is open on the user's system at the time.
Why FindWindow doesn't work
The method shown is clever, but it relies on timing and worse yet "hopes" that only one dialog is open on the user's system at the time.
Why FindWindow doesn't work
Ted
In Hypetia's post, just below the line
See thread222-1063344: Common Dialog and View Menu Set to Details by Default.
You will see a link that says: Thank Hypetia for this valuable post!
Click on that and it will open a confirmation window that you need to acknowledge.
[gray]Experience is something you don't get until just after you need it.[/gray]
In Hypetia's post, just below the line
See thread222-1063344: Common Dialog and View Menu Set to Details by Default.
You will see a link that says: Thank Hypetia for this valuable post!
Click on that and it will open a confirmation window that you need to acknowledge.
[gray]Experience is something you don't get until just after you need it.[/gray]
>it relies on timing
The code in TimerProc function is executed asynchronously after the SetTimer call, which means that the TimerProc function is executed only after the file dialog is created, initialized and displayed on screen, no matter how long does it take.
>and worse yet "hopes" that only one dialog is open on the user's system at the time.
This will not make any difference. You can have any number of file open / save dialogs open on your system. The code targets the correct dialog belonging to the current application using GetActiveWindow function which is just created and displayed.
Further, the scope of the GetActiveWindow function is restricted to the calling thread by design, which further ensures that the function will not pick any wrong dialog box from other applications. I checked it with 10 file dialogs open in 10 different application and it worked fine.
As for FindWindow function, most of the flaws highlighted in the article, don't apply here due to the following reasons.
[li]We are using FindWindowEx, instead of FindWindow, with our search scope limited to a dialog box with known window hierarchy, instead of the whole desktop.[/li][li]We are not searching by window title, but class name, with only one window belonging to that class in the search scope.[/li]
There are chances in which the above code might fail.
For example, if in some future version of Windows, Microsoft do some extensive overhauling of File Open/Save dialog UI, or control class names or message arguments are changed. In such cases, FindWindowEx function or SendMessage function will fail.
I have already indicated that possibility in the original thread.
>it may not work on all versions of Windows.
However, it will not happen atleast under WinXP. In my opinion, the code is fairly safe to use for practical purposes.
The code in TimerProc function is executed asynchronously after the SetTimer call, which means that the TimerProc function is executed only after the file dialog is created, initialized and displayed on screen, no matter how long does it take.
>and worse yet "hopes" that only one dialog is open on the user's system at the time.
This will not make any difference. You can have any number of file open / save dialogs open on your system. The code targets the correct dialog belonging to the current application using GetActiveWindow function which is just created and displayed.
Further, the scope of the GetActiveWindow function is restricted to the calling thread by design, which further ensures that the function will not pick any wrong dialog box from other applications. I checked it with 10 file dialogs open in 10 different application and it worked fine.
As for FindWindow function, most of the flaws highlighted in the article, don't apply here due to the following reasons.
[li]We are using FindWindowEx, instead of FindWindow, with our search scope limited to a dialog box with known window hierarchy, instead of the whole desktop.[/li][li]We are not searching by window title, but class name, with only one window belonging to that class in the search scope.[/li]
There are chances in which the above code might fail.
For example, if in some future version of Windows, Microsoft do some extensive overhauling of File Open/Save dialog UI, or control class names or message arguments are changed. In such cases, FindWindowEx function or SendMessage function will fail.
I have already indicated that possibility in the original thread.
>it may not work on all versions of Windows.
However, it will not happen atleast under WinXP. In my opinion, the code is fairly safe to use for practical purposes.
dilettante
MIS
Thanks for the enlightenment.
This approach is certainly much cleaner than working directly against comdlg32.dll in the "approved" fashion. You seem to have the holes closed as much as possible here.
This approach is certainly much cleaner than working directly against comdlg32.dll in the "approved" fashion. You seem to have the holes closed as much as possible here.
I completely agree with the standard callback method of GetOpenFileName / GetSaveFileName function.
That is the correct and recommended method, but more messy as you told.
In fact I wanted to second your opinion in my above post, but forget to do so while "closing the holes".![[smile]](/data/assets/smilies/smile.gif "[smile] [smile]")
That is the correct and recommended method, but more messy as you told.
In fact I wanted to second your opinion in my above post, but forget to do so while "closing the holes".
![[ponder]](/data/assets/smilies/ponder.gif "[ponder] [ponder]")
dilettante
MIS
Yes, poor choice of words. More tricky logic required, but it does the job in the documented fashion.
Just an amusing juxtaposition, it was still clear what you meant.
dennisharoldsen
Programmer
thanks for this information. it works great for me.
i have a couple of questions:
1. are there codes for setting the default sort order (Arrange Icons By)?
2. is there a way to save the user's choice. i want to load images using thumbnails. however, when i start, i want to find the folder in list or detail mode. when i find the folder i want, i manually change to thumbs. the problem is that if i reopen the commondialog, it doesn't remember my last selection.
i hope i am being clear.
i have a couple of questions:
1. are there codes for setting the default sort order (Arrange Icons By)?
2. is there a way to save the user's choice. i want to load images using thumbnails. however, when i start, i want to find the folder in list or detail mode. when i find the folder i want, i manually change to thumbs. the problem is that if i reopen the commondialog, it doesn't remember my last selection.
i hope i am being clear.
- Status
Similar threads
- Locked
- Question
