Page 1 of 2

FWH 15:12: Bug in the size of the column in xbrowse RESOLVED

Posted: Tue Feb 02, 2016 1:26 pm
by tiaofw
Good day,

I found that to update the version of FWH 2.15 to 15:12 the following anomaly occurred in xbrowse column, see:

Xbrowse 15.02:

Image


Xbrowse 15.12:

Image



I suppose the error is motivated by the fact that the column be blank.

This is the code:

Code: Select all


dlg_font := ;
        if(upper(substr(getsysdir(), 12, 8)) == "SYSTEM32", ;
        "Arial Negrito", 'Arial Negrito'), dlg_fonttam := ;
        if(upper(substr(getsysdir(), 12, 8)) == "SYSTEM32",  ;
        if(cResTela == 1024 .or. cResTela >= 1024, -14, -12), ;
        if(cResTela == 1024 .or. cResTela >= 1024, -12, -12))


   DEFINE FONT oFont1_F2 NAME dlg_font SIZE 0, -24


   redefine XBROWSE olbx_f2 fields &campo01,&campo02,&campo03,&campo04,&campo05,&campo06,&campo07,&campo08,&campo09,&campo10;
   headers titulo[1],titulo[2],titulo[3],titulo[4],titulo[5],titulo[6],titulo[7],titulo[8],titulo[9], titulo[10] update ;
   id 101 of ODLG_F2 AUTOSORT CELL LINES NOBORDER ;
   on dblclick f2_okdbl(@nqualcampo,@xvar, npesq)

olbx_f2:SetFont( oFont1_F2 )
olbx_f2:nMarqueeStyle       := MARQSTYLE_HIGHLCELL
olbx_f2:nColDividerStyle    := LINESTYLE_BLACK
olbx_f2:nRowDividerStyle    := LINESTYLE_BLACK
olbx_f2:lColDividerComplete := .t.
olbx_f2:lAllowRowSizing := .f.
olbx_f2:lHScroll := .t.
olbx_f2:lVScroll := .t.
olbx_f2:nHeaderLines := nLinTit
olbx_f2:cAlias := alias()
olbx_f2:ajustify := justif
olbx_f2:nStretchCol := STRETCHCOL_LAST
olbx_f2:lAdjusted := .t.


 
Any solution?

Thanks.

Re: FWH 15:12: Bug in the size of the column in xbrowse

Posted: Tue Feb 09, 2016 4:19 pm
by tiaofw
up!

Re: FWH 15:12: Bug in the size of the column in xbrowse

Posted: Tue Feb 09, 2016 9:20 pm
by Antonio Linares
What is the problem ?

Re: FWH 15:12: Bug in the size of the column in xbrowse

Posted: Tue Feb 09, 2016 9:32 pm
by TimStone
I posted a problem with column size in recent versions of xbrowse. I was told to use a different COMMAND syntax for calling a browse, and then it worked. However, in a very large program that meant re-writing the syntax for the browse about 200 times.

I was using the ADD COLUMN syntax. The alternative is to set the SIZE for each column when calling it.

I believe the problem arose in 15.12 and continued into the latest releases.

Tim

Re: FWH 15:12: Bug in the size of the column in xbrowse

Posted: Wed Feb 10, 2016 11:32 am
by tiaofw
Good morning everyone.

The problem is that in version 15.2 the size of the highlighted column not truncated the title of the column, and version 15:12 the size of the column did not obey the File field size, see the title of the highlighted column.

I suppose that the problem was caused by the fact that all records of the field in question is blank, as in other fields whose contents filled this has not happened.

OK?

Thank you.

Re: FWH 15:12: Bug in the size of the column in xbrowse

Posted: Wed Feb 10, 2016 7:16 pm
by TimStone
I don't think empty fields is the issue. The column size should be calculated by the structure of the database ( width ) or the header value, whichever is greater.

In my case, we found that either the first or last column would take up about 75% of the width of the browse, and the remaining columns would all be displayed compressed to equal sizes. I don't have a screen shot to show you, but essentially it was unuseable. I had not changed the command lines in many years, and I used the structure:

REDEFINE xBrow ID 123 OF oWnd
ADD TO xBrow DATA ....
ADD TO xBrow DATA ...
ADD TO xBrow DATA ....

This is documented format, but this method had the problem of displaying the columns incorrectly. We did discover if someone could grab one of the vertical column lines and pull it towards the oversized column, then the control would recalculate and display correctly. However, our clients were not willing to accept that behavior.

