Re: [PATCH 2/4] Return true in TuiWindow.is_valid only if TUI is enabled

[Hannes Domani via Gdb-patches <gdb-patches@sourceware.org>]

 Am Montag, 18. Januar 2021, 11:31:00 MEZ hat Andrew Burgess <andrew.burgess@embecosm.com> Folgendes geschrieben:

> * Hannes Domani <ssbssa@yahoo.de> [2021-01-17 13:19:41 +0000]:
>
> >  Am Sonntag, 17. Januar 2021, 12:31:05 MEZ hat Andrew Burgess <andrew.burgess@embecosm.com> Folgendes geschrieben:
> >
> > > After further though I think there's an even better solution for this
> > > issue.  See the patch below.
> >
> > This version crashes for me when I disable and then re-enable TUI, because
> > tui_windows and tui_win_list are empty, not filled again in tui_enable, and the
> > tui_update_gdb_sizes call at the end of tui_enable dereferences
> > TUI_CMD_WIN.
>
> That's annoying.  I would have sworn I'd tested that.  Guess not.
> I'll take a look at this later today.  I guess something that's
> currently conditional will need to become unconditional so that the
> windows are recreated when the tui is enabled.
>
> >
> > Also, and I think your previous patch behaves the same, but I can no longer use
> > the TuiWindows variables width/height/title inside my Window.close function,
> > because at this point tui_active==false, so the assertion inside is_valid
> > fails.
>
> OK, I think this one should be easy enough to fix.
>
> Out of interest, what do you do with the width/height/title in the
> close method?  Given the window is about to vanish I'd have thought
> all you'd be doing at this point is internal object clean up?

I have all my TUI windows in a dictionary, with the window title as key.
And on Window.close I remove the window from the dictionary.


> > This can be worked around by saving the values in some Window class members,
> > but it is more inconvenient.
>
> I think my fix will mean you don't need to do this.

Thanks.


Hannes