Possible interference on CW+ by use of PAUSE ??

I have come across an odd behaviour that I cannot account for in a friend’s code using FTN95 and ClearWin+. The error message that FTN95 generates is about there being too many %ca format codes.

If the program runs from the File/New menu, it goes through a sequence of dialogs, and successfully handles a particular one, including its callback function. This dialog & callback can be revisited repeatedly, with no problems.

However, if the File/Open menu option is chosen, and a complete dataset is loaded, then launching the dialog immediately gives the error message, despite the fact that there are no intervening WINIO@ function calls.

The one oddity in the routine(s) that read in the dataset is that they have been imported directly from the previous, DOS, version of the program, which, when an inadmissible data item was encountered, would use the PAUSE statement to convey a message to the user.

Now I recognise that PAUSE is a deleted feature, and I have read what FTN95.CHM has to say on the matter. The PAUSE statements are not, in fact, executed, because the trial dataset is admissible. I wonder if the implementation of the PAUSE statement is what causes the %ca error to occur?

We are in the throws of replacing the PAUSE statements with CW+ dialogs, in the hope that fixes things. It would be interesting to know if anyone else has such issues.

Eddie

Eddie:

This is what the PAUSE statement causes to happen in a 32-bit console program.

If the PAUSE is followed by a string in the Fortran source, the length of the string and the address of the string are pushed to the stack, and the routine PAUSE@ is called. If PAUSE is not followed by a string, a one character blank string is used instead. The PAUSE@ routine types out the string (or the blank), followed by

Enter system command or press ENTER key to restart:

and waits for keyboard input.

In your Clearwin program, are you watching the console window and responding with a system command or ENTER key press? I do not know what would happen if no console window is open -- where would the key press be expected to be received?

Eddie

What is the File/New menu that you refer to?

If you use /debug then you should get the line number at the point of failure (from the exception dialog).

You could try running the program from the relevant debugger SDBG or SDBG64.

Dear both,

Thank you for your quick comments.

Mecej4 - yep, I know what PAUSE should do, but I'd never thought about how it does it. This is not a console app, but a WINAPP. Although the PAUSE statements are there, they are not invoked. I suppose we should try invoking them, to see what happens. The PAUSE statements all have messages.

The input data file is read, and the program (not my style) then goes on to open a dialog. At that point, the program gives the ClearWin+ error message that there are too many %ca format codes. I have checked everything, and there is definitely no attempt to issue a WINIO@ function call with or without %ca before the line containing %ca that is referred to in the error window.

Paul, my apologies for using a shorthand. The program is a considerable way through (re-)development into a fully-fledged ClearWin+ Windows program,. My shorthand File/New means the New option in a File menu, following which the data values are laboriously entered one by one via a series of dialogs that can be invoked by options on the menu bar; File/Open means an Open option in the File menu that opens a file and reads the contents. Once the dataset is read, the dialogs are launched one by one so that the user inspects and accepts or changes the data values.

If there had been a formatting error in the datafile, then there should have been a message to that effect. If the dataset was inadequate in some way, or not to the specification required by the program, then one of the PAUSE statements left in from the DOS/console incarnation should have been invoked. There does not seem to be anything that I can immediately associate with the execution of one of the PAUSE statements that I can see. The error comes after the file has been read and validated and when there is an attempt to open one of the dialogs.

