\"Just the one\" - 'beep', that is.

G'day, folks 😄

The program shouldn't beep. I mean, no compilation or runtime errors are flagged, and so far the program hasn't crashed, even after beeping serially.

But beep it does, which makes me apprehensive about releasing it onto an unsuspecting public.

At risk of misleading anybody (enough of that in the wake of MH370) the beep only occurs when a window is closed by clicking on the 'X' in the upper right corner of the window.

Now my question is - could an Exception Handler reveal the mystery of the beep? There seems to be plenty of handlers available, having Googled 'silverfrost ftn95 exception handler' and the program already uses the 'divide by zero' exception handler.

But should it more accurately be viewed as a Clearwin problem? I Googled 'silverfrost clearwin exception handler' but found nothing that I could use, although to be fair I didn't closely dissect any of the 'hits'.

I can make the program available via my website, if that would help, but it's probably unnecessary without anybody also delving into the code.

Eric

It would be a good idea to localise the problem by masking out sections of your code - divide and conquer.

I would be looking for a local variable that has been accessed (by ClearWin+) when it has gone out of scope - i.e. a bug in your program.

One way to test for this is to make all local variables SAVEd - just as a test to see if the problem goes away.

For example, a common error is to omit to SAVE the variable associated with %lw - this would normally be declared in a COMMON block or a MODULE.

Quoted from PaulLaidler It would be a good idea to localise the problem by masking out sections of your code - divide and conquer.

Thankyou, Paul! 😄

I've isolated the problem to how the program handles keyboard input - a conjunction of the statements -

C
      external start_routine_keyin
C
      call add_keyboard_monitor@( start_routine_keyin )
C
      flags(30) = CLEARWIN_INFO@('KEYBOARD_KEY')
C
      call remove_keyboard_monitor@( start_routine_keyin )
C

( flags(30) is an element of an integer array held in labelled common throughout the entire program )

I was surprised to see control characters such as Ctrl-A and Ctrl-B returned (displayed via ia=winio@('%wd&', flags(30))

) as decimal values 513, 514, etc, while upper-case characters yielded the expected 65, 66, etc.

Looks like it will take some deep pondering and further experimentation to discover what the program is complaining about. But I'm sure the 'Eureka!' moment will make it all seem worthwhile 😄