Simple "console" read/write for debugging??

[Intel_C_Intel]

I'm developing a Fortran program which is called from Visual Basic. The VB code interacts with a commercial simulation program.

Previously, I have written a dummy Fortran routine, and this works with VB/simulation program. I have now tried to finish the real Fortran project/workspace (or whatever). This compiles and is linked with zero errors and zero warnings. The next job is to debug things.

I try to run the code by running VB in debug mode. This starts up the simulation program, and I open the GUI of a process unit in the simulation program. (The GUI is written in VB.) When I insert certain information in the GUI and closes this, the Fortran part is called on to do the calculations. In my GUI, I can select which Fortran routines to call. (A parameter is passed on to the Fortran program, and the selection is performed in Fortran.)

When I make a selection in the GUI (in VB) such that the old dummy Fortran code is called, everything seems to work as before. If I in the GUI choose to use the new code I have developed, and close the GUI (whereupon Fortran is run), something gets wrong - no answer is found (probably due to logic errors in the Fortran code). If I try to reopen the GUI, VB crashes.

I have also set the system up so that I can run Visual Fortran in debug mode. If I do this, the simulation program is started. When I select to run the appropriate case in the simulation program and try to open the GUI, an error message comes up, and I have to close the simulation program. Thus, I'm not able to take advantage of the VF debugger.

To get around this problem, I want to insert PRINT/WRITE statements in the Fortran code which prints information to a console-like window when I run the code in debug mode from Visual Basic.

After this lengthy introduction, I've come to the question.

Q: How can I print variable values to a console-like window from VF?

I have tried this:

USE DFLIB
OPEN (UNIT= 12, FILE= "USER")
WRITE (12, *) "FROM IOMMFOR - CMOD = "

If I do this and build the project, there are no error messages. When I run the code in debug mode from Visual Basic and select the option that should work and then closes the GUI (whereupon the Fortran code is run), the program crashes with an error message window with title: "Visual Fortran run-time error". When I click "OK" in this window, Visual Basic crashes and stops.

So - I just need a *simple* way so that I can print some standard text strings and values of variables (integers, double precision, double precision arrays) to a console type window.

