Console UI in a new Buffer

Welcome Forums General PowerShell Q&A Console UI in a new Buffer

Viewing 5 reply threads
  • Author
    Posts
    • #283051
      Participant
      Topics: 8
      Replies: 19
      Points: 163
      Helping Hand
      Rank: Participant

      Not sure if I’m even looking up the right terminology, and I’m a poor C++/C# programmer, but here’s what I’m trying to do:

      If you’re familiar with Linux commands like nano, vim, htop, or man, you’ll know that when you run the command, though it runs in the terminal, it doesn’t overwrite the text on the display once it’s exited. I believe the correct terminology is that it starts a new Buffer, and writes all it’s output to it, then when the command exits, it returns to the previous buffer.

      I’ve been looking to see if I can do something similar with PowerShell cmdlets I’m writing. I have the unfortunate task of making my tools accessible to lesser terminal users, hence why I’m spending the time thinking about the interface for a terminal UI.

      I can’t even figure out how to create a new console buffer, which is why I’m wondering if I’m even looking in the right spot. Any help would be wonderful.

    • #283300
      Participant
      Topics: 17
      Replies: 1951
      Points: 3,988
      Helping Hand
      Rank: Community Hero

      Can you provide an example of what is happening? Expected results? Not a *nix person, but it almost sounds like you want to do something like echo “Hello world” and you want that to happen in another session and come back to the main session?

    • #283456
      Participant
      Topics: 10
      Replies: 203
      Points: 996
      Helping Hand
      Rank: Major Contributor

      Having *nix experience, I believe I get what @mitchvh05 is after. Based on what I believe is the desired result, I dont believe it is possible in windows EXACTLY as you would get in Linux. Here is my interpretation of what @mitchvh05 is after:

      I am on a Linux box and I have a terminal open and I am at the prompt and want to edit a file using vim, I would enter “vim /path/to/file”. The terminal window would then open vim with my document to edit staying in and occupying the entire shell window. Once I exit vim, I am simply at the next line in the terminal window and dont lost previous shell content and or have to scroll to see it. Example:

      [[email protected] me]$ vim /path/to/file (file opens and I edit, then exit)
      [[email protected] me]$ (now I am back at the next line in the terminal)

      Now, on my windows box with VIM installed, this works the same way. But I believe the intent here is to run powershell scripts with the same behavior. The closest way I can think to do that is something like this which is ugly at best:

      start powershell.exe -Command “& {Start-Process PowerShell -ArgumentList ‘-ExecutionPolicy ByPass -File C:\Path\To\Script\MyScript.PS1’ -Verb RunAs}”

      Even with this method, you have no control over the spawned shell/script, but  you do get back to your original prompt in your original shell at the next line.

      I likely have it all wrong, just my $.02

    • #283516
      Participant
      Topics: 8
      Replies: 19
      Points: 163
      Helping Hand
      Rank: Participant

      Hey guys – thanks for spending a few minutes of your holidays trying to help me out.

      Can you provide an example of what is happening? Expected results? Not a *nix person, but it almost sounds like you want to do something like echo “Hello world” and you want that to happen in another session and come back to the main session?

      I don’t really have anything happening at the moment, I’m more looking for some direction to get the desired effect. I know it is possible in Windows — ntop does it perfectly fine — Just not sure that I can do this using PowerShell to interface with .NET.

      The effect should be as follows:

      1. User starts the console application, the entire console/terminal window blanks out for a sec, and get replaced with the console/terminal applications UI.
      2. The user does whatever they need to do
      3. The User closes the terminal application
      4. The user sees the entire console/terminal switch back to the text that was on the screen before — can scroll up like nothing ever happened.

      I don’t know if I can explain it better than that — however — if you’re familiar with chocolatey — you can quickly install ntop (it’s a terminal task manager) using cinst ntop.portable -y then run ntop — You can close out of ntop by pressing ‘q’ or ‘Ctrl+C’. You can then observe the behavior I’m looking to replicate. When the application closes, the (I believe it’s called) Buffer gets discarded, and the previous one gets set to active, and is displayed as if ntop was never on the screen at all.

      Hopefully that makes sense.

    • #283705
      Participant
      Topics: 8
      Replies: 19
      Points: 163
      Helping Hand
      Rank: Participant

      So, in typical PowerShell fashion, I found new utility in things I thought I knew completely already. At the very least, I can Get the Contents of the screen buffer, overwrite them, and then rewrite them once I’m done. Check out the Method members on $Host.UI.RawUI — and here’s a bad example I put together while bleary-eyed.

      $rect = [System.Management.Automation.Host.Rectangle]::new(0,0,$Host.ui.rawui.BufferSize.width,$Host.ui.rawui.BufferSize.Height);
      $COORD = [System.Management.Automation.Host.Coordinates]::new(0,0); 
      $OldBuffer = $Host.ui.rawui.GetBufferContents($Rect); 
      $NewBuff = $Host.ui.rawui.NewBufferCellArray(([console]::WindowWidth),([console]::WindowHeight),([System.Management.Automation.Host.BufferCell]::new(' ', 10, 0, 'complete'))); 
      $Host.ui.rawui.SetBufferContents($COORD, $NewBuff); 
      start-sleep -seconds 5; 
      $Host.ui.rawui.SetBufferContents($COORD, $OldBuffer)

      Hope one day  you folks get some use out of this.

    • #283960
      Participant
      Topics: 17
      Replies: 1951
      Points: 3,988
      Helping Hand
      Rank: Community Hero
Viewing 5 reply threads
  • You must be logged in to reply to this topic.