But why would we need to change all DispOut*() calls in order to implement some alternate method of coloring as Lorenzo suggested?
Implementing TBrowse for GUI platforms is IMO a completely different topic and it'd probably need a more serious rewrite (a GUI clone) just like ALERT() and friends. We already have xpp_TBrowse and we already have some extended stuff disabled by default in a few classes which could well go into such hb_<Clipperclass> classes. It's even possible (if justified) to add extended stuff to core class internals, what we must be careful of is to add all new *public* methods and variables to hb_* flavour to leave the original public interface intact. Brgds, Viktor On Sun, Apr 26, 2009 at 12:26 AM, Pritpal Bedi <bediprit...@hotmail.com>wrote: > > Hi > > >Exactly what I had in mind. > > This almost requires a rewrite of almost all the methods > of TBrowse just rendering subclassing futile. It is because > of DispOut | DispOutAt methods scattered all over. > In the past I had suggested to corner these calls to a > method of Tbrowse but the idea was declined, probably, > for the reason of performance, because of one more > layer to GT calls. > > I plan this extension for GTQTC++ family of GT's. > > BTW Tbrowse class is fairly stable at this moment so we can > take a chance to organise it as above and then subclass to > hb_Tbrowse. Then it will be only a couple of methods to > rewrite in subclass . > > Regards > Pritpal Bedi > > > -- > View this message in context: > http://www.nabble.com/Alternate-line-colors-for-tbrowse-tp23233265p23237147.html > Sent from the Harbour - Dev mailing list archive at Nabble.com. > > _______________________________________________ > Harbour mailing list > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour >
_______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
