Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prompting for user input causes display issues. #158

Closed
dan-da opened this issue Mar 23, 2020 · 3 comments
Closed

Prompting for user input causes display issues. #158

dan-da opened this issue Mar 23, 2020 · 3 comments

Comments

@dan-da
Copy link

dan-da commented Mar 23, 2020

I can't seem to prompt user and read from stdin without causing display issues. Is there a standard/supported way to do this?

I have two progress bars, eg:

[--------------------]   Current FIle
[--------------------]   Entire Multifile Transfer

If a file already exists, I need to prompt the user, eg:

[--------------------]   Current FIle
[--------------------]   Entire Multifile Transfer
File `/path/to/file` exists.  Overwrite? [Y/n]

Presently I am doing this with a call to print!(), and stdin.read_line(). Unfortunately, it causes the progress bars to scroll up the screen leaving duplicates that are never cleared.

So, I am wondering if there is a good/supported way to do this, or else, can there be?

I thought about a couple possibilities:

  1. Use ProgressBar::println!(). Except this would print the prompt above the progress bars (undesired), and adds a "\n" after prompt (undesired) and does not provide a way to get user input (required).

  2. Create a 3rd progressbar where the prompt is displayed via set_message(). I tried this, but stdin read from next line, and hitting enter causes scroll plus paint issues.

@mibac138
Copy link
Contributor

Would an API to show and hide progress bars be an appropriate solution to your problem? It'd allow you to hide the progress bar when prompting the user and then showing it back afterwards. You can check set_visibility out here or here with PR #132 included.

@dan-da
Copy link
Author

dan-da commented Mar 24, 2020

I think that would be acceptable/workable provided it paints in the same place after a line is manually printed and user presses enter. If I can find some time later, I will make a test case that demonstrates the issue and also try out the visibility branch.

@djc
Copy link
Collaborator

djc commented Feb 22, 2022

#333 added ProgressBar::suspend(), which I think could solve this issue. Going to close this for now, though you should feel free to reopen if you think this doesn't address your use case (well).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants