Josep Roca wrote:Wrong. What he did was to enable a hook, which has the side effect of disabling the new style.
There is a scenario where it isn't disabled.
I copied and pasted your code, where the above quote came from, and made only one alteration: I changed 'DIM wszInitialDir AS WSTRING * 260 = Curdir' to 'DIM wszInitialDir AS WSTRING * 260 = AfxGetExePath'. I called the exe OFDHook.
That works. It did not matter where I navigated to on the first execution of the open file dialog the second execution will open in the application's folder and not the ending folder of the first execution. I tested this many times and could not break it.
However, when I introduced your code to my current project, Encrypternet.exe, I got the second execution of the open file dialog opening at the ending folder of the first execution.
The PB dll approach also worked. I spent sometime on that and could not break it. However, when I wrote another version of Encrypternet using the dll it also 'misbehaved'.
I spent hours comparing all the code and could see no reason why Encrypternet did not see the new style being disabled when your code or the dll were used.
I had a barmy idea. I have three folders each with a copy of Encrypternet to simulate three people exchanging encrypted data. I then put OFDHook into two folders. After using OFDHook in one folder I then moved to the other folder and that is where things went wrong. I deleted both folders and then ran OFDHook from my development folder and the fist execution of the open file dialog saw a folder opened previously, it was not the application's folder - the damage had been done.
It may well be that instead of three folders we had three PCs then this problem may not occur.
One thing is for sure - the new style is not being disabled.
I then deleted OFN_EXPLORER from the flags and saw the really old open file dialog. I have done a few tests with that and that seems to work. Of course, the template being used is very different