Non-blocking console input.

Question

0.00/5 (No votes)

See more:

Hello,

I have a little problem with my application. It's an console application.

The application receives a lot of data when connected to server and I cannot block the connection for too long time. So I created another thread which handles the messages (GetMessage). So now certain data packets invokes action which needs user input. I use PostThreadMessageA with custom messages so the user can fill in information and the recv thread isn't blocked by std::cin.
That works quite well.

But now I would like to add some command handler like ".resenddata". I would create another thread for that, but it wouldn't work well with GetMessage thread (Two std::cin doesn't work very good when called at the same time in the 2 different threads).

Any idea how to solve this situation.

Some points I would like to remind:
- The Recv thread must not be blocked by user input because server sends you data all the time.
- Some received packets requires user response. For example "Auth request".
- I want to be able to control some actions of the application by commands.

Thank you for your help and ideas.

Posted 21-Jun-11 6:33am

Im2N00By

Add a Solution

2 solutions

Solution 1

You can easily use threads with console application if you only write to console. The thread will share the console for output, mixing the output lines somehow. You can handle it nicely and use Critical Section to interlock blocks of text. This is how threading techniques are often demonstrated.

Technically, you can do it with console input as well, but it will make the console extremely messy: strings will be added and console scrolled down as you type. Serious console application rarely use console input. If you use threads writing to console, avoid input. You can use command line parameters instead.

If you need interactive input with multithreaded console output, consider creating a windowed application. Simulate console output in one control (a list view is a perfect candidate for keeping output lines), and organize input separately from you simulated console using regular input control. You can create console copy/paste, data validation and other nice feature.

—SA

Posted 21-Jun-11 8:00am

Sergey Alexandrovich Kryukov

Comments

Im2N00By 21-Jun-11 15:40pm

I tried to avoid the window implementation, because it requires a lot of additional coding. And code gets easily messy. I think I will keep the application without control for now. Will be much harder to use (because server sometimes gets buggy), so I will have to restart application.

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

TRK3 · Accepted Answer · 2011-06-21T12:34:00

If I understand this correctly, you have a working console application that handles the received data and the required user response in one window.

Is that right?

And the problem you are running into is that you'd like to have a way for the user to also input additional commands, but you can't use std::cin for that input because that is already being used for required user responses.

If you want to keep this as a console application, then you need a different stream for the input to the command handler.

Try starting a second console window and execute the command "copy con tmpfile.txt" whatever you type in that console window will be written to tmpfile.txt each time you hit return (until you hit ^Z to signal end of file).

You should then be able to read from tmpfile.txt in your console application and use that as your command input stream. I'm not sure how end-of-file on tmpfile.txt will appear in your console application, so you might have to loop and test for the file size changing on tmpfile.txt.

If that works for you, then you could add have your console application actually spawn the other command window to execute "copy con tmpfile.txt" at startup.

That will get around writing a windows application.

(Frankly, once you get familiar with windows applications, it's not that much more code to write, but if you are just starting out or are coming from a unix background, then the approach I've outlined should work for what you need.)