Getcharqq() ignores keyboard entry in this circumstance

[mixed_message]

I'm calling a fortran routine from a c++ menu. The fortran routine simply asks the user a question, but makes use of getcharqq() to intercept the keyboard strokes and echo them as "*" to the screen like a typical passwork entry.

The first time I call the routine, the getcharqq() routine works as programmed. If I exit the fortran and return to the C++ menu, and invoke the fortran code again, the getcharqq() command no longer waits for the user to strike a key, but returns character 255 ( ANSI char code, it's a y with two dots over it ) in an infinite loop.

Background: The C++ routine calls a fortran subroutine that opens a console window (error1 = AllocConsole() ), and subsequently closes the console window ( freeconsole() ) after the fortran returns.

What can I do to fix this? Is there a way to flush the keyboard buffer? Is that even the right question?

[Steven_L_Intel1]

I recommend not closing the console until the application exits. getcharqq assumes that its handle to the console is still valid, and I think it may also get confused by non-Fortran code reading from the console.

You may want to consider an alternate approach to this input, such as a dialog box. I'm sure that the Win32 API experts here (I'm not one of them) may have additional thoughts.

[kent_hennessey]

Thanks for the reply. I need to close the console between application runs

[Jugoslav_Dujic]

Steve suggested not opening the console at all. It's fairly ugly practice to mix up pure GUI code with console I/O anyway, and you should do it if you don't have other options (and most often, you do). Normally, when you set up a GUI, all interaction with the user should go through dialogs, message boxes and like. Why don't you ask the user "a question" using a dialog in C++ and just pass the answer to Fortran code as an argument?