using dialog boxes and defToFD.exe

[John_B__Walter]

Is it just me or do I have things not setup correctly?

In order to use dialog boxes you have to get resource.h converted to resource.fd

The documentation talks about this in "The Include (.FD and .H) files"
and also in "Designing a Dialog Box Overview"

Great so far. But when I use "deftofd resource.h resource.fd" as the command line in the properties, Visual Studio can't find it, and I end up having to include the path to deftofd.exe as well.
Regardless of whether I use the %IFORT_COMPILERxx% environment variable or explicitly specify the path, I end up having to revise my project to reflect the current location of defToHD when I update my compiler.

This doesn't seem correct since that is a pain and orthers must clearly be using dialog boxes in their projects.

So what have I done wrong or what have I missed in installing IVF?

yesterday I installed VS 2008 and then Intel ComposerXE-2011, so I'm somewhat up-to-date now.

Thanks,

[Steven_L_Intel1]

If VS can find the compiler it should be able to find deftofd.exe, since it is in the same folder. If you find it is not, uninstall and reinstall Fortran.

[John_B__Walter]

So color me confused.
What you say makes sense, Steve,but...

I've looked at my PATH, and while the install added a bunch of ...\redist\... folders, presumably for the redistributable files, it didn't add the binary folder C:\Program Files\Intel\ComposerXE-2011\bin\ia32
so I don't know haw VS was finding IFORT.EXE in that folder.

Now that I've personally and explicitly added this to my path, it finds defToFD just fine.

I did just the default install of the compiler. Did I miss something, or was I supposed to do something differently? This has been the case when I've installed previous versions, ever since I converted from CVF.

Thanks,

[Steven_L_Intel1]

PATH has nothing to do with it when you are using Visual Studio. It uses the folders listed under Tools > Options > Intel Visual Fortran > Compilers. Maybe you need to click the RESET button there.

From the command line, you need to establish the Fortran environment using one of the shortcuts provided in the Start menu for Intel Parallel Studio XE or execute the appropriate compilervars.bat (with ia32 or intel64 argument) to set up everything.

Please do not manually add the compiler BIN folder to the PATH system variable.

[John_B__Walter]

So that's fine, I shouldn't have to add an environment variable.

But, the executables path, the libraries path, and the includes path under Tools\options Intel Visual Fortran\compilers

ALL reference the environment variable IFortInstallDir

which I don't see on my system, and I don't see where compilervars.bat or ifortvars.bat create it either.

Obviously it should have been created at installation.

The last entry for executables is $(PATH) so that is why adding the folder to the path lets VS find defToFD

FURTHER I'm missing something when you refer to "using one of the shortcuts provided in the Start menu for Intel Parallel Studio XE". That gives me shortcuts for "Command Prompt" and some other links, but nothing that appears useful for this.

Running a .bat file in a command window usually has zero effect after the window exits, with the exception of a few commands like the DOS SUBST command, but I decided to open a DOS window using the IA-32 shortcut. I executed "compilervars.bat ia32", logged out and back in just for good measure, and ran Parallel Studio XE with no effect. There was still no definition for IFortInstallDir, and defToFD.exe was still unknown.

What in Blue Blazes am I missing? Am I just speaking a completely different language? What do you mean "From the command line"?

[Steven_L_Intel1]

That environment variable is created dynamnically by the VS integration. Running compilervars.bat as a command from VS will have no effect.

I mentioned the shortcut only because it was unclear to me which environment you were using to build. If you are using VS, ignore that part.

Please go to Tools > Options > Intel Visual Fortran > Compilers. Make sure that the selected compiler is . Click "Reset All". See if that helps.

[acar]

John, I had a similar problem when I upgraded at the beginning of the year although my upgrade was only from IVF to ComposerXE (I was already and am still running VS2008). I can't recall the precise details now but I have overcome it by writing a small program that runs the deftofd conversion. I seem to have to do this manually each time I make a change to my dialog resources. Looking at the routine I wrote there seemed also to be an issue with continuation lines in the resulting fd file. Once it was created with deftofd I then modify the fd file to strip out all the continuations and concatenate to single lines. It there is a way round this Intel then I would be pleased to hear about it.

