As noted in a post today, it's useful for applications/subclasses to access Fl_Help_View's scrollbars to, for instance, hide() them.

They are currently private: and are instances named scrollbar_ and hscrollbar_.

Options I can think of:

1. Make scrollbars "protected:" or "public:" and named appropriately for direct access.
2. Expose scrollbars via accessor methods that return pointers
3. Expose scrollbars via accessor methods that return references
4. Other?

Precedents:

• Fl_Scroll exposes scrollbar and hscrollbar as public instances
• Fl_Browser exposes "scrollbar" and "hscrollbar" as public instances
• Fl_Text_Display exposes *mHScrollBar and *mVScrollBar as protected pointers
• Fl_Tree exposes *_vscroll and *_hscroll as protected pointers
• Fl_Table exposes *vscrollbar and *hscrollbar as protected pointers

I'd like to hold back my vote on which I prefer for last, just to see what everyone thinks, as I'm not really sure what's best.

What I can say is:

• I don't like camel case exposed in Fl_Text_Display for its scrollbar member names, so let's not do that
• I don't think it's good to expose members with underbars as a prefix or suffix (e.g. Fl_Tree)
• I like the names "scrollbar" and "hscrollbar" for vert/horiz scrollbars respectively. Whether we should expose them as methods or direct access, not sure. I generally prefer using pointers for everything, just so construction time can be specific, but there may be reasons why FL_Help_View uses instances instead of pointers and 'new'.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.