Page 2 of 2

PostPosted: Mon Dec 17, 2007 1:27 pm
by Antonio Linares
NageswaraRao,

Its only three changes in the Class source code.

Could you show an example of your proposed change ? Thanks,

PostPosted: Mon Dec 17, 2007 1:28 pm
by nageswaragunupudi
This is a very useful addition to TXBrowse. Thanks to Mr Otto and Mr Antonio

PostPosted: Mon Dec 17, 2007 1:35 pm
by nageswaragunupudi
I now give here my changes to cFooter. I shall follow up with changes for font.
Code: Select all  Expand view
/*
   xbrfooter.prg
   inhertited class to deal with footer codeblocks
   if a few changes are made in the orginal
   source, this is not necessary
*/




#include "FiveWin.ch"
#include "InKey.ch"
#include "xbrowse.ch"

#ifdef __XPP__
   #define Super ::TControl
   #define New   _New
#endif

//-------------------------------------------------------------------------//
CLASS TXBRColFt FROM TXBrwColumn

   DATA   uFooter HIDDEN
   METHOD cFooter SETGET
   // FOR Comaptibilty with the recent change in FWH
   // if the FWH code is reverted to previous code
   // this bfooter method is not necessary
   METHOD bFooter SETGET

ENDCLASS
//-------------------------------------------------------------------------//
METHOD   cFooter( uNew ) CLASS TXBRColFt

   LOCAL cFooter

   IF PCOUNT() > 0
      ::uFooter   := uNew
   ENDIF
   IF ::uFooter != NIL
      cFooter   := IIF( VALTYPE( ::uFooter ) == 'B', EVAL( ::uFooter ), ::uFooter )
      IF VALTYPE( cFooter ) != 'C'
         cFooter   := TRANSFORM( cFooter, ::cEditPicture )
      ENDIF
   ENDIF

RETURN cFooter
//------------------------------------------------------------------------//
METHOD   bFooter( uNew ) CLASS TXBRColFt

   IF PCOUNT() > 0 .AND. VALTYPE( uNew ) == 'B'
      ::uFooter   := uNew
   ENDIF

   // returning nil to avoid evaluation of the block in the paint method
   // if the code in paint method is reverted to previous code
   // old code :  cFooter := ::cFooter  <-- this is better
   // then we can drop bFooter data and methods
   // cfooter can be assigned a value or codeblock

RETURN NIL
//-----------

Actually if we use the TXBrowse version prior to 7.12, the bFooter data / method is not necessary.

I adopted this apporach so that we do not have t o make too many changes in the original source. No dangers of breaking the original code even inadverttantly.

Also there is a minor issue with the 7.12 implementation of bFooter. Even after assigning the oBrw:lFooters := .T., if we do not scpecify Char value to atleast one cFooter, footers are not shown, To do that, we need to change code in many methods like for bRowFont. So was the need for me for this change.

PostPosted: Mon Dec 17, 2007 1:45 pm
by nageswaragunupudi
Proposed modification for Row Font:

Code: Select all  Expand view
#include "FiveWin.ch"
#include "InKey.ch"
#include "xbrowse.ch"

#ifdef __XPP__
   #define Super ::TControl
   #define New   _New
#endif

//-------------------------------------------------------------------------//
CLASS TXBRColFont FROM TXBrwColumn

   DATA   uFont HIDDEN
   METHOD oFont SETGET

ENDCLASS
//-------------------------------------------------------------------------//
METHOD   oFont( uNew ) CLASS TXBRColFont

   LOCAL ofnt

   IF PCOUNT() > 0
      ::uFont   := uNew
   ENDIF
   IF ::uFont != NIL
      ofnt   := IIF( VALTYPE( ::uFont ) == 'B', EVAL( ::uFont, Self ), ::uFont )
   ENDIF

RETURN ofnt
//------------------------------------------------------------------------//


-------------
VERY IMPORTANT CAUTION
-------------
Methods DataHeight and DataWidth are evaluated only once during initialisation phase of the browse. So the alterntive font objects should not be different in size or the data will not be painted correctly.

So the programmer should keep in mind that he should choose different variations of the samesize font like italics, strikeout, etc.

Recalculation of the heght and width while painting every cell may be too slow and not desirable.

PostPosted: Tue Dec 18, 2007 12:53 am
by Antonio Linares
NageswaraRao,

Though your proposed use of a SETGET method is a good and valid solution, it is quite different from the way that FWH uses the DATA oFont in other FWH classes, thats why we prefer to use it as we proposed

Anyhow, we thank you for your suggestions and comments