Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!mips!sgi!shinobu!fido.wpd.sgi.com!marktwain.rad.sgi.com!linton
From: linton@marktwain.rad.sgi.com (Mark Linton)
Newsgroups: comp.windows.interviews
Subject: Re: Declaration of IV library classes
Message-ID: <1991May29.214221.2650@fido.wpd.sgi.com>
Date: 29 May 91 21:42:21 GMT
References: <1991May28.200149.11510@ge-dab.GE.COM>
Sender: news@fido.wpd.sgi.com (Usenet News Admin)
Reply-To: linton@marktwain.rad.sgi.com (Mark Linton)
Organization: sgi
Lines: 20

In article <1991May28.200149.11510@ge-dab.GE.COM>, vita@gloucester.dab.ge.com (Mark Vita) writes:
|> We have been doing application development using InterViews 2.6 for
|> about a year, generally with very positive results.  However, over
|> that time we have encountered several instances where we wanted to
|> subclass from various classes in the InterViews library, only to find
|> that we were effectively prevented from doing so because of the way
|> the classes in the library were declared.  To wit: member functions
|> that we wished to override were not declared "virtual", and data
|> members that we needed to access were declared "private" (and thus
|> unaccessible to our derived classes).  Our solution was to patch the
|> source code of our copy of the InterViews library to add the "virtual"
|> keyword where needed, and change the appropriate data members to
|> "protected".  However, we'd prefer not to have to do this, since it
|> means that our local copy of InterViews diverges from the "standard"
|> one.

You should send bug reports about such things (mail to interviews-bugs).
We won't make data members protected, but we will add appropriate access functions.
In this case, you should make sure to specify whether you need read access or
write access (or both).