Here is more information. It is not just a case of 'hover over' in the debug window showing rubbish values, rubbish values actually 'turn up in' and are actually used by the called routine.
In my module (call it MODNAME), all real variables are defined as REAL(DOUBLE) and all integer variables are defined as INTEGER(LONG). USE DFWINTY is invoked to define DOUBLE and LONG.(ALL my reals and ALL my integers throughout my code are similarly defined). I use IMPLICIT NONE everywhere.
In the module, some real variables are defined REAL, PARAMETER :: varname.
Other real variables in the module whose values are derived from PARAMETER values are just defined as REAL(DOUBLE). These variables previously resided in a callback routine in an early version of the program that worked OK. It was a simple single dialog program. My new version uses a tabbed dialog, and I have moved variables previously held in a callback linked to the original dialog into the module and removed them from the callback. The original dialog has become one tab of a 2-tab dialog box. The removed variables are now made available to the callback linked to the first tab by USEing the module that contains them in the callback routine.
When in the debugger, I find that if I enter the name of a parameter variable in MODNAME in the Watch window as MODNAME::varnameparam, the debugger tells me it is undefined. (This is the behaviour I observe even in the program that works OK, so PARAMETER module variable values appear to be out of reach of the debugger in general).
If I enter a non-parameter name MODNAME::varname which has already been defined by previous execution of a statement in a routine that utilises the module parameter values to generate the other values( e.g. varname=varnameparam1*varnameparam2), then a correct value is displayed. It is not flagged as 'undefined'.
If I call a routine with a module parameter variable as an argument, the routine generates very incorrect output values ( I know this because the code has been used in a previous single-dialog (i.e. non-tabbed) project with exactly the same input data where parameters previously resided in a callback function invoked by a button to compute output values. The output generated in the latter case are perfectly sensible).
In teh tabbed-dialog project, when I use the Watch window to examine the arguments after stepping into the called routine, I find that the variable corresponding to the module parameter variable used as argument in the calling program is completely at odds with its actual value defined in the module. This wrong value is clearly used in the called routine and leads to the generation of rubbish output values.
As an example, a run where the first four arguments of a called routine are module variables and the real values observed in the debugger before the call to the routine are 50.02864, 1.972364, -451.50000000, 55.0000000, whereas the real values, as seen in the Locals window, that are assigned to the dummy arguments when I enter the routine are 1.027595374870205D-311, -3.246627407232088D+22, -451.5000000000, 55.000000000
In the called routine, the arguments are defined as either REAL(DOUBLE) or INTEGER(LONG) to match the type of the arguments in the calling program.
P.S. The Tabbed dialog project was converted from a test project created using CompaqVF and I have just noticed that under project...properties...configuration properties...external procedures, the calling convention is set as CVF (/iface:cvf). I tried changing it to 'Default' and rebuilding and rerunning the debugger, but I got the same behaviour. Using any other options under calling convention gives me link errors.