Ideas on how to implement "ESC will force SYSTEM" at any time?

[FilipeEstima]

Is there a simple way to make a LONG program do its duties, while all the time checking if ESC is pressed - and if that's the case, immediately interrupt everything and do SYSTEM? That is, without creating a subroutine to check if INKEY$ equals to ESC and inserting GOSUBs to it, in *every single part* of the code?

I guess it would need a routine that works on interruption.

[Jack002]

Have you looked at the help area for the keyword INTERRUPT? I see there is a provision for it. I've never used it.

Are you a commodore 64 user? The C64 has one, the restore key. It does just what you're asking.

[FellippeHeitor]

Use a TIMER:

Code: QB64: [Select]

1. ON TIMER(.03) checkESC
2. TIMER ON
3.  
4. DO
5.     'this emulates your program doing its thing
6.     _LIMIT 1
7. LOOP
8.  
9. SUB checkESC
10.     IF _KEYDOWN(27) THEN SYSTEM
11. END SUB

Also, at any time you can hit Alt+F4 (or just close the window).

[FellippeHeitor]

Have you looked at the help area for the keyword INTERRUPT? I see there is a provision for it. I've never used it.

Are you a commodore 64 user? The C64 has one, the restore key. It does just what you're asking.

Whatever INTERRUPT usage is accepted by QB64 is emulated and should be avoided in new code. Just makes no sense anymore since we're not directly talking to hardware these days.

[bplus]

I worked up an example with ON TIMER

Code: QB64: [Select]

1. t1 = _FREETIMER 'get a timer number from _FREETIMER ONLY!
2. ON TIMER(t1, .05) TimerEvent
3. TIMER(t1) ON
4.  
5. 'some old code to keep us occupied
6.  
7. 'fully factor.bas SmallBASIC 0.12.6 [B+=MGA] 2016-06-11
8. m = 2
9. WHILE 1
10.     n = m
11.     PRINT "Next n to factor is"; m
12.     DO
13.         fd = 0: test = 2
14.         WHILE test <= n ^ .5
15.             IF n MOD test = 0 THEN fd = test: EXIT WHILE
16.             IF test = 2 THEN test = 3 ELSE test = test + 2
17.         WEND
18.         IF fd THEN n = n / fd: PRINT fd; " "; ELSE PRINT n
19.     LOOP UNTIL fd = 0
20.     m = m + 1
21.     _LIMIT 10
22. WEND
23.  
24.  
25. SUB TimerEvent
26.     IF _KEYDOWN(27) THEN END
27. END SUB
28.  
29.  

ESC does stop the program

[Pete]

A good design would have your whole program in a DO/LOOP, so INKEY$ was being constantly polled between events. If that structure isn't easy to do, or impossible, the way to still achieve what you are asking for is to use ON KEY...

Example. Press Esc to terminate this program.

Code: QB64: [Select]

1. KEY (15), CHR$(1) ' CHR$(1) is the scan code for the escape key. KEY 15 is one of the user defined ON KEYs available.
2. KEY(15) ON
3. ON KEY(15) GOSUB trap
4. PRINT "Press Esc to quit."
5. DO: _LIMIT 30: LOOP ' Your program code would replace this endless loop.
6.  
7. trap:
8. SYSTEM
9.  

Pete

[Raven_Singularity]

CHR$(0) is a NUL byte.  CHR$(27) is Escape.  Hmm?

[Pete]

CHR$(27) is Escape.  Hmm?

Not in %$%^$^ scan codes it isn't. It's CHR$(1).

Pete

[FilipeEstima]

Thanks guys, I'll give these suggestions a shot.

[SMcNeill]

One thing to note:  Some commands take *total* control of your program and *can not* be easily interrupted.   From the top of my head, if I’m remembering correctly, INPUT is one of them.  If you need a program to be response to various key/mouse states, at all times, be certain to never use INPUT in that program.  Use INKEY$, _KEYHIT, _DEVICE, INP, or some other method to get input from the program. 

INPUT itself takes total control and waits for that valid ENTER press before it releases control and resumes normal program operation.

[Pete]

One thing to note:  Some commands take *total* control of your program and *can not* be easily interrupted.   From the top of my head, if I’m remembering correctly, INPUT is one of them.  If you need a program to be response to various key/mouse states, at all times, be certain to never use INPUT in that program.  Use INKEY$, _KEYHIT, _DEVICE, INP, or some other method to get input from the program. 

INPUT itself takes total control and waits for that valid ENTER press before it releases control and resumes normal program operation.

Steve makes a good point, because not even ON KEY will get you out of an INPUT or LINE INPUT wait for user input statements. I've always considered INPUT and LINE INPUT to be beginner statements or just available if you are making a quick and easy utility and you don't want to bother to write just a couple more lines of code.

One thing I will give ON KEY is that even though it uses GOSUB, you can still get the key to respond while you are in a sub.

Code: QB64: [Select]

1. KEY (15), CHR$(1) ' CHR$(1) is the scan code for the escape key. KEY 15 is one of the user defined ON KEYs available.
2. KEY(15) ON
3. ON KEY(15) GOSUB trap
4. PRINT "Press Esc to quit."
5. CALL waitforit
6.  
7. trap:
8. SYSTEM
9.  
10. SUB waitforit
11. DO: _LIMIT 30: LOOP ' Your program code would replace this endless loop.
12. END SUB
13.  

That was good engineering, but why they didn't make a way to get it to interrupt an input statement is beyond me.

Pete