[anthonyrichards]

If you right-click on Resource.H in solution explorer and select properties, then look under 'Configuration Properties' (left-hand pane) and find 'Custom Build Step..General', you will see if the DefToFD step is shown. Otherwise you should add it there so that every time Resource.H changes, this step is always carried out.
(see attached example).

I appreciate that it must be V. annoying if this step is not made by default for every resource.h file in every project you create because of a VS integration problem.

By the way, the othe picture shows the EXE's in the compiler binary folder. As you can see, the compiler, the linker and deftofd are all together.

[John_B__Walter]

Thanks for all the ideas. I've finally put it all together, so I'll sum up my problem.

I was used to being able to go to the solution explorer and right clicking on a source file and selecting to compile it. Well, you can't do that with a .h file, unless it is in a C project.

So Duh! in a C++ project VS wasn't looking in the right place for a fortran project executable.

So now I've removed that C++ project from my solution (I only had it for generating the .FD from the .h) and I've added the .h to my fortran project using Project\Add existing Item, and setup the custom build step for the .h as described in the documentation.

Even though I can't use "right click\compile" to execute it, it is automatically converted each time I build my project (assuming a rebuild or the .h has changed).

This is good. The only thing helpful about using my C++ project strategy was that all I had to do was to add that project to each of my fortran solutions; I didn't have to add the .h and then set up the "custom build step" each time. I did have to explicitly specify the location of defToFD.exe, and that had to be revised when I upgraded my compiler version, which as I said and you can see is a pain.

Thanks, this will be better. It would be nice if the .h type was recognized and all I had to do was to add it to my fortran project and not have to fool with the custom build step.

[anthonyrichards]

What about making your Fortran project dependant on the C++ project? Maybe that will trigger all the right things when you have modified the C++ project?

[Steven_L_Intel1]

The .h file type is a C/C++ include file - it would be wrong for Fortran to consider this a compilable file.

[acar]

Thanks for that Anthony.

[John_B__Walter]

Being able to "compile" the .h explicitly was a red herring in anycase as the .fd is not needed untill the fortran while which uses it is compiled. At that point a build of the project, rather than just a compile of the particular fortran file can be called for. That will perform the defToFD step.

Making the fortran dependent on the C++ doesn't work because then it would try to build the fortran project before the C++ project, and also it still wouldn't find defToFD in the C++ folders.

What I have now is the correct solution, with the .h in the fortran project.

[acar]

Only problem with adding deftofd to the custom build step is that when running in debug mode the compiler thinks that the project is out of date even if the resources haven't changed. Probably too much to expect the compiler to check to see whether, after enforcing it to run deftofd, it actually needs to do this?

[nvaneck]

I had to do this, too, after trying all kinds of things I made a cmd file for it. Now I'm in the habit of just doing it automatically. Only neededwhen a newcontrol is added or deleted--not needed for other design changes to the dialog.

[John_B__Walter]

Quoting acar

Only problem with adding deftofd to the custom build step is that when running in debug mode the compiler thinks that the project is out of date even if the resources haven't changed. Probably too much to expect the compiler to check to see whether, after enforcing it to run deftofd, it actually needs to do this?

This should not be the case.
Iadded the .h directly to the fortran project (not to the sources or header folder), went into the project\properties for the .h, and set them as described in the documentation.
THEN defToFD is only executed when the .fd is not found or the .h has changed since the .fd modification date.
This does not, in my experience, cause VS to complain that the solution is not up-to-date when I tell it to start the code in debug mode.
I have not done anything to instruct VS to run defToFD unconditionally, merely to execute it when the .FD is not up-to-date.

[acar]

Yes I have reverted to this approach and yes don't need to run it for edits.

[onkelhotte]

After setting up a new project my resource.fd wasnt build any more.

Thanks for the picture of the Custom Build Step, that did the trick.

Markus