An olde worlde open file dialog

Windows specific questions.
deltarho[1859]
Posts: 4292
Joined: Jan 02, 2017 0:34
Location: UK
Contact:

Re: An olde worlde open file dialog

Post by deltarho[1859] »

Josep Roca wrote:Please try the following example.
Looking good José.

However, it falls short of what I want as written.

On the second execution of 'Open File Dialog' the initial directory is the ending directory of the first execution.

However, in WndProc if we change

Code: Select all

DIM wszInitialDir AS WSTRING * 260 = Curdir
to

Code: Select all

DIM wszInitialDir AS WSTRING * 260 = AfxGetExePath
then no matter what the ending directory of the first execution is the second execution's initial directory will be the same as the first.

That is the behaviour that I want. In my latest application the first use of the OFD is to select a target file for either encryption or decryption. I do not want the next use to open the target's directory again but to open the application's directory where the key blobs are located.

I shall keep testing but I would much rather use your code than a PowerBASIC dll.
deltarho[1859]
Posts: 4292
Joined: Jan 02, 2017 0:34
Location: UK
Contact:

Re: An olde worlde open file dialog

Post by deltarho[1859] »

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
jj2007
Posts: 2326
Joined: Oct 23, 2016 15:28
Location: Roma, Italia
Contact:

Re: An olde worlde open file dialog

Post by jj2007 »

deltarho[1859] wrote:... 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.
Indeed, you can hand over any path to the dialog; curdir, exepath, user docs, whatever. Question is what is the best behaviour from a user's viewpoint. What I would normally expect as a user is the most plausible folder at the beginning (whatever that is), but if the user picks a file from another folder, s/he will probably grateful if the program remembers that choice.
I then deleted OFN_EXPLORER from the flags and saw the really old open file dialog.
That one looks funny indeed. Did you notice that explorer comes back when you set the hook flag to zero?
deltarho[1859]
Posts: 4292
Joined: Jan 02, 2017 0:34
Location: UK
Contact:

Re: An olde worlde open file dialog

Post by deltarho[1859] »

jj2007 wrote:but if the user picks a file from another folder, s/he will probably grateful if the program remembers that choice.
But some will not. I have six places in Encrypternet which uses the open file dialog box. I do not want anything remebered otherwise I spend half of my time navigating.
Did you notice that explorer comes back when you set the hook flag to zero?
In flags OFN_EXPLORER
jj2007
Posts: 2326
Joined: Oct 23, 2016 15:28
Location: Roma, Italia
Contact:

Re: An olde worlde open file dialog

Post by jj2007 »

deltarho[1859] wrote:In flags OFN_EXPLORER
Yep, there it is, thanks:
This flag is necessary only if you provide a hook procedure
deltarho[1859]
Posts: 4292
Joined: Jan 02, 2017 0:34
Location: UK
Contact:

Re: An olde worlde open file dialog

Post by deltarho[1859] »

@jj2007

Your last quote is from OFN_ENABLESIZING and not OFN_EXPLORER.

It seems to me that José's hook procedure, returning FALSE, is redundant unless we omit the OFN_EXPLORER flag.

I cannot see anywhere in his code that has any bearing on the Windows's 7 new style otherwise, which is why it is not disabled.

Of course, if we want a fast way to get to a folder to avoid any open file dialog navigation it is a simple matter to create a Places Bar, if one does not exist already, and put the folder there. I might do that if I cannot fathom a way to disable the Windows's 7 new style. I am certainly not going to resort to the ancient open file dialog.
Josep Roca
Posts: 564
Joined: Sep 27, 2016 18:20
Location: Valencia, Spain

Re: An olde worlde open file dialog

Post by Josep Roca »

> I cannot see anywhere in his code that has any bearing on the Windows's 7 new style otherwise, which is why it is not disabled.

Of course it is. The appearance of the dialog is different (Windows XP style). Or are you so used to PowerBasic DISPLAY OPEN FILE (that, because it uses a hook, displays the dialog using the XP style) that you don't see the difference? The XP style displays icons in the left side, the new one (without a hook) displays a list of folders.

BTW passing an initial directory is taken with Windows as a suggestion. The normal behaviour is to remember the last folder to which you have navigated.
deltarho[1859]
Posts: 4292
Joined: Jan 02, 2017 0:34
Location: UK
Contact:

Re: An olde worlde open file dialog

Post by deltarho[1859] »

The normal behaviour is to remember the last folder to which you have navigated.
That is true but only since Windows 7.

Under lpstrinitialDir of the OPENFILENAME structure it states "The algorithm for selecting the initial directory varies on different platforms." and then describes the difference between Windows 7 and Windows 2000/XP/Vista.

Your code and the PowerBASIC dll seem to behave according to the pre Windows 7 method but not under all circumstances.

In my post, opening with "There is a scenario where it isn't disabled.", I describe a situation where your code and the PowerBASIC dll approach fail. It could be that Vista and earlier also fail in this situation but no one spotted it.

