xBrowse Report

[PeterHarmes]

Hi,

i'm trying to use the :Report() function in my xBrowse, but the widthes of the columns on the report do not represent the columns in the browse. The columns in the report are far too big and therefore only 2 columns usually show. Any ideas how to fix this?

Regards,

Pete

[James Bott]

Pete,

The simple solution is to write your own report using TReport.

James

[PeterHarmes]

James,

I use a generic xBrowse builder that builds lists based on items from a database (defined by my clients) so the report would have to look at the current state of the browse which it is sort of doing at the moment, so i'd rather get this fixed rather than re-inventing the wheel.

Thanks for the response

Pete

[PeterHarmes]

I've looked at the source code of xBrowse and noticed the following function:

Code: Select all  Expand view

static function MakeRepCol( oRep, oXCol )

   local oCol, bData, cPic //, lTotal := .F.
   local cAlign

   if ( bData := oXCol:bEditValue ) == nil
      bData := oXCol:bStrData
   else
      cPic := oXCol:cEditPicture
   endif

   if bData != nil

      cAlign   := If( oXCol:nDataStrAlign  == AL_RIGHT, "RIGHT", ;
                  If( oXCol:nDataStrAlign  == AL_CENTER, "CENTER", "LEFT" ))

      oCol := RptAddColumn( { { || oXCol:cHeader } }, nil ,;
                            { bData }, nil, { cPic } ,;
                            nil, oXCol:lTotal, nil ,;
                            cAlign, .F., .F., nil )
   endif

return oCol
 

I've noticed that the 4th parameter of RptAddColumn (size) is Null and i think it's defaulting to oXCol:nWidth - so i have modified this 4th param to be oXCol:nWidth / 8 (i used 8 as it is the size of the default font used in the report) and it seems to fit a bit nicer. Is there anyway this could be included in a future release if everyone accepts the change or could someone suggest a way of getting the divisor figure that i have used?

Regards,

Pete

[James Bott]

Pete,

I use a generic xBrowse builder that builds lists based on items from a database (defined by my clients) so the report would have to look at the current state of the browse which it is sort of doing at the moment, so i'd rather get this fixed rather than re-inventing the wheel.

If you mean that they are selecting the data, then you can easily use your own report on the current database by just specifiying the workarea. If you mean that the users are building the configuration of the browse (which columns) then it would be more difficult.

I have not looked at the Report method of XBrowse but column widths are generally setup using the width of a string of capital W's or M's because those are the widest letters. This insures that all strings of the width of the field will fit the column. Of course, it would be extremely rare that any field would contain a string of W's or M's, so the column will almost always be too wide.

One could make the column slightly narrower by multiplying the W width by 0.9 or 0.8 or somesuch but you do then run the risk that some data will be cut off.

Perhaps xBrowse could have such a instance variable that the programmer could adjust. It would default to 1 but then the programmer could adjust this down depending on the level of risk of data cutoff they were willing to risk.

James

[nageswaragunupudi]

The code reproduced above is from much older versions of XBrowse.

XBrowses column object's data nWidth is in pixels. Report class requires data width to be specified in number of characters.

In the recent versions of XBrowse the column object has a new DATA nDataLen and nDataDec ( in addition to the earlier cDataType ).

We can now specify a column with either in pixels by assigning a value to oCol:nWidth or in number of characters by assigning value to oCol:nDataLen.
If we specify oCol:nDataLen ( instead of oCol:nWidth in pixels ), Xbrowse calculates the pixel width for display depending on the font size. In addition, oCol:nDataLen is used to specify the report column width in the Report method.

So, to control the report column widths,
(1) Use picture clause ( Report allocates as much space that is required )
or
(2) Specify oCol:nDataLen instead of oCol:nWidth while defining the xbrowse column.

While defining Xbrowse in command mode, if we specify sizes as negative numbers in COLSIZES clause, they are considered as nDataLen.

Example:

REDEFINE XBROWSE oBrw COLUMNS ..... COLSIZES 80, -12, 100, -15

In this case, 80 and 100 are considered as pixel widths and are assigned to oCol:nWidth and 12 and 15 are considered as widths in number of characters and assigned to oCol:nDataLen

With this feature we can easily control the Report column widths