not as elegant as I wished... but it works!
www.zabkat.com/blog/SHBrowseForFolder-s ... -patch.htm
blog: fix for SHBrowseForFolder shell API
Moderators: fgagnon, nikos, Site Mods
Re: blog: fix for SHBrowseForFolder shell API
I had the same problem in my wrapper of BrowseForFolder, written in Visual Basic 6. Your solution was a godsend. I translated your code to Visual Basic, and it worked.
But I wasn't comfortable with the timer. The 250 ms period used in your code isn't enough in some cases (network drives, or many levels of nested directories), in which case it doesn't work. I tried with one second, but it is noticeable: the dialog shows up, and then, a second later, it suddenly jumps to the selection. It's enough time for the user to "scan" the dialog's contents, or even to try to interact with it. And even that could break on some corner cases (i.e., slow network connections).
Then I realized that I was already capturing the BFFM_SELCHANGED in order to raise a SelChanged() event, so why not try to make visible the selected item in every selection change? I moved the enumeration call from the timer callback to the case of the BFFM_SELCHANGED message, and it worked like a charm! Now the selection was visible immediately for local folders, and it remained visible if the tree's contents took longer to load. In my (limited) testing, on Windows XP, 10 and 11, I have not found a single failure.
Of course, this could cause problems if you tried to programmatically change the selection once the dialog is loaded. But I think this is a rare scenario, and it wouldn't be too difficult to disable the call to the enumeration in the BFFM_SELCHANGED message via a flag if it was needed. Other than that, I can't imagine a scenario where this wouldn't work.
I understand that you blog focuses on C/C++ code, but if you find this interesting, I can share with you my Visual Basic class where I implemented this.
But I wasn't comfortable with the timer. The 250 ms period used in your code isn't enough in some cases (network drives, or many levels of nested directories), in which case it doesn't work. I tried with one second, but it is noticeable: the dialog shows up, and then, a second later, it suddenly jumps to the selection. It's enough time for the user to "scan" the dialog's contents, or even to try to interact with it. And even that could break on some corner cases (i.e., slow network connections).
Then I realized that I was already capturing the BFFM_SELCHANGED in order to raise a SelChanged() event, so why not try to make visible the selected item in every selection change? I moved the enumeration call from the timer callback to the case of the BFFM_SELCHANGED message, and it worked like a charm! Now the selection was visible immediately for local folders, and it remained visible if the tree's contents took longer to load. In my (limited) testing, on Windows XP, 10 and 11, I have not found a single failure.
Of course, this could cause problems if you tried to programmatically change the selection once the dialog is loaded. But I think this is a rare scenario, and it wouldn't be too difficult to disable the call to the enumeration in the BFFM_SELCHANGED message via a flag if it was needed. Other than that, I can't imagine a scenario where this wouldn't work.
I understand that you blog focuses on C/C++ code, but if you find this interesting, I can share with you my Visual Basic class where I implemented this.
Re: blog: fix for SHBrowseForFolder shell API
not a bad idea!