When setting the label of a BTab, the BTabView's tab bar is not invalidated

[waddlesplash]

As in title.

The BTab object has no way of knowing what BTabView it's currently in, and thus no way of calling Invalidate(). So I'm not sure what the proper solution to this problem is.

[axeld]

The proper solution for now is to document that you have to call BTabView::Invalidate() manually after having updated the title (and eventually InvalidateLayout(), too, right?).

Once we replace the interface kit with something amazing, we could also look into this issue again :-)

[waddlesplash]

Is there a reason we can't make the BTab call Invalidate?

[pulkomandy]

tab->View()->Parent()->Invalidate()?

[axeld]

Replying to waddlesplash:

Is there a reason we can't make the BTab call Invalidate?

I just trusted your judgement that it has no way of knowing its BTabView. Apparently, I shouldn't have done that.

[waddlesplash]

I just trusted your judgement that it has no way of knowing its BTabView. Apparently, I shouldn't have done that.

No, my judgement is correct, and PulkoMandy's isn't. The reason is that there are two forms of BTabView (as far as I can tell): the BCardLayout version, and the non-BCardLayout version. The code is a bit convoluted, but in the non-layout version, when BTabs are not the "current tab", they aren't actually a child of the BTabView at all -- they're technically parentless. And when adding a BTab to a BTabView, the BTabView does not pass a pointer to itself to the BTab, so there are at least some cases where the BTab cannot get the BTabView via ->Parent() chains.

So we can solve the problem by:

• getting rid of the non-layout version (I can't tell what it's used for, exactly)
• making BTabView call a hook function to give BTab its address
• adding some other way for BTab to get the BTabView it's a part of

I don't know which is the correct solution, which is why I opened this ticket rather than just implementing something.

[axeld]

Ah, sorry! The non-layout version obviously cannot be removed, as it is part of the Be API.

Can't we just solve the issue for the layout version, and leave the original version as is, and just document the fact? I wouldn't put much work into that, as the issue exists since almost 20 years for the original version of BTabView, when it can be easily solved for the layout version of it.

[pulkomandy]

Does it work in BeOS? If so, we should make it work too, otherwise, we should just document it.

[waddlesplash]

Well, one of the solutions (pass the BTab a pointer to the BTabView) will work both on layout and non-layout, so unless you see a reason not to use that one, that's the one I'd pick.

[axeld]

If the solution that Adrien suggested works with the layout version, I'd use this, as it almost doesn't require any changes. That's only if the bug existed on BeOS, too (as I would expect) -- for existing software using the non-layout version, they will have worked around that bug already, anyway.

[waddlesplash]

I seem to recall trying that solution on a BTabView that was part of a layout, so I don't know why it wouldn't've worked, but I don't think it did. Anyway, I don't have any BeOS installs that work, so if someone with a BeOS install could please test this, that'd be excellent.

[pulkomandy]

Do you have a test program I can easily run? I can write one myself, but if you already have one it would help. And we can add it to our test suite.

[markh]

Is this in anyway related to #12108? I added a test case for that which works on BeOS R5.

[waddlesplash]

Yes, they have the same root cause: the BTab has no way of invalidating a BTabView.

Thanks for the tip, now we know that BeOS R5 does the right thing!

[waddlesplash]

Fixed in hrev49398.