GetOpenFileName default file display problem

[andrew_4619]

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

[andrew_4619]

I rechecked with the file I posted on the forum as I had changed the spource file a little.

The ICE with the forum post file is as below. It also has an ICE with the x64 compiler.



Compiling with Intel(R) Visual Fortran Compiler 16.0 [IA-32]...
ifort /nologo /debug:full /Od /standard-semantics /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"
 "C:\...\shobjidl2.f90"

C:\Users\...\shobjidl2.f90(13976): 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\...\shobjidl2.f90 (code 1)

Cadfil90s - 1 error(s), 7 warning(s)

[Steven_L_Intel1]

Thanks. I found that /debug /debug-parameters:used seemed to be key here. Odd that if I took off /debug-parameters:used the error went away, even though that's the default. I added this information to the bug report.

[andrew_4619]

OK I will try that.

[andrew_4619]

errm what were the build option used? If I change to 

/debug-parameters:none

I still get the ICE.......

[Steven_L_Intel1]

Hmm - now (on a different system) I don't get the ICE with /debug and /debug-parameters. Must be something else going on.

[andrew_4619]

Sounds like one of those difficult problems!

[andrew_4619]

Steve,

I still have this on my do list so I gave it a whirl on the new 17.0.0.109 [IA-32] compiler but I still get an ICE with all compiler options that I tried. Could someone take a quick look at it, maybe there is a simple "workaround" but I don't get any clues as to the problem. I presume DPD200412146 is still open.

[andrew_4619]

OK an update! I split the source file from one file to two files (attached) both now compile without an ICE which is maybe some "clue" to the problem. Anyway I have a workaround .....

[Steven_L_Intel1]

It would be more helpful if you could determine the minimum compile options needed to reproduce the ICE in the original source. That you have /warn:interface on tells me that it might also be dependent on previously compiled sources.

[andrew_4619]

We already established that stand is not a factor. I did a couple additional tests and Release compiles OK, Debug gives an ICE. The command lines are below. I had previously only tried to build under debug and any combination of options I tried gave an ICE. We ICE if modules shobjidl_TYPES, shobjidl_constants, shobjidl are in the same source file when I split them there is no ICE.

/nologo /O2 /module:"Release\\" /object:"Release\\" /Fd"Release\vc120.pdb" /libs:dll /threads /winapp /c

/nologo /debug:full /Od /module:"Debug\\" /object:"Debug\\" /Fd"Debug\vc120.pdb" /libs:dll /threads /dbglibs /winapp /c

[Steven_L_Intel1]

Ok - I can get the ICE with no options in 16.0 but not 17.0. Would you please try that?

[andrew_4619]

I am using 17.0.0.109 [IA-32] compiler

[Steven_L_Intel1]

Ok - I can make it fail with just /debug. Thanks.