Correct way to open a fullscreen window and wait for response

[DJSures]

hey - I'm happy with your platform, it's been great to port a Winforms mono app to a CLI with .Net 7. My question is two-part, which is probably related to each other...

1. I have a "settings" window where I want to wait for a response because the user can either press SAVE or CANCEL. So I am using Application.Run(window) from my previous running application. Is that how you expect it? I couldn't find an example.

`
using (var settingsWindow = new FormSettings(_CF)) {

      Application.Run(settingsWindow);

      if (settingsWindow.Cancelled)
        return;

      saveConfig(settingsWindow.Config);
    }

`

And in the settings window, I'm closing the application with...
RequestStop();

2. When a user returns from Settings to the main application, a few things don't work correctly anymore. Specifically, a large TextView that I have populating for debug log. It just goes black with no more text being displayed. However, there is no TextView.AppendText(), so I'm doing this for every event...
   tbLog.MoveEnd(); tbLog.InsertText(txt); tbLog.InsertText(Environment.NewLine);

Is the unusual behavior of the TextView happening because I'm using the Application? Run<>() to open the settings window. What other facility does your platform have for opening another fullscreen window and waiting for a user response? Or should I switch to using events for the Settings window's cancel/save?

Also, another strange behavior when I use the Application.Run(window) is with MessageBox dialog popups. In the secondary window (i.e. settings window), the first time a MessageBox.Query is called, the window goes away, and the parent window is shown with the message box. With these strange behaviors, I have to assume that I'm opening a secondary fullscreen window incorrectly.

Unrelated stuff to my question. There are a few other things that I've done. I see the mention of requiring to Invoke for different threads, and there is no InvokeRequired(), so I created this for MainLoop...
`
int _mainThreadId = System.Threading.Thread.CurrentThread.ManagedThreadId;

public bool InvokeRequired() {

  return System.Threading.Thread.CurrentThread.ManagedThreadId != _mainThreadId;
}

`

I also found ListView and ComboBox limiting because there are duplicate references. So since the GUI objects are lifetime instances, they should own the data. In which case, I added these. Of course, the source needed to be changed from private to internal. But I wanted to make only a few changes to your code on my end, so it'll be easier to update with your new releases.

ListView2
`
using System.Collections.Generic;

namespace Terminal.Gui {

internal class ListView2 : ListView {

List<object> _list = new List<object>();

public void AddItem(object item) {

  _list.Add(item);
}

public void AddItems(params object[] items) {

  _list.AddRange(items);
}

public void ClearItems() {

  _list.Clear();
}

public void BindToItemList() {

  SetSource(_list);
}


public string SelectedItemText {
  get {
    return source.ToList()[SelectedItem].ToString();
  }
  set {
    var items = source.ToList();

    for (int i = 0; i < items.Count; i++)
      if (items[i].ToString() == value) {

        SelectedItem = i;
        break;
      }
  }
}

public object SelectedItemObject {
  get {
    return source.ToList()[SelectedItem];
  }
  set {
    var items = source.ToList();

    for (int i = 0; i < items.Count; i++)
      if (items[i] == value) {

        SelectedItem = i;
        break;
      }
  }
}

}
}
`

ComboBox2
`
using System.Collections.Generic;

namespace Terminal.Gui {

internal class ComboBox2 : ComboBox {

List<object> _list = new List<object>();

public void AddItem(object item) {

 
  _list.Add(item);
}

public void AddItems(params object[] items) {

  _list.AddRange(items);
}

public void ClearItems() {

  _list.Clear();
}

public void BindToItemList() {

  SetSource(_list);
}


public string SelectedItemText {
  get {
    return source.ToList()[selectedItem].ToString();
  }
  set {
    var items = source.ToList();

    for (int i = 0; i < items.Count; i++)
      if (items[i].ToString() == value) {

        SelectedItem = i;
        break;
      }
  }
}

public object SelectedItemObject {
  get {
    return source.ToList()[selectedItem];
  }
  set {
    var items = source.ToList();

    for (int i = 0; i < items.Count; i++)
      if (items[i] == value) {

        SelectedItem = i;
        break;
      }
  }
}

}
}
`

[tznind]

hey - I'm happy with your platform, it's been great to port a Winforms mono app to a CLI with .Net 7.

Awesome! glad to hear it! I'm pleased you are able to make headway using the library.

---

So I am using Application.Run(window) from my previous running application. Is that how you expect it? I couldn't find an example.

Yup that is the way to do it! The Dialogs example Scenario contains some code that does.

Alternatively you might want to look at RunColumnWidthDialog in TableEditor.cs Scenario which runs a modal popup to illicit user input and then passes that back to rest of the program.

---

Specifically, a large TextView that I have populating for debug log.

TextView is more of a text editor. In the past I have tried to use it for a scrolling log (as you are) and had difficulties.