There were two solutions. On the ADD TO lines, use SIZE and specify the column width. The other was to use the "preferred format" that is not in the documentation:

REDEFINE XBROWSE xBrow ID 123 OF oWnd ;
DATASOURCE oDbf ;
COLUMNS "invnum", "invdes", "invchg" ;
HEADERS "Part", "Description", "Charge" UPDATE

This is what I did to over 200 controls in the coming version. I patched the existing release a bit.

Finally, although where the problem occurs is consistent, it did not occur on all browse controls. I can't tell you what made the difference. I just know it has worked perfectly, as written, for many years on all of the versions of FWH prior to 15.12.

Tim

Re: FWH 15:12: Bug in the size of the column in xbrowse

Posted: Thu Feb 11, 2016 12:29 pm
by tiaofw
Good Morning Tim.

I also think that the issue is in the way FiveWin calculates the size of the column, I can not say what influence

What I can say with certainty is that I have not changed the code.

The interesting thing is that the problem occurs in only one column, the other is correct.

At 15:02 FWH was correct and not 15:12.

Thanks.

Re: FWH 15:12: Bug in the size of the column in xbrowse

Posted: Thu Feb 11, 2016 2:00 pm
by tiaofw
Tim.

When I change the FIELDS clause to the COLUMNS xbrowse does not conform to the number of defined fields and reads all fields of DBF.

Thanks.

Re: FWH 15:12: Bug in the size of the column in xbrowse

Posted: Thu Feb 11, 2016 2:35 pm
by tiaofw
Tim, Antonio.

Was I imagined.

The xbrowse uses the contents of the first record to calculate the size of the column.

See the image below using xbrowse in FWH 15:12 and the first completed registration.

Image


Thus the column size is correct.

But if content is empty column is truncated.

Thank you.

Re: FWH 15:12: Bug in the size of the column in xbrowse

Posted: Thu Feb 11, 2016 9:16 pm
by Antonio Linares
Have you tried to change the width of the column ?

oBrw:aCols[ ... ]:nWidth := GetTextWidth( 0, "textwithdesiredwidth", oBrw:hFont )

Re: FWH 15:12: Bug in the size of the column in xbrowse

Posted: Fri Feb 12, 2016 12:59 pm
by tiaofw
Good morning Antonio.

The point is that in the version 15:02 I do not need to manually adjust the size of the column, the FWH did it automatically.

15:12 but in the initial record is blank he can not correctly calculate the column width. But could 15:02.

I would have no way to fix?

Thank you.

Re: FWH 15:12: Bug in the size of the column in xbrowse

Posted: Fri Feb 12, 2016 5:24 pm
by Antonio Linares
There are many changes since version 15.02 so we need some time to locate it and fix it.

In the meantime, you could modify the width as a workaround.

Re: FWH 15:12: Bug in the size of the column in xbrowse

Posted: Fri Feb 12, 2016 6:15 pm
by tiaofw
Ok.

Thank you!

Re: FWH 15:12: Bug in the size of the column in xbrowse

Posted: Sat Feb 27, 2016 8:29 am
by nageswaragunupudi
tiaofw wrote:Good morning Antonio.

The point is that in the version 15:02 I do not need to manually adjust the size of the column, the FWH did it automatically.

15:12 but in the initial record is blank he can not correctly calculate the column width. But could 15:02.

I would have no way to fix?

Thank you.
We regret the mistake. This escaped our tests and our own running applications because we tested with the usual COLUMNS clause and in that case there is no change. This affected browses with FIELDS clause and ADD TO oBrw clause without specifying column sizes.

Please apply this fix in xbrowse.prg
Please locate the code (Line no: 10206 in ver 15.12 or Line no: 10186 in ver 16.01) in method DataWidth()

Code: Select all

              nWidth   := CalcTextWH( ::oBrw, cText, oFont )[ 1 ]
 
Please replace this code with

Code: Select all

              nWidth   := ::oBrw:GetWidth( Replicate( 'B', Len( cText ) ), oFont )
 

With this fix all width calculations should match previous versions.

Re: FWH 15:12: Bug in the size of the column in xbrowse

Posted: Sun Feb 28, 2016 2:02 pm
by nageswaragunupudi
The problem is that in version 15.2 the size of the highlighted column not truncated the title of the column, and version 15:12 the size of the column did not obey the File field size, see the title of the highlighted column.
This problem also is fixed in 16.02.