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

tiaofw
Posts: 97
Joined: Fri Dec 12, 2008 4:39 pm
Location: Brasil
Contact:

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

Post 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.
Last edited by tiaofw on Mon Feb 29, 2016 3:15 pm, edited 1 time in total.
Contagem/Brazil
FWH/xharbour 15.12/PELLES C, MED, DBF
tiaofw
Posts: 97
Joined: Fri Dec 12, 2008 4:39 pm
Location: Brasil
Contact:

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

Post by tiaofw »

up!
Contagem/Brazil
FWH/xharbour 15.12/PELLES C, MED, DBF
User avatar
Antonio Linares
Site Admin
Posts: 37481
Joined: Thu Oct 06, 2005 5:47 pm
Location: Spain
Contact:

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

Post by Antonio Linares »

What is the problem ?
regards, saludos

Antonio Linares
www.fivetechsoft.com
User avatar
TimStone
Posts: 2536
Joined: Fri Oct 07, 2005 1:45 pm
Location: Trabuco Canyon, CA USA
Contact:

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

Post 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
Tim Stone
http://www.MasterLinkSoftware.com
timstone@masterlinksoftware.com
Using: FWH 19.06 with Harbour 3.2.0 / Microsoft Visual Studio Community 2019
tiaofw
Posts: 97
Joined: Fri Dec 12, 2008 4:39 pm
Location: Brasil
Contact:

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

Post 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.
Contagem/Brazil
FWH/xharbour 15.12/PELLES C, MED, DBF
User avatar
TimStone
Posts: 2536
Joined: Fri Oct 07, 2005 1:45 pm
Location: Trabuco Canyon, CA USA
Contact:

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

Post 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
Tim Stone
http://www.MasterLinkSoftware.com
timstone@masterlinksoftware.com
Using: FWH 19.06 with Harbour 3.2.0 / Microsoft Visual Studio Community 2019
tiaofw
Posts: 97
Joined: Fri Dec 12, 2008 4:39 pm
Location: Brasil
Contact:

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

Post 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.
Contagem/Brazil
FWH/xharbour 15.12/PELLES C, MED, DBF
tiaofw
Posts: 97
Joined: Fri Dec 12, 2008 4:39 pm
Location: Brasil
Contact:

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

Post 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.
Contagem/Brazil
FWH/xharbour 15.12/PELLES C, MED, DBF
tiaofw
Posts: 97
Joined: Fri Dec 12, 2008 4:39 pm
Location: Brasil
Contact:

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

Post 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.
Contagem/Brazil
FWH/xharbour 15.12/PELLES C, MED, DBF
User avatar
Antonio Linares
Site Admin
Posts: 37481
Joined: Thu Oct 06, 2005 5:47 pm
Location: Spain
Contact:

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

Post by Antonio Linares »

Have you tried to change the width of the column ?

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

Antonio Linares
www.fivetechsoft.com
tiaofw
Posts: 97
Joined: Fri Dec 12, 2008 4:39 pm
Location: Brasil
Contact:

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

Post 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.
Contagem/Brazil
FWH/xharbour 15.12/PELLES C, MED, DBF
User avatar
Antonio Linares
Site Admin
Posts: 37481
Joined: Thu Oct 06, 2005 5:47 pm
Location: Spain
Contact:

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

Post 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.
regards, saludos

Antonio Linares
www.fivetechsoft.com
tiaofw
Posts: 97
Joined: Fri Dec 12, 2008 4:39 pm
Location: Brasil
Contact:

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

Post by tiaofw »

Ok.

Thank you!
Contagem/Brazil
FWH/xharbour 15.12/PELLES C, MED, DBF
User avatar
nageswaragunupudi
Posts: 8017
Joined: Sun Nov 19, 2006 5:22 am
Location: India
Contact:

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

Post 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.
Regards

G. N. Rao.
Hyderabad, India
User avatar
nageswaragunupudi
Posts: 8017
Joined: Sun Nov 19, 2006 5:22 am
Location: India
Contact:

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

Post 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.
Regards

G. N. Rao.
Hyderabad, India
Post Reply