I am resigned to accepting that as much as I'd like to have the pre Window's 7 behaviour it ain't going to happen.

Microsoft made, in my view, a monumental error by not introducing a flag allowing a choice between Windows 7 and later and pre Windows 7. I understand that we must move with the times and we should not 'hang on' to everything but there are some things which should be kept. Microsoft are not blind to this - the compatibility feature isn't there for the fun of it. I tried with Vista compatibility but knew that would not work and it didn't. <laugh>
jj2007
Posts: 2326
Joined: Oct 23, 2016 15:28
Location: Roma, Italia
Contact:

Re: An olde worlde open file dialog

Post by jj2007 »

deltarho[1859] wrote:@jj2007

Your last quote is from OFN_ENABLESIZING and not OFN_EXPLORER.
Scroll down three boxes, and you'll see the identical phrase a second time.

What you can do to solve your problem, btw, is using the CDN_FOLDERCHANGE notification to set lpstrInitialDir.
deltarho[1859]
Posts: 4292
Joined: Jan 02, 2017 0:34
Location: UK
Contact:

Re: An olde worlde open file dialog

Post by deltarho[1859] »

jj2007 wrote:Scroll down three boxes, and you'll see the identical phrase a second time.
Blimey!

CDN_FOLDERCHANGE notification: Sent by an Explorer-style Open or Save As dialog box when a new folder is opened.

By which time the horse has bolted.

I mentioned above about having José's code in two folders. Using the ancient open file dialog I navigated all over the place with one of the exe and then moved to the other folder. It opened in its folder on the first use of the open file dialog - it was not influenced by what I was doing in the other folder. With the modern open file dialog they would influence each other. I have a phrase to cover this: Quantum entanglement. <smile> I bet Microsoft are not aware of this.
jj2007
Posts: 2326
Joined: Oct 23, 2016 15:28
Location: Roma, Italia
Contact:

Re: An olde worlde open file dialog

Post by jj2007 »

deltarho[1859] wrote:By which time the horse has bolted.
Well, no. Guess what is the purpose of that notification;-)
deltarho[1859]
Posts: 4292
Joined: Jan 02, 2017 0:34
Location: UK
Contact:

Re: An olde worlde open file dialog

Post by deltarho[1859] »

jj2007 wrote:Well, no. Guess what is the purpose of that notification;-)
Please elucidate.
marcov
Posts: 3455
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Re: An olde worlde open file dialog

Post by marcov »

(I see you use afxopenfiledialog, the MFC variant. I'm writing this in case you get stuck with it, you could also try winapi directly)

I don't know much about MFC, but I looked at our own (Lazarus) implementation, and
as far as I can see, XP and older and Vista and newer use different ways of popping the filedialog.

The Vista plus way goes via IFileDialog interface(https://msdn.microsoft.com/en-us/librar ... s.85).aspx), while the old way is via getopenfilename (https://msdn.microsoft.com/en-us/librar ... s.85).aspx)

So the major split seems to be between XP and VIsta, not Vista and W7 (though Windows 7 does not implement the functionality to set file filters anymore, https://msdn.microsoft.com/en-us/librar ... s.85).aspx)
Last edited by marcov on May 30, 2018 10:10, edited 1 time in total.
jj2007
Posts: 2326
Joined: Oct 23, 2016 15:28
Location: Roma, Italia
Contact:

Re: An olde worlde open file dialog

Post by jj2007 »

deltarho[1859] wrote:
jj2007 wrote:Well, no. Guess what is the purpose of that notification;-)
Please elucidate.
When the user navigates, the current directory is set (unfortunately - this should be local to the dialog IMHO).
In the CDN_FOLDERCHANGE handler, one can copy the current directory to lpstrInitialDir. The next time you call GetOpenFile, it opens the last folder used. But that may not be what you want... so the solution for you is probably to set lpstrInitialDir to a specific folder before calling GetOpenFile.
marcov wrote:(though Windows 7 does not implement the functionality to set file filters anymore, https://msdn.microsoft.com/en-us/librar ... s.85).aspx)
This concerns a specific filter routine, not the filtering by extensions. To filter files individually, see OFN_ENABLEINCLUDENOTIFY CDN_INCLUDEITEM - but don't expect miracles (SOF):
After looking further into CDN_INCLUDEITEM, which requires the pre-vista version of OPENFILENAME, I have found that this is the most useless API imaginable. It only filters NON-filesystem objects. In other words, you can't use it to filter files. Or folders. The very things one would filter 99.99% of the time for a file open or save dialog. Unbelievable!
Btw your link doesn't work in my browser, this one is better.
deltarho[1859]
Posts: 4292
Joined: Jan 02, 2017 0:34
Location: UK
Contact:

Re: An olde worlde open file dialog

Post by deltarho[1859] »

jj2007 wrote:so the solution for you is probably to set lpstrInitialDir to a specific folder before calling GetOpenFile.
I think you meant GetOpenFilename.

Anyway, that is what we are already doing.
Post Reply