Close console after pressing ESC in program?
 

I have a non-window asm program that in Workbench spawns a console process when you run it, and in its main loop I check $bfec01 for ESC to end the program if it was pressed.

However, this has a problem... The program itself does end, but the console is kept open until you press enter. I think the reason for this is that it's listening to stdin, and an ESC press will put one character into stdin, and the console is waiting for you to press enter. Is there any way I can get rid of this problem? I want the console to quit together with my program. I don't really want the console to print any key presses.

My main loop looks like this:

Not enough information. What means "spawn a console"? If you open a console window with stream=Open("CON:...",MODE_NEWFILE), you close the window with Close(stream).



Besides, if you want to wait for a key pressed, why don't you open a RAW: window and wait for a key by a Read() on the stream? Poking the hardware is considered very bad practise.


WaitTOF() is not your "generic delay function". For that, please use dos/Delay() instead. WaitTOF() may do something different on graphics cards.

Any program that doesn't attempt to open an Intuition window, will spawn a console when ran in Workbench. That's my understanding of it, at least. I don't spawn a console manually.

Because it's the simplest way, I'm new to Amiga programming, and I still need the main loop to be up and functioning.

I'm fully aware, I'm using it to wait until all vblank interrupts are done so that I'm in "idle time" in the frame. http://amiga.nvg.org/amiga/reference.../node048B.html

No, it doesn't. If you use "Execute" from the workbench window, or XIcon, your program will executed from a shell, and the shell will open the window, and in the shell, your program will execute. The workbench will open an AUTO/CLOSE/WAIT window, which means it will stay open until the user closes it.

Whatever. Whenever I run the binary, it opens a console. Maybe because I print messages?

Create an icon for your program, and make sure you handle the workbench startup mechanism. No, a program that has been started by the workbench process does not receive a console.

EDIT: I see, my program is not spawning a console, but an "output window". I have the same problem there as when running it from the shell:
When I press ESC, the process terminates (music stops), but the output window is kept open with an ESC character printed to its character buffer. Shell is also just showing the ESC character in its output buffer instead of getting back to prompt.

In the case of running it from a shell and pressing ESC, you just press enter and the shell will get back to the prompt. In terms of the output window, you have to manually close it. Quite annoying! I wish I could get rid of both symptoms, e.g. shell goes back to prompt after pressing ESC, and output window closes after ESC (if you ran it through double-clicking on the program).

If you start from Workbench, there is no standard output file handle, so it sounds like your debug output function is fnding the fact that there is no handle and therefore opens this "output window".

Are you linking to a pre-built library (like amiga.lib) and then using something like a printf for your debug messages?

They are not debug messages, they are the program's actual output by calling _LVOPutStr. It prints messages and then enters a loop until you press ESC. And no, I don't link anything.
The program is an XM player that for the time being works in the console (or the output window if you didn't run it from the shell). I want the user to see the messages, it shows important information.

Anyway, this thread is a mess, I see now that I managed to not ask what I really wanted to ask, and it shows confusing messages. :D

Any program run from a WB pseudo icon will spawn an "output window". This window will not close until the user presses the close button and AFAIK you have no control on this.
But it won't physically open if nothing is done with input/output handles.
So I think you'd be better off by opening your own.

Another problem is that you're peeking the keyboard without proper handshaking and with the OS still running - i.e. pretty dirty but this looks temporary.
Either use the OS to get keyboard input (don't ask ME how :)), or turn it off and do correct keyboard reading (which is not that easy either). Or keep actual code, but this is only valid for a test program.

Ok, I see. I think I'll end up programming a small GUI for the player instead. However, I need to be able to have a loop that runs WaitTOF twice and then mixes audio samples. Is this possible when you have an Intuition/window loop instead?
I can't use a vblank interrupt for this, because I'll not end up in idle time. This is important, the mixer should only mix samples in idle time so that it doesn't slow down the system.

You can open a CON window yourself and use that instead of stdin/stdout. Then you have control over closing the window and next to no changes in your program.

Maybe I should. But how will it act when I run the player from within the shell? Will the current shell stall, and a new console opens?

Check in your program if it runs from workbench or a shell - if shell, assign stdout to your output stream variable, if workbench, open a console yourself and assign its output stream to your variable.

Yes, you can have a window and still use your WaitTOF pair. Just poll intuition events (without waiting) before or after each of them.


The current shell will stall, unless you launch your program with the run command.