VS2013 crashes on File Open

[reidar]

I am using W8.1 togeter wih VS2013 and IVFComposer 2013. The program I am working with is a MDI application. A feature is to open and edit files, which used to work fine up to now. But suddenly VS2013 stop working every time I try to open a file as shown below. I wonder if it is due to a windos upgrade. I hope someone can give me a tip.. (Open file secton and the intitialize open file name structure  is shown below)

Open file:

case (IDM_OpenFile)

! get open file dialog box

Ofn%Flags = null

szfilter = 'TVC input files(*.inp)' &

// char(0) // '*.inp' // char(0)

Ofn%LPSTRINITIALDIR = loc(trim(InputDir)//Char(0))

iret = InitializeOpen()

bret = GETOPENFILENAME(Ofn)

bret=.true.

! check to see if the OK button has been pressed

if(bret == 0) then ! check for error

call COMDLGER(ierror)

! ierror is the returned error value

MainWndProc = 0

return

else

lpszCaption = &

szFileName(1+Ofn%NFILEOFFSET:Ofn%NFILEEXTENSION-1)

ext = szFileName(Ofn%NFILEEXTENSION+1: &

Ofn%NFILEEXTENSION+3)

end if

integer*4 function InitializeOpen()

! intitialize open file name structure 

useMultiPadGlobals

use DEFAULTS_TV

use comctl32

implicit none

! szfilter = 'MultiPad data files(*.txt)' &

! // char(0) // '*.txt' // char(0)

Ofn%lStructSize = sizeof(Ofn)

Ofn%hwndowner = ghwndMain

Ofn%hinstance = gHinstance

Ofn%lpstrfilter = LOC(szfilter)

Ofn%LPSTRCUSTOMFILTER = NULL

Ofn%NMAXCUSTFILTER = 0

Ofn%NFILTERINDEX = 1

Ofn%LPSTRFILE = LOC(szFileName)

Ofn%NMAXFILE = LEN(szFileName)

! Ofn%LPSTRFILETITLE = loc(szTitleName//".txt"C)

Ofn%NMAXFILETITLE = 50 ! 25

! Ofn%LPSTRINITIALDIR = NULL ! loc(inputdir) !

Ofn%LPSTRTITLE = null

! Ofn%FLAGS = NULL

Ofn%NFILEOFFSET = NULL

Ofn%NFILEEXTENSION =NULL

! Ofn%LPSTRDEFEXT = loc("*.txt"C)

Ofn%LCUSTDATA = NULL

Ofn%LPFNHOOK = NULL

Ofn%LPTEMPLATENAME = NULL

initializeOpen = 1

return

end

[reidar]

Steve,

In the sample folders Win32 there is a project named GetOpenFileName. I bulit an run the program, and the same thing happens. In debug mode the program just start, and then VS2013 closes. Is this something somebody from Intel can explain?

[Steven_L_Intel1]

I'll take a look at this on Monday, but my expectation is that I won't see the problem on my system.

[reidar]

Hello Steve,

I think you are right, however it does not solve my problem :-(

FileOpen worked well with VS2010, but not with my new purchase VS2013.

(And yes, I have also installed the latest update of VS2013)

Crying,

Reidar

[andrew_4619]

reidar wrote:

Steve,

In the sample folders Win32 there is a project named GetOpenFileName. I bulit an run the program, and the same thing happens. In debug mode the program just start, and then VS2013 closes. Is this something somebody from Intel can explain?

If you have a break point on the first executable statement are you saying under debug VS closes before you get to the break point?

If so does any program e.g. "hello world" run under debug?

[Steven_L_Intel1]

As I expected, I can't reproduce this with VS2013 and Windows 8. (I can't yet install 8.1 on my company system.)  I would also like to know the answers to app4619's questions. Does it crash before you even get to the first breakpoint? 32-bit or 64-bit?

[reidar]

Hi,

I set breakpoint at:

iret = InitializeOpen()

and the program stops. When I then press F10 or F11, V2013 simply dies.

By the way, my operating system is W8 pro, but the problem I have, came With VS2013.

Best regards

Reidar

[Steven_L_Intel1]

Does the Applications section of the Event Viewer have anything relevant to this? In the Windows search box type Event and it should come up with the Event Viewer. Open that, select Windows Logs, Applications. It may or may not.

Another data point would be to boot in Safe Mode and see if the error remains.

[reidar]

Hi Steve, can you explain what menu and item(s) to Select to open the Event Viewer?

[Steven_L_Intel1]

You can do it the way I suggested, or...  Right click on Computer, select Manage. Then select Event Viewer.

[reidar]

Hello Steve, Just a final feed-back form my side.. The problem with FileOpen and "mousing" variables was solved by replacing VS2013 with V2010. A drawback is then that the Fortran help function by pressing F1 does not work, it just directs me to a Microsoft VS page. (Altough installation of XE2013 with integration to VS were "succesfully")

[Steven_L_Intel1]

Very interesting. As for the help, try this:

• Help > Manage Help Settings
• Choose Online or Local Help
• I want to use local help
• Ok
• Install content from disk
• Browse to C:\Program Files (x86)\Intel\Composer XE 2013 SP1\Documentation\msvhelp\1033\compiler_f
• Select helpcontentsetup_f.msha and click Open

[reidar]

Thank you for the tip, Steve. Now help works fine!

[Gabor_V_]

I had a similar problem in console applications (long Fortran 90 programs with little inserts in C++). Earlier I used GetOpenFileName and GetSaveFileName for opening files. It had worked perfectly for ca. 10 years. When Windows 8.1 arrived, my console programs crashed at the second call of a GetOpenFileName or GetSaveFileName. The problem arose at all versions of Microsoft VS and Intel Fortran composer which I've used till then. (I mean the 5-year old exe files crashed the same way as the new ones created by VS 2013 and Composer XE 3013 with the latest updates.)
Lacking any better idea, I replaced GetOpenFileName and GetSaveFileName by IFileOpenDialog and IFileSaveDialog in the C++ part of my program, as Microsoft advised. I strictly followed their example codes, and carefully matched the CoInitializeEx by a CoUninitialize. The obtained function crashed at repeated calls in the same way as its predecessor had crashed with GetOpenFileName and GetSaveFileName. Following advices from the msdn community I put the code one level lower than CoInitializeEx/CoUninitialize pair (into a separate function that was called between CoInitializeEx/CoUninitialize).  I carefully closed and released everything before CoUninitialize, exactly as it was done in the Microsoft's C++ example.  Still the problem persisted, Finally I deleted the CoUninitialize() line. Now CoInitializeEx is called only once in the program, at the first invoking of my function, and CoUninitialize is not called at all. It appears to work nicely under Windows 8.1.
I'll plan to test the new code soon in earlier Windows versions (64-bit Windows 7 and 32-bit Vista). If anything will be differetn there, I'll turn back to this page and write it.

[reidar]

My solution was to remove VS2013 and re-install VS2010.....  So far, so good.