Instead I would recommend trying ListView. This has worked for me in the past in my last job (See ConsoleGuiRunPipeline.cs). You can even implement IListDataSource yourself and so be in full control of how much history is retained etc.

Note that ConsoleGuiRunPipeline.cs was created with TerminalGuiDesigner so you will need to look at ConsoleGuiRunPipeline.Designer.cs too if you want to follow the example.

Screenshot of ConsoleGuiRunPipeline.cs running

---

I see the mention of requiring to Invoke for different threads, and there is no InvokeRequired()

This is correct. Terminal.Gui does not throw on cross thread access but typically you will have unexpected side effects or things stop working. So I always just use MainLoop Invoke when updating from Tasks/Threads and let Terminal.Gui handle it. There should be no side effects from invoking when already on the UI thread other than code readability.

If you anticipate hundreds of events a second or even just as good practice you may want to update your datastructures in real time but just use SetNeedsDisplay to notify the library that it should update.

  Task.Run(() =>
  {
      process.Start();


      while (!process.StandardOutput.EndOfStream)
      {
          var line = process.StandardOutput.ReadLine().Trim();


          lock(lockList)
          {
              consoleOutput.Insert(0,line);
              Application.MainLoop.Invoke(()=>_results.SetNeedsDisplay());
          }
          
      }
  });
}

Updating a List (consoleOutput) and setting needs display - Source Code

---

I also found ListView and ComboBox limiting because there are duplicate references.

Sorry, I'm not sure what you mean by 'duplicate references'?

For the code you have provided, are you able to reformat it as a diff or describe the changes at a higher level and why they were necessary. Understanding the limitations of current views is important so it would be good to get your insight here.

[DJSures]

Thanks, that's super helpful information.

1. By duplicate references, I mean that if I create a list to use as a data source, I'll have to keep a reference in my program and the terminal.gui object. Since the gui object is running for the lifetime of the program and is the thing the user interacts with anyway, it made sense for me to let the GUI object hold the primary reference to the list. That way, it's also easier to remember that the list is used in the gui object because I'm referencing the gui object to get the selected object/text. The only things missing from the combobox and listview are accessing the original Source since it's there anyway - why not expose it?

2. I'm trying to figure out what I missed in the examples you listed. I got that the underlying window can be updated in a worker by calling SetNeedsDisplay(). I tried that with this example on my About window. The issue is the lower window does not get redrawn, and the About window leaves a mess behind it.

`
private void aboutToolStripMenuItem_Click() {

  using (var t = new System.Timers.Timer()) {

    t.Interval = 250;

    t.Elapsed += ((object sender, ElapsedEventArgs e) => {
      Application.MainLoop.Invoke(new Action(() => {
        this.SetNeedsDisplay();            
      }));
    });

    t.Start();

    using (var f = new FormAbout())
      Application.Run(f);
  }
}

`

Before you answer that question with the Timer, is this even the right approach? Because I also tried opening the settings window on the main application thread and using the Closed event. I wanted the Full window Screen, the same size as the parent, but it will never render. It will render if I make the window small and specify the values explicitly, But it won't work if it's the same size as the parent.

`
FormAbout _formAbout;

private void aboutToolStripMenuItem_Click() {

  if (_formAbout != null) {

    Application.Top.Remove(_formAbout);

    _formAbout.Dispose();
  }

  _formAbout = new FormAbout();

  _formAbout.X = this.X;
  _formAbout.Y = this.Y;
  _formAbout.Width = this.Width;
  _formAbout.Height = this.Height;
  _formAbout.Closed += F_Closed;

  Application.Top.Add(_formAbout);

  _formAbout.SetFocus();
}

private void F_Closed(Toplevel obj) {

  if (_formAbout.Cancelled)
    return;

  // save my stuff here
}

`

[BDisp]

You are instantiate a new FormAbout without properly closing the prior instance. You must call Application.RequestStop() or FormAbout.RequestStop() and not Application.Top.Remove(_formAbout). That why you are having multiple windows on the screen.

[BDisp]

Another suggestion to reuse data between windows is using a toplevel with IsMdiContainer = true which allows having many non modal windows and also having a modal window. See the https://github.com/gui-cs/Terminal.Gui/blob/0d9b7dce31945af85c3dee7bdd06fd846a5ca048/UICatalog/Scenarios/BackgroundWorkerCollection.cs in the UICatalog project where you can maintain a log with a TextView or ListView. You can also store data in the Data property of the modal window and use it on the caller.

If you don't want to use MdiContainer you can also see the https://github.com/gui-cs/Terminal.Gui/blob/0d9b7dce31945af85c3dee7bdd06fd846a5ca048/UICatalog/Scenarios/SingleBackgroundWorker.cs in the UICatalog project.