forums.silverfrost.com

[mhudson]

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:

[PaulLaidler]

Mark

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

[mhudson]

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.

[brucebowler]

From the help description, it says "will yield control to other tasks", not "will return immediately if nothing's there". If the wording was carefully chosen (I can't say one way or the other whether it was or not), to me "other tasks" would be other programs or threads, not something else in "the same task".

[PaulLaidler]

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.

[mhudson]

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

[mhudson]

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

[PaulLaidler]

Mark

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

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