Conference turris::fortran

    1) How do I get information about where runtime errors are occuring?
       For example "forrtl; error (63): output conversion error, unit 8,
       file ...".  This error is difficult to track down without line numbers
       and subroutine name.

We have not yet implemented a traceback capability - this is on our list for
a future version.  Please look up the help topic "Just-In Time debugging" - it
tells you how to define an environment variable so that errors cause you to stop
in the debugger (or bring up the debugger) rather than just printing an error
message.

    2) When I restart the debugger, it asks "Please enter the path for
       CRTO.C".  What is this?   A "C" run-time file?  Where would this
       be and why is the debugger asking for it?

DIGITAL Visual Fortran programs actually start in the run-time library, which
is written in C, and hence uses the C library's initialization code in module
CRT0.  By default, debug-configuration applications link against the debug
versions of the libraries, and hence the debugger looks for the source for this
module.  Click Cancel when this comes up.  We suggest you set a breakpoint at
the first executable line in your program and then use F5 (GO) to go to it.

    3) How do I get the debugger to stop on a floating point exception?  I
       assume I need an exception handler.  Is there one supplied that I can
       use?

Run the program under the debugger.  From the Debug menu, select Exceptions...
From the exception list displayed, select "Float Overflow", click the
"Stop Always" button, then OK.  This setting will remain in effect for this
project until you change it again.


(There are other exception types available on this list.)

|>Under Digital Visual Fortran it appears that PARAMETERs are "invisible"
|>to the debugger! 
|>
|>When run under the debugger, 'I' is known, but 'PP' is indicated as an
|>"Undefined variable"! Is this a known "bug" in the current release of the
|>compiler???

It's not a bug - at least we don't look at it that way.   It is a feature that
we're currently missing and one which we consider desireable.  Note that
PARAMETER constants aren't "variables".  It's on our list for implementation
in a future version.  We don't support this on UNIX yet either (we do on 
OpenVMS - the debug support there is more robust.)

But here's a way to get the equivalent.  Click on Tools, Source Browser...
Enter some name (doesn't matter what), uncheck the "Case sensitive" box,
then OK.  It will tell you it needs to change the project settings to enable
source browsing - let it do so and let it rebuild.  You need do this only
once.

Now, in a debug session, position the cursor over the name of a PARAMETER
constant, select Tools..Source Browser  (Or ALT-F12).  The name of the
constant should show up in the selection window - if it doesn't, type it in.
Select "Definitions and References" (this should already be highlighted) and
click OK.  It will list the definitions, and you can double-click to find them.
You can also type in the name of any symbol in the Source Browser window.

In article <[email protected]>, Ralph Jay Frisbie <[email protected]>
 writes:
|>I'm having problems figuring out how to do things with the workbench.  
|>As of now, I don't think I'm having DEC problems, I just have had NO 
|>experience with Microsoft's Studio, and the documentation is all 
|>online.  Online documentation is great when you know what you're doing,
|>but when you're not even clear on how to bring up a reference manual, 
|>there's a problem.
|>	So, would appreciate some pointer to a:
|>"MS Developers Studio for the Complete Idiot" book.  

Here's how to get started.

1.  Create a project:

    File...New...Projects
    Select "Win32 Console Application".  Type in the name of your
    project under "Project Name".  Click ok.

2.  Add a file to a project:

    File..New..Files
    Select either "Fortran Fixed Format Source File" or "Fortran Free
    Format Source File".  Enter the file name.  The "Add to project" box
    should already be checked - click OK.

    Alternatively, if you have existing files on your disk:
    Project...Add to Project...Files
    Select the files you want (you may have to change the file filter from
    C files to Fortran files), click OK.  After doing this, I suggest doing
    a Build..Update all dependencies.

    Hint:  Use Tools..Customize to drag the New button to the toolbar, where
    you can use it instead of going to the File menu all the time.

3.  Edit file(s) - if you created a new file above, you'll be in the editor
    already.  Otherwise, click on the FileView tab, then on the + next to
    "projectname files", and double-click on a file name.

4.  Build the project

    Build..Rebuild All  (There's a button icon next to that entry, the same
    icon shows up on the toolbar.)  It may prompt you for a configuration -
    select Debug when you're starting out.  You can switch to a "Release"
    configuration with Build..Set Active Configuration.

5.  Run the program

    Click on the ! button, or select Build..Execute.

6.  Debug the program

    Because of the way that Fortran programs are started in the RTL, you'll
    need to set a breakpoint at the first executable line of the program.  In
    the source window, right click on the line and select "Insert/Remove
    Breakpoint".  This will stay active between sessions.  Start the debug
    session with Build..Start Debug..Go  (or press F5 or the button that's
    to the right of the ! that looks like a page with a down-arrow). 

    A new button bar will appear with debug-related buttons.  Run your mouse
    over them to see what they do (in the ToolTip).  To examine a variable's
    value, just position the mouse over the variable name in the source
    window.

7.  Getting help

    Position the mouse over a function name or a keyword and click on the
    binoculars with the ? next to it.  It should bring up a Search window with
    that keyword.  Double-click on a topic title to view it.  (If you have
    dial-up-networking set up so that there is a "default Internet connection",
    you may see a "Connect to" box come up.  Just dismiss it - this is due to
    the way that DevStudio's InfoViewer works, based on MSIE.)


8.  Explore

We're aware that many people who are new to DevStudio find it a bit hard to
get started.  We're looking to see what we can do to help.

A QuickWin program copied to another system that does not have DVF installed
fails with the error:

 Internal Error - unexpected error, file "E:\forrtl\build\qwnbuild\qwginit.c",
 line 268

This is due to a missing QuickWin help library on the target system.  To
fix this, copy Windows\System\fqwin.hlp to the same directory on the target
system (or somewhere in the PATH).  QuickWin will be fixed in a future update
to give a more descriptive message and to require the help library only when
the user asks for Help.

Command lines longer than 255 characters get truncated by the compiler 
command driver.

This is a bug which will be fixed as soon as possible.

Attempts to compile any program give the error:

  df: error: Create process failure - Error: 5

This will occur if there is a C:\Program directory that is separate from
C:\Program Files, which is what the compiler driver is expecting.  This will
be fixed in the driver, but a workaround is to rename or remove the
C:\Program directory.

In a QuickWin application built in "Release" mode, why do all of the default
menu items bring up the Print Setup dialog box?

This problem is a result of a particular programming method used to determine
the identity of default menu callbacks and a new linker optimization which
breaks an assumption made by said programming method.  This will be corrected
in a future update.  As a workaround, add /OPT:NOREF to the Project..Settings..
Link..Project Options list.

If an array with a lower bound of 0 is displayed in the debugger, the bounds
are incorrectly given as starting with 1.

This will be fixed in a compiler update.