If you could help me, please also inform me how I close the windows/output channels, and how I can do this after I have read the message. (I.e., some kind of pause thing. Alternatively, it's ok. to close the windows manually!!!)

Finally - I'm not versed in the Visual Studio environment - I only know it through using Visual Fortran a few hours (and I have not been able to find tutorial material on how to use it; I am aware of the Digital Visual Fortran Programmer's Guide, but I don't consider that a tutorial).

Thanks,
-Bernt Lie

[Steven_L_Intel1]

FILE="USER" works only from within a QuickWin application.

What you need to do is call the Win32 API routine AllocConsole before doing your normal Fortran WRITEs (to unit *, for example). This will create the console window for you.

Steve

[Intel_C_Intel]

Thanks to Steve L, who set me on the right track.

Here is a somewhat more complete description of the solution:

Place the following declarations/commands in the declaration part of the main program/some subroutine that is called before you want to print to the console window:

USE DFWIN ! loads routines from the Digital Fortran Win32 API
! library, or something like that
INTEGER B ! needs to run a boolean AllocConsole function to open
! a console window. Fortran doesn't support Boolean ?,
! so I used Integer instead.

Somewhere before you want to print data, call the AllocConsole function:

B = AllocConsole()

Next, use PRINT/WRITE/... as usual in Fortran 77, etc.

PRINT *, "The value of variable VAR is: ", VAR

This helped me out since I can check values of variables in Fortran the old-fashioned way - the VF debugger tends to crash, while I can run the program (at least partially...).

In my view, simple tricks like this should be introduced in the very beginning of a Fortran VF tutorial book. Then one should (gradually?) let the user/student discover the advantages of using the debugger.

-Bernt Lie

[Steven_L_Intel1]

INTEGER is the correct type for API routines that return a C "boolean". This is the way AllocConsole is declared in DFWIN.

I'm unsure of why this would belong at the beginning of a VF tutorial. AllocConsole is of no use to people writing ordinary Fortran programs. It can be useful when writing DLLs called from VB or similar languages, but for debugging, I would think using the debugger itself would be preferable (see our Knowledge Base).

I had initially proposed that a WRITE to the console when no console existed should create the console, but it was pointed out to me that Visual C just discards such output, so we should too. The user could call AllocConsole to create the console. In any event, we all agree that an error is not the thing to do. I'm hoping to have this change in the near future.

Steve

[Intel_C_Intel]

Why does the use of the AllocConsole command belong in a tutorial for VF? Maybe Steve is right, and it doesn't? How should a tutorial be structured?

One thing that puzzles me beyond reason is that the "tutorial"/introduction to using VF (and VB, etc.) starts without any decent attempt of explaining to the user what is the purpose of "Workspace", "Project", and "Files". My background is some simple Fortran 77 programming ca. 10 years ago, before visual system, and without the use of a debugger. I think many potential VF users might be in the same category, and will lack any knowledge of OOP and Visual Studio. I think there is a huge marked for people like me, who are casual Fortran programmers, and who do not have the time or energy to learn in detail all the fancy possibilities of the visual evironment.

To me, it is extremely frustrating to be supposed to start developing my own code *without* having an understanding of what is the purpose of "Workspaces", "Projects", etc. Why? Because when you start to experiment with your own code, you have to define the Workspace, the Project, etc. Extremely frustrating when you don't know it's purpose. In my view, a tutorial introduction to VF must start with this: what the user first has to deal with when he/she starts to experiment on his/her own. Give practical examples which illustrates the purpose of Workspaces, Projects, etc. Maybe the VF developers disagree with me, and think that they have provided what I ask for? If so, I disagree. Anyway, to me it is meaningless to start to use a program and have to define files, projects, etc. when I have little clue as to what is the purpose of these. Of course, I realize that e.g. a Visual C++ user will know all of this, but that is presumably not who a tutorial is written for?

Next, regarding the AllocConsole. If you want to transform "old fashioned" Fortran programmers into using VF, you should get them started with something they recognize, and then gradually build up their confidence in VF. Most "old time" Fortran programmers know how to read and write information to a console. That is why I think it is good to start with AllocConsole (or any other input-output method that doesn't require a lot of coding, setting up in menues, etc.). This is basic pedagogics - start with something that the audience recognizes. Don't make too large leaps in the presentation.

Steve suggests that it is a bad idea to use the console window to debug Fortran code. 10 years ago, that's the way I debugged code. That's the way I have debugged e.g. Matlab code until now - I simply had not gotten used to using a debugger. What turned me on the use of debuggers was when programming in Visual Basic - I like their debugger. However, from limited use of the VF debugger, my impression is that it crashes a lot. Maybe this is due to the problem I'm trying to solve. However, I have to say that if I was to rely on the VF debugger this week, I'd be stuck with a dysfunctional Fortran code. The use of Print to the console window made it possible to run my code through the (relatively stable) VB debugger, and read the values of the Fortran code in the console window.

-Bernt

[Steven_L_Intel1]

Bernt,

I think you misunderstand. "Old-fashioned Fortran programmers", using Visual Fortran, aren't going to be writing DLLs to be called by Visual Basic! They will just create a "Fortran Console Application", build their existing code, and it will work! This is all explained in the Getting Started manual. The Programmer's Guide goes into more detail about workspaces and projects.

AllocConsole is not needed by traditional, self-contained Fortran applications. You need it only if you are calling a Fortran DLL from Visual Basic (or something similar) and want to "write to the console". This is an advanced programming methodology, far removed from "old-fashioned Fortran".

I agree that a tutorial on creating DLLs for use from VB should discuss this issue, but it's not something the traditional Fortran programmer would care about.

Steve

[Intel_C_Intel]

Hi,

OK, we're discussing two topics. First, getting up to speed on using the Visual Studio IDE and second, the use of AllocConsole.

There's a bunch of documentation that ships with VF that refers to the IDE, workspaces, projects, etc : in the 'Programmer's Guide, Building Programs and Libraries'; the entire 'VC++ User's Guide' which includes the 'Working with Projects' chapter - the Compaq Visual Fortran online documentation 'Home Page' includes a direct link to the 'VC++ Users Guide (for Visual Fortran)' right there, up front; and then there's the printed 'Installing and Getting Started' guide that has a chapter 'Using Visual Fortran'. Now, whether that document set could be more organized, or have a single location that can be called a "tutorial", or have more pictures or little AVI files etc, I'm sure any such suggestions would be well received by vf-support.
No knowledge of OOP is required to use Visual Studio, and in fact, using Visual Studio is not required to create applications. You can compile and link source files from the command line (a separate chapter in the VF Programmer's Guide). Maybe the IDE does get in the way if the goal is to just compile some sources into a console app - then one can always go the cmd line route. But imo, the IDE is a big boon for complex projects with multiple targets/components/configurations.
I don't thing the market for Fortran itself is "huge", let alone casual programmers. IMO, the market for fortran programmers is likely skewed towards those moving from UNIX boxes to NT and those users will likely be attempting to interact more with the Win32 OS than just porting a UNIX console app to a Windows console app.

As for AllocConsole, it is not required to write to the console (for a "console app") so normally there is just no reason to use it. The only time its use really comes up is when people naively move Fortran code into a DLL to be used by VB and wonder why their program aborts ( ... because there's no console for the write/print statements to write to). The typical answer to the queries that follow the crash is, " ... , you can use AllocConsole to start a console so your write/print statements have some place to go." I couldn't disagree with that advice more. The whole idea of a GUI app is to provide a richer experience for the users. But, the "AllocConsole solution" is a ton easier to explain than suggesting to people that they restructure their code to pass the information (error, or progress, or whatever) back to the caller and let the calling GUI app inform the user more nicely. And, surprise, people often choose to take the easy route. IMO, a good portion of the difficulties people have in moving to VF/Windows is utlimately related to the different programming model that Windows represents - an event driven model vs a non-event driven, sequential, stdin/stdout/stderr programming model.

This thread started with difficuly debugging a VF DLL used from VB. I would have attacked the problem by trying to get vf-support's help in resolving the difficulty (they are usually pretty responsive). But if you choose to debug with print statements, that's perfectly fine; just as if you choose to compile from the command line.
IMO, VF has a rich capablility in debugging mixed language applications, enough so that I would resist leaving it. It is also robust. I've never experienced a crash, through debugging straight f90 code, f9 0/VB apps, f90/C++ mixed apps, f90/C++/COM/VB apps, ... I'd think that if you like the VB debugger, you'd like VF's debugger once what ever is causing the difficulty is resolved.

Oh, well. I got more long winded than I expected, but that's my 2c.

-John