The line numbers in the ordinary FTN95 error box gives the line number for the error, which is the %ca invocation for the relevant first dialog and the line number of the END statement in the main program routine (not the call for the dialog box but we can infer that from various trials, as the dialog box starts OK as a callback function if invoked from the menu bar, but not as here from a function call immediately following reading in the file. I therefore don't think that /DEBUG is actually helpful in the present situation.

My pal is replacing the PAUSE statements at the moment, and I will report back if that solves the problem, then try to write a demonstrator.

Given that PAUSE is a deleted feature from way back in the 20th century (!) I should hardly be surprised if it works in a console app with FTN95 but has side effects in a WINAPP - side effects that no-one reported before, because no-one normally considers having PAUSE statements (possibly).

You will get a grovelling apology from me if it transpires that it is simply a coding error that I haven't picked up on! (But I have looked very hard). Compilation is 32bit, and no optimisation.

A belated Happy New Year, by the way,

Eddie

Eddie

I suggest that you write a very short ClearWin+ program that uses the PAUSE statement.

Run it to the PAUSE first as a console application (without WINAPP etc.) and then as a Windows application.

I am guessing that you will get the PAUSE at least for a console application.

You will probably know that a ClearWin+ program that is linked as console application will launch a DOS box first and then the application itself. The DOS box should (I think) show the PAUSE prompt.

My testing showed that PAUSE behaves differently in a 32-bit program as compared to a 64-bit program.

I took the test code in http://forums.silverfrost.com/viewtopic.php?p=32287#32287 and added PAUSE statements before and after the reference to WINIO@. The resulting program behaved differently when compiled for 32-bit versus 64-bit.

The 32-bit program opened a large window (with white background) and displayed the strings following each PAUSE in the program followed by a second line saying 'Enter system command or press ENTER key to restart', and waited for keyboard input in that window. The word 'restart' seems a bit inappropriate, since the program just continues rather than restarting after the ENTER key is pressed; perhaps, 'resume' would be better.

The 64-bit program, on the other hand, displayed a small 2 in X 3 in pop-up that contained the standard text 'Click OK to continue', each time that the PAUSE statement was executed.

Mecej4 - it is interesting that the 32-bit and 64-bit versions differ.

May I commend ClearWin+ to you? Although people get the wrong results from incorrect programming, I have found that often the issue is with incorrect data - they are helped a little by a GUI and a lot by a graphical presentation of what they have input.

Paul - I tried my own demonstrator, and it works as expected. Pinning the blame on something like PAUSE may not therefore be correct. I will go back and look some more.

Eddie

Eddie, this may or may not be helpful.

Each time I've gotten this or another similar error (i.e. 'there are two of these being commanded and you can only do this once'), it has been because I've detected an error while building a window, and another window (one of my own) is thus being created to display the error. For my errors, it made perfect sense, and was, in some cases, difficult to find using the error callback list.

I changed the code to perform all the error checking up front before the first ClearWin+ command is issued. In those rare cases where that cannot be done, the error detection and reporting is done to a file and/or a %cw.

I (currently) only use Win32.

Bill

Bill,

That's helpful advice, thanks, but not the answer here. I already caught a previous incarnation of the multiple %ca error where my pal had genuinely caused it by trying to open a dialog while building another dialog (your case, I believe), but we've checked this time and it isn't the case.

Eddie

Well, whatever the problem is (and it’s not PAUSE statements, because we took them all out), I have a workaround. I tried a benign WINIO@:

      IW = WINIO@ (‘%sf’)

and it popped up a dialog with no contents and no caption, so I doubt that there’s a WINIO@ of any sort before it, because if I run a program:

      WINAPP
      OPTIONS (INTL, DREAL)
      PROGRAM XXX
      INCLUDE <WINDOWS.INS>
      IW = WINIO@ ('%sf')
      END

I get exactly the same dialog with no caption and no contents. The workaround is to include:

      IW = WINIO@ (‘%lw’, IEXIT)
      IEXIT = 0
      CALL WINDOW_UPDATE@ (IEXIT)

This prevents a dialog popping up, at least, if it does then it disappears before anyone notices. Heaven only knows what it has trapped…

Eddie

Here is a direct way to obtain a 'Pause' without touching the ClearWin+ library...

program main
stdcall MessageBox 'MessageBoxA'(VAL7,INSTRING,INSTRING,VAL3):integer*4
 ir = MessageBox(0,'Click OK to continue','Pause',0)
end program main

May I seek for some information about the use of the argument descriptors VAL3 and VAL7 used in the previous post by Paul?

Hi Paul,

That's probably (certainly!) of interest to others, but my issue is the phantom extra %ca message that appears, and which we have only managed to kill off with the 3-liner workaround above.

I have told my friend that when we eventually find what is causing it it is more likely to be in his code than CW+, with blaming it on PAUSE grasping at straws. However, without a WINIO@ generating the phantom first %ca, I can't see how the error arises.

Eddie

jib

VAL3 represents an integer argument of KIND=3 passed by value.

VAL7 represents an integer argument of KIND=7 passed by value.

Usually you can deduce the meaning from the documentation for the routine.

VAL means passed by value. REF means paased by reference.

Eddie, I have one place where %ca caused sometimes crash because of it appears second time as error message claims. I suspect this is because previous window was not properly closed while creating new with its own %ca started.

Still my wish would be that instead of crash %ca has also use recently implemented (for other controls) safety mechanisms which will ask user to ignore this %ca instance and proceed at the expenses of the possible crash in the future if indeed something is wrong. Paul knows better if this already implemented or not, as i did not have such error for a long time

The ClearWin+ on my machine allow continuation after two or more %ca.

I don't know if this is a recent change.

Dan,

What you described is what is catching us out, although we cannot find any dialog that isn't properly closed with the text string in a WINIO@ call not ending in an ampersand (&). If such a dialog existed, it wouldn't work, and it would soon be found. We've tried that, and also scanned the code by eye, all without success.

Paul,

Now that's interesting, but two %ca format codes must be an error, unless there is a mechanism for deciding which has priority.

Both,

The workaround consumes very little.

Eddie

Eddie

It is an error and you get an error report with the option to continue or quit.

If you continue then you will get the last %ca value.