mirror of
https://github.com/rivo/tview.git
synced 2026-04-26 13:25:51 +03:00
[GH-ISSUE #141] SetBorder hides contents of List and TextView #111
Labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/tview#111
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @viktordanov on GitHub (Jul 21, 2018).
Original GitHub issue: https://github.com/rivo/tview/issues/141
When calling the SetBorder function on a List or a TextView (might be exhibited by other widgets too), no matter the argument, the contents of the targeted view get hidden and the view appears empty.
@rivo commented on GitHub (Jul 27, 2018):
I can't reproduce this. Can you send a short code snippet and a screenshot that illustrates this, please?
@viktordanov commented on GitHub (Jul 27, 2018):
Accourding to new observations, it appears that the issue is only present when the border is set using a chained
.SetBorderfunction, which is most likely due to the output of the function. I appologize, if this is meant to function like this by design.@rivo commented on GitHub (Jul 28, 2018):
I understand. Well,
TextViewinheritsSetBorder()fromBoxand becauseSetBorder()returns aBox, if you assign the result to a variable, you have aBoxon your hand, not aTextView:This means that in your example,
tviewwill callBox'sDraw()function instead ofTextView'sDraw()function so it ends up empty.I don't know of any way of changing the function's return value without duplicating all functions in the child classes. So at this point, the only thing you can do is this:
@viktordanov commented on GitHub (Jul 28, 2018):
I understand. Sacrificing good code structure for a little convenience is never worth it. Thanks for taking your time. 👍
Should I close this?
@rivo commented on GitHub (Aug 4, 2018):
I'll close it.
Not sure I'd say "never". I'm still wrestling with this decision because I tend to think that the convenience for the users (i.e. the developers who use
tview) is more important. But it increases the boilerplate for every new primitive I introduce in the future, it duplicates a lot of code and documentation. And that's always a source for mistakes.