Use of GET_KEY_OR_YIELD@

Hi,

The help file suggests (to me) that this subroutine ought to work such that it is called repeatedly and only returns a key value if one is pressed, otherwise it does nothing. Perhaps I am wrong. Anyway, the following program:

      program keyboardtest
      implicit none
      
      integer :: i
      
      integer(kind=2) :: key
      
      do i=1,1000000
        write(*,*) i
        
        call get_key_or_yield@(key)

        key=0        
        if (key.ne.0) then
          write(*,*) 'Key pressed with return value: ',key
        end if
      end do
      
      end program keyboardtest

is supposed to loop over integers and display the key value each time a key is pressed. However, what actually happens is that the program prints '1' and then waits for me to press a key.

Have I simply misunderstood the use of the 'yield' in this routine's name?

Mark.

Mark

Why do you set key=0 after the call to get_key_or_yield@? Otherwise it works OK.

Hi Paul,

Not sure why I had that KEY=0 where I did, it was supposed to be before the call to GET_KEY_OR_YIELD@.

In any case, the routine still causes the program to wait for a key to be pressed. The 'YIELD' and the help file suggest that the program (i.e. the loop in this case) will run without the subroutine's getting in the way, until and unless a key is pressed.

Basically, the program prints the 1, then waits until I press a key, then prints the 2, then waits till I press a key. What I would like, and expected, is that the program will run through the loop, printing 1,2,3,... and the subroutine will intercept the keypress when it is made.

I have tried using ADD_KEYBOARD_MONITOR@, but this seems not to work with a console application.

The effect I am trying to achieve is to let the program (which is a console application) intercept, say, a Ctrl-D from the user, causing the program to dump useful output before the program then aborts itself.

Mark.

Yes, I think the yield is in the sense of a Windows exit to the main message queue. There may also be a Windows 'Sleep' element (to allow other threads a slice of time) but I would have to check the code for this. This has little or no effect in a console executable but in a Windows executable it will allow the message queue to be processed, so that, for example, the mouse will continue to respond.

Thanks for the responses. The upshot is just that I'd misunderstood the help file description. But can I go back to the other part of my question and ask if there is any way to get a console application to respond to a key combination if it is pressed, but to continue doing other things in the program if not? There are a number of Salford commands that deal with keyboard input, but they seem to require a Clearwin window or other window for which one can obtain the handle.

Failing that, has anyone out there been able to trap, for instance, a Ctrl-C in a console application by other means? Or is this sort of thing just not possible? Windows API-based ideas are welcome. I'll go off and browse the MSDN myself now.

Mark

Hi again,

Well, it seems that the example program given in the SET_TRAP@ function's documentation works as I had desired for trapping a Ctrl-C or Ctrl-Break, so you can close this correspondence if you like.

Unless, anyone has any other comments about how I might trap non-CtrlC key presses in a console application?

Mark

Mark

The following may be of interest.... [start up and then press the 'A' key]

include <win32api.ins> integer2 state,oldstate oldstate = 0 do state = GetKeyState(ichar('A')) if(state /= oldstate) then print, state oldstate = state endif enddo end