Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Valued Contributor III
71 Views

GetOpenFileName default file display problem

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

0 Kudos
33 Replies
Highlighted
65 Views

I can reproduce this. Weird.

0 Kudos
Highlighted
Valued Contributor III
65 Views

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?

0 Kudos
Highlighted
65 Views

This is evidently a bug in the control itself. If you just click Open, it returns the correct file. 

0 Kudos
Highlighted
Valued Contributor III
65 Views

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. 

0 Kudos
Highlighted
65 Views

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!

0 Kudos
Highlighted
Valued Contributor III
65 Views

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.

 

 

0 Kudos
Highlighted
Valued Contributor I
65 Views

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.

0 Kudos
Highlighted
65 Views

The Fortran Module Wizard ought to be able to construct interfaces for the COM methods. I haven't been able to find the type library that exports these, however.

0 Kudos
Highlighted
Valued Contributor III
65 Views

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 .....

0 Kudos
Highlighted
65 Views

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.

0 Kudos
Highlighted
Valued Contributor III
65 Views

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.....

 

0 Kudos
Highlighted
Valued Contributor III
65 Views

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.

 

0 Kudos
Highlighted
65 Views

Hah! I didn't know about using MIDL for that either. I will look at the errors and see what we can do about those.

0 Kudos
Highlighted
Valued Contributor III
65 Views

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.

 

0 Kudos
Highlighted
65 Views

Please keep us informed with your progress on this! Maybe even write an article for IDZ? I know it would be of great interest to other users.

0 Kudos
Highlighted
Valued Contributor III
65 Views

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

3] debug

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....

0 Kudos
Highlighted
65 Views

Thanks - we'll take a look.

0 Kudos
Highlighted
65 Views

ICE escalated as issue DPD200412146. It is triggered by /stand, which is not appropriate to use for this source so you may as well turn it off for now.

0 Kudos
Highlighted
Valued Contributor III
65 Views

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.

 

 

0 Kudos