Silverfrost Forums

Welcome to our forums

Cannot get 'keyboard_monitor' to work.

18 Oct 2015 5:31 #16933

G'day, folks 😄

Can anybody offer a suggestion as to why the following program doesn't work - at least on my machine running 64-bit Windows 7 Home Premium.

Nothing happens when I hit a key at random. Ctrl-C is needed to abort the program.

It's not the entire application, just an extract to investigate why the keyboard monitor facility doesn't work for me.

C
      integer keyin
      character do_this*12
C
      common keyin, do_this
C
      include <windows.ins>
C
      external kb_input
C
      keyin=0
      do_this='KEYBOARD_KEY'
C
      call add_keyboard_monitor@(kb_input)
C
      write(5, 91)
91    format(' Hit any key: ',$)
C
C loop to await an entry at the keyboard
C
100   if(keyin .ne. 0) goto 200
      goto 100
C
C display the character code for the single input key, then pause
C
200   write(6,211) keyin
211   format(' From keyboard = ', i10)
C
      call remove_keyboard_monitor@(kb_input)
C
      pause
C
      stop
      end
C
      integer function kb_input()
C
      integer keyin
      character do_this*12
C
      common keyin, do_this
C
      include <windows.ins>
C
      keyin=clearwin_info@(do_this)
C
      kb_input=1
C
      return
      end
C

Compilation and linking were done from a batch file:

C:\Users\Eric\Desktop\Program_Files_ex_C\Silverfrost\FTN95\FTN95 -c fdisplay.for /check /dump /list
C:\Users\Eric\Desktop\Program_Files_ex_C\Silverfrost\FTN95\SLINK fdisplay.obj -file:fdisplay.exe

And the listing file, with the line-numbered code removed, reported nothing untoward:

Silverfrost FTN95/WIN32 Ver 5.50.0  fdisplay.FOR  Sun Oct 18 13:20:44 2015

Compiler Options in Effect:
    CFPP CHECK COLOUR DELETE_OBJ_ON_ERROR DUMP LIST MINIMISE_REBUILD  NO_QUIT 
    NON_STANDARD SINGLE_THREADED 

   	Dump of all variables in MAIN@

	Local Variables
                INTEGER(KIND=3) FUNCTION WINDOW_PRINTF@      WINDOW_PRINTF@      (at line 175)
                INTEGER(KIND=3) FUNCTION WINIO@              WINIO@              (at line 177)
//              CHARACTER(LEN=12)    DO_THIS             @ 4   (at line 4)
//              INTEGER(KIND=3)      KEYIN               @ 0   (at line 2)

	Total stack size: 24 bytes
	Total static size: 105 bytes

	Dump of all variables in KB_INPUT

	Local Variables
                INTEGER(KIND=3) FUNCTION WINDOW_PRINTF@      WINDOW_PRINTF@      (at line 9683)
                INTEGER(KIND=3) FUNCTION WINIO@              WINIO@              (at line 9685)
//              CHARACTER(LEN=12)    DO_THIS             @ 4   (at line 9512)
//              INTEGER(KIND=3)      KEYIN               @ 0   (at line 9510)

	Total stack size: 16 bytes
	Total static size: 112 bytes

End of Compilation - Clocked 0.76 seconds

Eric, in Perth, Western Australia

18 Oct 2015 2:38 #16934

The keyboard monitor works with a user-created window (ClearWin+ for example).

When I compiled and ran your code, I got a DOS style window. When you have input in the DOS style window, the keyboard monitor will not work.

Depending on what you ultimately wish to do, the keyboard monitor may (or may not) be the proper option for you.

18 Oct 2015 8:48 #16935

Quoted from wahorger

When I compiled and ran your code, I got a DOS style window.

Thank you for your comments, wahorger; they are much appreciated.

Having learned Fortran and Assembler on five different machines in the days when 'windows' meant openings in walls I was expecting something akin to 'pass-thru' mode, where everything entered at the keyboard, including all the control characters, was passed directly to the program.

Old familiarities are imbued with immortality, it seems.

Thanks again 😄

Eric

19 Oct 2015 4:03 #16936

Happy to be of some help, Eric.

19 Oct 2015 5:11 #16937

Quoted from wahorger

Happy to be of some help, Eric.

And thanks again 😄 Here's my chance to explain a bit more fully the history of the project; the project being to modernise (make Window-ful) a program I wrote decades ago.

That program was to set up a command file for SASGraph, the file being executed in batch mode.

Part of the program displayed a list of printer device options, for example, on the old line-oriented screen ...

APLPLUS Apple Laserwriter Plus (PostScript) 10/17/96 APPLELW Apple Laserwriter (PostScript) 10/17/96 APPLELWM Apple Laserwriter A4 paper 10/17/96 ... ...

... and finish each screenful with a prompt inviting the user to enter a device name (the first, maximum of 8, characters in each displayed line), thus:

C
160   write(6,161)
161   format(' Enter device name ',
     1'(Control-Z to quit) > ',$)
      read(5, 171, err=100, end=100) device
171   format(a8)
C

(Hit 'Return' or 'space' for next screenful, Control-Z if the desired device was not listed)

In the 'olden' pre-Windows era my assembler subroutine interrogated the keyboard, echoed any ASCII character entered, and responded immediately to Control-Z.

( %rs in ClearWin does unpredictable things with Control-Z; highlights characters already entered, and/or deletes all but the first character. In any case, the Control-Z is not an option available to the programmer. )

Of course, in writing this, I've realised that the 'modern' approach is to highlight the selection and then click somewhere.

That's a synopsis of what I'm trying to achieve - gain control over that Control-Z - or some other control character.

Eric

19 Oct 2015 2:04 #16940

I, too, took a very old FTN program (circa 1985) and reworked the human interface. I understand some of the issues you are having; my code also used specific control codes to allow navigation through the user menus.

My suggestion would be to replace the edit box with a list box, using %ls, that shows the options and allows the user to select the one they want. In the dialog box, supplying a CANCEL button and associated code to process that action gives you a way of backing out of the selection process as well. You likely already have the data in the appropriate format (an character vector) and the code to implement is easy enough.

I use cascading list boxes to allow users to perform map selection, selecting the state first, which updates the list of quadrangle names, which in turn updates the list of map scales available. The coding is not difficult and my users like not having to type anything, just select what they want. I use the same concept in many places to preclude typing errors.

19 Oct 2015 6:10 #16941

Quoted from wahorger

... and my users like not having to type anything, just select what they want.

Yes, that's important - user acceptance. I think it must be the secret wish of every programmer 😄

But programmers might be on the list of endangered species. Gone are the days when students drew every histogram, calculated every standard deviation, before ever considering more complex methods of analysing their data. Nowadays all they want to do is plug their data into some commercial package that gives pretty output.

They say that nostalgia is the balm that eases the way into the future. I'm sure that my epitaph will read something like 'His greatest moment was discovering encode and decode in Fortran.'

Thanks for the list box suggestion; that shall be part of my future 😄

Eric

19 Oct 2015 8:24 #16942

This compiler has everything needed to make the program react both ways, DOS or Windows, possibilities are endless, just read the the GUI manual which is actually fun to read (this was the only manual i ever red almost completely in my life before it was combined with the FTN95 manual). I used first way 20 years ago, but now use only Clearwin Windows interface.

21 Oct 2015 4:53 #16945

Just a guess, but Dan may be referring to the Fortran Clearwin manual, a digital copy of which may be found on this website.

Eddie

Please login to reply.