I have a problem using the GetOpenFileName function. This is something I have used successfully for several years embedded in my own utility routine however for historical reasons my application i/o files I have been restricted to the old dos 12 chars dot 3 chars name format (12.3). I made some edits to allow longer file names however I have a problem.
Via the OPENFILENAME structure we supply a memory location of a character string (buffer) (and also the buffer length) for GetOpenFileName to return the selected file name.
In many instances there is an obvious choice of file name for the user so I set this as default by putting that file name as a null terminated string into the buffer before calling GetOpenFileName. GetOpenFileName puts that default name the “File name” edit box that shows the current selection and if you click the “Open” button without making any other selection that is what is returned.
I find that if the default file name supplied is longer than 16 characters (12+1+3) it is displayed in the file name edit box such that half the name cannot be seen as it appears centred on the left edge of the box. If you click in the box and arrow left you find the name is all there it is just a display glitch. If you click on a windows unrelated to the application and then click on the application window which forces the dialog to be refreshed by windows it corrects the displays.
It is not a problem with the length of the text buffer (that is 256 chars and has not changed) it is purely a function of the number of chars to the left of the null terminator in the initial buffer string.
Can’t see any flags or attributes that can be set. Is there an alternative way of specifying the name of a default file? Quite an annoying and frustrating feature! Any ideas Anyone?
Best Regards, Andrew
Steve Lionel (Intel) wrote:
I can reproduce this. Weird.
Thanks, it is helpful to know it is not just me....
But surely others must experience this problem I think this method is widely used as the more modern "common file dialog" api/methods seem impenetrable from Fortran?
Steve Lionel (Intel) wrote:
This is evidently a bug in the control itself. If you just click Open, it returns the correct file.
That is my conclusion also GetSaveFileName works OK. I suppose the question is, is this a new "feature" in the latest sdk? I do not have any easy way to test that.
It wouldn't be an SDK thing - the control implementation is part of Windows. I tested on Windows 7. Just took the GETOPENFILENAME sample we provide, changed the initialization of the filename buffer and ran it. GetSaveFilename doesn't have this issue? Weird!
OK thanks for the info I am running W10 pro so it looks like this a not a new problem.
It is also think not likely to get fixed. Some clever person needs to write some wrappers for IFileOpenDialog, and IFileSaveDialog. I had a look at this a year or two ago and it looks like quite a lot of hard work.
Yes, I see this problem as well (with Win7), never noticed it before since I have not been pre-loading the filename with a default name as a click shortcut. Also as noted GetSaveFileName() does not have the problem. Clicking the dn-arrow at the rhs of the filename editbox brings a dropdown with the correct full path+name of the supplied filename, and if selected the full path+name is then shown correctly in the editbox. This is clearly an API error, must have been around for many years.
The .h file is :
C:\Program Files (x86)\Windows Kits\8.1\Include\um\ShObjIdl.h there is also an ShObjIdl.idl file but not sure where one would go next .....
Yeah, I found the .h and .idl files but I need a .tlb or .dll or .ocx that exports the interfaces. There has to be one somewhere for this to work, but I haven't found it yet.
OK I learn something new every day. Pop a Fortran command prompt and run the sdk tool MIDL (MIDL ShObjIdl.idl) this creates ShObjIdl.tlb. I ran the module wizard on that ( I know < 0 on proper use of the module wizard) and got a useful Fortran module of declarations and interfaces.....
The module wizard could be a little bit more standards friendly, I appreciate that API's are platform specific but we could specify GUID's and other constants in standards compliant ways (warning #7023: Fortran 2008 does not allow radix-specified constants) and maybe not have tabs and long lines
warning #5112: Extension to FORTRAN-90: tab formatting
warning #5268: Extension to standard: The text exceeds right hand column allowed on the line.
Maybe things like:
error #7287: A dummy argument has both the VALUE attribute and an explicit INTENT(OUT) F2008 attribute. [PSZNAME]
error #8039: The INTENT(OUT) or INTENT(INOUT) attribute is not allowed for arguments received by value. [PSZNAME]
Are a bit more problematical as I guess the definitions son't allow for passing memory locations by value.
It is nice to compile with the absolute minimum of warnings to be suppressed.
After the challenge was set at #11 the MIDL route took quite a bit of googling and reading of stuff before it appeared as the solution. It could be worth a note in the module wizard "how to" document as clearly the IDL file appears to be the "master document" for describing the interface and is referenced in the msdn documentation for COM api's.
Having eliminated the compile errors and suppressed the warnings by warning number we get "catastrophic error: Too many warnings, exiting". It appears the compiler counts warnings even if they are suppressed and there is some limit. The only option is to turn off standards checking for that source file.
It isn't a top prority at the moment more of an interest project. I did some mass edits to the interface module and some manual edits as there are some features in the auto-generated source that will not compile. Stuff like passing a structure reference when the receiving interface is an integer pointer, untenable intent(out) etc.
1] get it to compile and dont think too hard
2] generate some simple test cases
Anyway set 1] has failed as I now get an ICE
Compiling with Intel(R) Visual Fortran Compiler 16.0 [IA-32]... ifort /nologo /debug:full /Od /standard-semantics /stand:f08 /Qdiag-disable:7025,5142,6477,7028,7023,6924,7372 /debug-parameters:used /warn:declarations /warn:unused /warn:truncated_source /warn:uncalled /warn:interfaces /Qauto /module:"Debug\\" /object:"Debug\\" /Fd"Debug\vc120.pdb" /traceback /check:bounds /check:uninit /check:stack /libs:static /threads /dbglibs /winapp /c /Qlocation,link, "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\\bin" "...\shobjidl.f90"
fortcom: Fatal: There has been an internal compiler error (C0000005). compilation aborted for C:\...\shobjidl.f90 (code 1) 1 error(s), 7 warning(s)
I haven't looked to finds a cause an ICE is over to you guys....
C:\....\shobjidl.f90(13978): catastrophic error: **Internal compiler error: internal abort** Please report this error along with the circumstances in which it occurred in a Software Problem Report. Note: File and line given may not be explicit cause of this error.
compilation aborted for C:\Users\....\shobjidl.f90 (code 1)
Build log written to "file://C:\Users\...\Debug\BuildLog.htm"
Cadfil90s - 1 error(s), 7 warning(s)
With Stand off I still get an ICE but a slightly different ICE message.