Opened 9 years ago

Closed 4 years ago

#8105 closed bug (invalid)

BTextView: Erasing content outside TextRect

Reported by: bigmike Owned by: axeld
Priority: normal Milestone: R1
Component: Kits/Interface Kit Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All


I just started playing around with Haiku a bit and I tried to subclass BTextView to extend it so that it shows line numbers to the left. I was trying to do this by setting TextRect.left to something bigger than 0 and override Draw() like this:

void HelloView::Draw(BRect updateRect) {
	// Draw line numbers to the left of TextRect ...

I don't know if I am actually kind of misusing the API here, but when deleting lines (by pressing backspace) the TextView erases the content outside TextRect. I think the correct behavior can be achieved with the attached 1-line patch. :-)

Attachments (1)

BTextView.patch (614 bytes ) - added by bigmike 9 years ago.

Download all attachments as: .zip

Change History (6)

by bigmike, 9 years ago

Attachment: BTextView.patch added

comment:1 by bigmike, 9 years ago

patch: 01

comment:2 by axeld, 9 years ago

Status: newin-progress

comment:3 by axeld, 9 years ago

Thanks for the patch! I'm not sure it doesn't have unwanted consequences -- have you tried if resizing a BTextView doesn't leave any garbage behind?

To test this best, you could try to draw a rectangle over fTextRect with a BTextView that has insets via that text rect, and then resize the view.

In any case, it's kind of hard to customize the BTextView class as it wasn't designed for such a use case at all, unfortunately.

comment:4 by bigmike, 9 years ago

You are right, it's indeed not that easy. Even characters stay there when lines are removed. Now I thought, setting eraseRect.left = fTextRect.left should be safe, because there should be no characters to the left of the fTextRect.

But in fact that doesn't even help in my case, because the _Refresh method (where this drawing/erasing happens) is called from various points in the code directly, e. g. in _HandleBackspace(). This means the Draw() method of my subclass isn't even called in those cases, resulting in a dirty view. So I think BTextView really is not very suitable for sub-classing. You can probably close this ticket as invalid.

This drawing outside of Draw() without invalidating (parts of) the view seems a bit messy to me. I wonder if this is done intentionally this way? It probably saves a few method calls but it also kind of defeats the design, or am I missing something?

comment:5 by pulkomandy, 4 years ago

Resolution: invalid
Status: in-progressclosed

Closing as invalid on submitter's request. We can rethink the design of BTextView, but that will be part of R2 efforts. And yes, drqwing outsode of Draw() is a Bad Thing. It may be required to replicate some BeOS quirks here, I guess?

Note: See TracTickets for help on using tickets.