Organize a static library project when routines use dialog boxes

Organize a static library project when routines use dialog boxes

I need help deciding how to best manage a static library when some of the routines use a dialog resource.

For my individual applications that use a dialog, I usually place all three dialog files (resource file PROG.RC, Fortran include file RESOURCE.FD, and C include file RESOURCE.H) in the same folder as the source PROG.F90, and add RESOURCE.FD to the project using Visual Studio. The include files become available to the project by virtue of the default search location for includes, which is the same folder as the source. So far so good.

If I am working on a library project, I put all of the subroutine sources SUBnn.F90 in the library source folder. If subroutine 01 uses a dialog, then I put the associated SUB01.RC, RESOURCE.FD, and RESOURCE.H in the same folder, and add SUB01.RC to the project. This works fine too.

But what if two or more of the library subroutines use a dialog? I can name their resource file SUB01.RC, SUB02.RC etc., put all of them in the library folder, and add all of them to the library project. But the include files are problematic, since they have the same names by default. I can rename the Fortran include files SUB01.FD, SUB02.FD etc. because the Fortran include file needed for each subroutine is explicitly stated in the subroutine source. But that doesn't work for the C include files, RESOURCE.H, because this is specified inside the .RC file.

The only way I see to make this system work is to edit each .RC file to call for a custom-named C include file. That seems like asking for trouble.

Is this a good way to organize the library project? Can anybody suggest a better way?

7 Beiträge / 0 neu
Letzter Beitrag
Nähere Informationen zur Compiler-Optimierung finden Sie in unserem Optimierungshinweis.
Bild des Benutzers app4619

you can add the .h file to the fortran project. The resource complier will then find it whaerver it may be.

I'm not sure how this reply addresses my question. The problem was, what to do if there are multiple resource files and each one has its own resource.h file.

But after some more struggling, I find that my problem is even more basic than I thought. I can not even get a single dialog box to work in a single subroutine in a static library.

I have a program TESTPROG.FOR that calls a subroutine PAUSED.FOR and that subroutine uses resources PAUSED.RC, INCLUDE.FD, AND INCLUDE.H. This all works fine in a regular project. But the next step is to add PAUSED to a static library so that it can be called from various applications. I can not get this to work at all. My technique is to use a VS library project, add various .for files to it one of which is PAUSED.FOR, and add PAUSED.RC to the library project as well. The resource include files are in the same folder as all of the other .for files in the library project. When I try running an application that accesses PAUSED in the library, I get a runtime error "Forrtl: severe(157) Program exception-access violation upon hitting the line IRET = DLGMODAL (DLG).

Am I even correct in assuming that dialog boxes should work in a static library? If so, what am I doing wrong?

I have studied the documentation (including the off-ine document Using IVF to create and build windows-based applications) hard but I don't believe it addresses this situation.

(This isn't Fortran specific, but perhaps Intel's FD to H thing complicates it.)

You can create resources for and use dialog boxes created in static libraries, but you need to make sure that the resources for the dialog box from the static library make their way into the final executable.  You also need to be mindful that identifiers for resources at the resource class level (string, dialog box, etc) are global to an executable or DLL.

(The global nature of the identifiers is one of the reasons that it may be better to have a project wide include file.)

Memory fails me - I'd have to go an look at some historic C projects of mine to see what I used to do.  One approach is that the rc file for the executable #includes the rc files for the static library, with the programmer manually managing any identifier clashes for the same class of resource.  I also have a vague recollection that the res files produced by resource compiler can be concatenated together, but I might be getting my operating systems confused now.

Bild des Benutzers Steve Lionel (Intel)

Have a look through http://software.intel.com/sites/products/documentation/hpc/composerxe/en-us/fortran/win/pdf/Creating_Fortran_Win_Apps.pdf and the section Including Resources Using Multiple Resource Files.

Steve

Thanks to both for these comments, but I still struggle with it.

To Ian: yes, it began to appear to me that the .rc info is introduced to the project at link time, not compile time as I had assumed. This would explain a lot. Unfortunately the need to distribute the resource info to "insure they make their way to the final executable" kind of defeats the purpose of a static library. The whole idea of a static library is to package everything needed into the obj's. Or so I had assumed. So to me, Intel's explicit statement in the documentation that dialog boxes are compatible with all project types *including static libs* is misleading.

To Steve: I have looked at this but have trouble following it. In part this is because the instructions/comments seem to assume that I am building the application AND associated dialogs with the full VS package, where the resource editor is closely integrated with Fortran. I don't have that, I only use the VS shell, where the resource editor is no longer included. So some of the instructions refer to menu options that don't even exist for me. I use an independent resource editor (it happens to be an old VS from CVF 6, if that makes a difference)--as I'm sure many do, and which you have advised several times in the past to those who complained about the editor no longer being a part of Fortran.

Bild des Benutzers Steve Lionel (Intel)

However you create the .rc and .h files, the instructions for adding them to the project should be the same.

Steve

Melden Sie sich an, um einen Kommentar zu hinterlassen.