Page 1 of 2
xBrowse anomoly
Posted: Tue Dec 03, 2019 1:53 am
by TimStone
I have noticed a very specific problem with xBrowse. This may be a new behavior in the latest version
I create a browse ( perhaps with an array ), with headers and columns.
If the first field is String but the content is numbers, it is somehow converting it to a decimal after perhaps 5 characters where it adds a period instead of the next character. It also can truncate the remaining data. I also see the strange truncating and improper sizing on other fields.
Sizing of the fields was not accurate so I then specified the SIZE for each field in the command. Even so the decimal was still in place.
I found it necessary to also add a PICTURE field to get it properly formatted.
Here is an example of a BROWSE that finally worked properly.
Code: Select all
// Display the browse
REDEFINE XBROWSE oLbx2 ;
DATASOURCE oListOrders ;
HEADERS " Order ", " Vendor ", " Date ", " " ;
COLUMNS "ordnum", "ordcom", "orddat", " " ;
SIZES 150, 300, 100 ;
PICTURE "#####", "@!", "99/99/99";
ID 2100 OF oDlt ;
ON DBLCLICK (retval := .t., oDlt:end() ) ;
MESSAGE "Type the beginning of the vendor, highlight the desired order, and Double Click, or select Accept" ;
AUTOSORT UPDATE
oListOrders is a DBF file and each record refers to a different purchase order.
ORDNUM is a Character field of 10 characters
ORDCOM is a Character field of about 30 characters. Without the picture statement, a value like "Advantage Fuel Storage and Delivery" would display as "Adfvan.very"
ORDDAT is a Date field.
I have handled the problem ( but not fixed the flaw that causes it ) but wonder if anyone else has seen similar behaviors. Also, it does not occur with every instance of Xbrowse ...
A SECOND PROBLEM I am seeing, which was corrected previously, occurs with clicking on a row. In these same browses, if I have a list of 10 items, perhaps the last 3 or 4 will not respond to mouse clicks. However, if I use the arrow key to scroll down to them, they highlight fine. Thoughts on this would be appreciated. Again, it is not consistent across all uses of XBrowse.
Tim
Re: xBrowse anomoly
Posted: Tue Dec 03, 2019 1:56 pm
by nageswaragunupudi
We tried to reproduce the problems you mentioned.
I create a browse ( perhaps with an array ), with headers and columns.
But the code you reproduced is for TDatabase object.
So we tested with both Array and TDatabase with the same data.
This is our test program:
Code: Select all
#include "fivewin.ch"
REQUEST DBFCDX
//----------------------------------------------------------------------------//
function Main()
local aData, oDlg, oBrw, oFont
SET CENTURY ON
BrowseArray()
BrowseTDatabase()
return nil
//----------------------------------------------------------------------------//
function BrowseArray()
local aData, oDlg, oBrw, oFont
SET CENTURY ON
aData := ArrayData()
DEFINE FONT oFont NAME "TAHOMA" SIZE 0,-15
DEFINE DIALOG oDlg SIZE 620,350 PIXEL TRUEPIXEL FONT oFont ;
TITLE FWVERSION + " : Browse Array"
@ 20,20 XBROWSE oBrw SIZE -20,-20 PIXEL OF oDlg ;
DATASOURCE aData COLUMNS 1, 2, 3 ;
HEADERS "Order", "Vendor", "Date" ;
AUTOSORT CELL LINES NOBORDER
WITH OBJECT oBrw
:nStretchCol := 2
:CreateFromCode()
END
ACTIVATE DIALOG oDlg CENTERED
RELEASE FONT oFont
return nil
//----------------------------------------------------------------------------//
function BrowseTDatabase()
local oDbf, oDlg, oBrw, oFont
SET CENTURY ON
oDbf := OpenTDatabase()
DEFINE FONT oFont NAME "TAHOMA" SIZE 0,-15
DEFINE DIALOG oDlg SIZE 620,350 PIXEL TRUEPIXEL FONT oFont ;
TITLE FWVERSION + " : Browse TDatabase"
@ 20,20 XBROWSE oBrw SIZE -20,-20 PIXEL OF oDlg ;
DATASOURCE oDbf COLUMNS "ORDNUM", "ORDCOM", "ORDDAT" ;
HEADERS "Order", "Vendor", "Date" ;
AUTOSORT CELL LINES NOBORDER
WITH OBJECT oBrw
:nHeadStrAligns:= AL_CENTER
:nStretchCol := 2
:CreateFromCode()
END
ACTIVATE DIALOG oDlg CENTERED
RELEASE FONT oFont
return nil
//----------------------------------------------------------------------------//
function ArrayData()
local aData := ;
{ { "0123456789", PadR( "Advantage Fuel Storage and Delivery", 35 ), Date() } ;
, { "1234567890", PadR( "Some other text in second line", 35 ), Date()- 1 } ;
, { "2345678901", PadR( "Some other text in third line", 35 ), Date()- 2 } ;
, { "3456789012", PadR( "Some other text in fourth line", 35 ), Date()- 3 } ;
, { "4567890123", PadR( "Some Fuel Storage and Delivery", 35 ), Date()- 4 } ;
, { "5678901234", PadR( "Some other text in sixth line", 35 ), Date()- 5 } ;
, { "6789012345", PadR( "Some other text seventh line", 35 ), Date()- 6 } ;
, { "7890123456", PadR( "Some other text in eighth line", 35 ), Date()- 7 } ;
, { "8901234567", PadR( "Some other text in nineth line", 35 ), Date()- 8 } ;
, { "9012345678", PadR( "Advantage Fuel StorageDelivery", 35 ), Date()- 9 } ;
}
return aData
//----------------------------------------------------------------------------//
function OpenTDatabase()
local aStruct := ;
{ { "ORDNUM", "C", 10, 0 } ;
, { "ORDCOM", "C", 35, 0 } ;
, { "ORDDAT", "D", 8, 0 } ;
}
DBCREATE( "TESTDATA", aStruct, "DBFCDX", .T., "DAT" )
FW_ArrayToDBF( ArrayData() )
FW_CdxCreate()
CLOSE DAT
return TDataBase():Open( nil, "TESTDATA", "DBFCDX", .T. )
//----------------------------------------------------------------------------//
We did not use COLUMNWIDTHS or PICTURES clauses. XBrowse automatically calculated the widths correctly and displayed the data.
We also did not face any problem with mouse clicks on the 9th or 10th row or any row for that matter.
Browse Array:
Browse TDatabase
How can you help us to reproduce the problem?
Re: xBrowse anomoly
Posted: Tue Dec 03, 2019 6:06 pm
by TimStone
Nages,
As I said, it is not consistent. HOWEVER, also note my code uses resources and thus is a REDEFINE. I have never been able to get consistent display with @ x,y positioning on complex dialogs. I wish I could but it just never seems consistent to me, and every effort always seems to get jumbled.
Here is the .RC line for this contol:
CONTROL "",2100,"TxBrowse",WS_BORDER | WS_VSCROLL | WS_TABSTOP,10,10,430,230
Again, I use this same methodology over a hundred times, and it only happens in some instances.
Thanks for looking at it.
Re: xBrowse anomoly
Posted: Tue Dec 03, 2019 8:20 pm
by nageswaragunupudi
HOWEVER, also note my code uses resources and thus is a REDEFINE.
Here is the .RC line for this contol:
CONTROL "",2100,"TxBrowse",WS_BORDER | WS_VSCROLL | WS_TABSTOP,10,10,430,230
Sure, let us test the above sample with resources, using exactly the same definition of the xbrowse.
Code: Select all
#include "fivewin.ch"
REQUEST DBFCDX
//----------------------------------------------------------------------------//
function Main()
local aData, oDlg, oBrw, oFont
SET CENTURY ON
BrowseArray()
BrowseTDatabase()
return nil
//----------------------------------------------------------------------------//
function BrowseArray()
local aData, oDlg, oBrw, oFont
SET CENTURY ON
aData := ArrayData()
DEFINE FONT oFont NAME "TAHOMA" SIZE 0,-15
DEFINE DIALOG oDlg RESOURCE "TEST" FONT oFont ;
TITLE FWVERSION + " : Browse Array"
REDEFINE XBROWSE oBrw ID 2100 OF oDlg ;
DATASOURCE aData COLUMNS 1, 2, 3 ;
HEADERS "Order", "Vendor", "Date" ;
AUTOSORT CELL LINES NOBORDER
WITH OBJECT oBrw
:nStretchCol := 2
END
ACTIVATE DIALOG oDlg CENTERED
RELEASE FONT oFont
return nil
//----------------------------------------------------------------------------//
function BrowseTDatabase()
local oDbf, oDlg, oBrw, oFont
SET CENTURY ON
oDbf := OpenTDatabase()
DEFINE FONT oFont NAME "TAHOMA" SIZE 0,-15
DEFINE DIALOG oDlg RESOURCE "TEST" FONT oFont ;
TITLE FWVERSION + " : Browse TDatabase"
REDEFINE XBROWSE oBrw ID 2100 OF oDlg ;
DATASOURCE oDbf COLUMNS "ORDNUM", "ORDCOM", "ORDDAT" ;
HEADERS "Order", "Vendor", "Date" ;
AUTOSORT CELL LINES NOBORDER
WITH OBJECT oBrw
:nHeadStrAligns:= AL_CENTER
:nStretchCol := 2
END
ACTIVATE DIALOG oDlg CENTERED
RELEASE FONT oFont
return nil
//----------------------------------------------------------------------------//
function ArrayData()
local aData := ;
{ { "0123456789", PadR( "Advantage Fuel Storage and Delivery", 35 ), Date() } ;
, { "1234567890", PadR( "Some other text in second line", 35 ), Date()- 1 } ;
, { "2345678901", PadR( "Some other text in third line", 35 ), Date()- 2 } ;
, { "3456789012", PadR( "Some other text in fourth line", 35 ), Date()- 3 } ;
, { "4567890123", PadR( "Some Fuel Storage and Delivery", 35 ), Date()- 4 } ;
, { "5678901234", PadR( "Some other text in sixth line", 35 ), Date()- 5 } ;
, { "6789012345", PadR( "Some other text seventh line", 35 ), Date()- 6 } ;
, { "7890123456", PadR( "Some other text in eighth line", 35 ), Date()- 7 } ;
, { "8901234567", PadR( "Some other text in nineth line", 35 ), Date()- 8 } ;
, { "9012345678", PadR( "Advantage Fuel StorageDelivery", 35 ), Date()- 9 } ;
}
return aData
//----------------------------------------------------------------------------//
function OpenTDatabase()
local aStruct := ;
{ { "ORDNUM", "C", 10, 0 } ;
, { "ORDCOM", "C", 35, 0 } ;
, { "ORDDAT", "D", 8, 0 } ;
}
DBCREATE( "TESTDATA", aStruct, "DBFCDX", .T., "DAT" )
FW_ArrayToDBF( ArrayData() )
FW_CdxCreate()
CLOSE DAT
return TDataBase():Open( nil, "TESTDATA", "DBFCDX", .T. )
//----------------------------------------------------------------------------//
Resource file:
Code: Select all
TEST DIALOG 6, 15, 450, 257
STYLE DS_MODALFRAME | WS_POPUP | WS_VISIBLE | WS_CAPTION | WS_SYSMENU
CAPTION "TXBrowse demo"
FONT 8, "MS Sans Serif"
{
CONTROL "",2100,"TxBrowse",WS_BORDER | WS_VSCROLL | WS_TABSTOP,10,10,430,230
}
Browse Array:
Browse TDatabase
Creating these xbrowses either from source code or resources can not make such a difference as to produce the kind of behavior mentioned above.
Re: xBrowse anomoly
Posted: Tue Dec 03, 2019 8:42 pm
by nageswaragunupudi
On a thorough testing we can assure that XBrowse, on its own (i.e., without specifying PICTURE clauses) is not capable of producing such kind of results.
However, it is possible if we assign a numeric picture clause to a column containing string values (whether numeric or alpha), due to some oversight or otherwise.
For example, if we add these lines to the above browses.
Code: Select all
SIZES 150, 300, 100 ;
PICTURES "######.","######." ;
this kind of result can appear.
Re: xBrowse anomoly
Posted: Thu Apr 16, 2020 12:02 am
by TimStone
I realize your small tests don't show it, but the problem continued and my clients were getting very upset.
The behavior IS in xBrowse.prg ... Sometimes it is intepreting a Character data field as Numeric and applying a default picture to the column. The data is fine, and clearly type C.
To correct the problem, where it pops up, I have to add a PICTURE clause to the browse. To save space I'm using "@!" which may annoy some with all characers capitalized, but it is far better than having the field displayed as 7 characters, and then a decimal point, with no trailing data.
I've spent days testing to see if I can find any other cause. There is none. I should note that if the data row is shown on the browse, and the same data displayed in a field on the same screen, the GET field shows the full data, correctly. The browse shows the abbreviated data. For example:
GET. Johnny Mustang home
BROWSE. Johnny .
Maybe someone can find the source of this issue. The databases are DBF, the display is by default in xbrowse, the build is with Harbor and MSVC 2019.
Tim
Re: xBrowse anomoly
Posted: Thu Apr 16, 2020 7:38 am
by MOISES
There is also a problem with the latest version. When the last numerical column does not fit, it is not painted, even partially:
https://ibb.co/84wDQcT
But if you move the scroll, it is painted as you move:
https://ibb.co/YNgqyF3
Thank you.
I am using FW 20.02-
Re: xBrowse anomoly
Posted: Wed Apr 22, 2020 5:53 pm
by TimStone
I'm still hoping for an answer on this.
Re: xBrowse anomoly
Posted: Wed Apr 22, 2020 9:51 pm
by Silvio.Falconi
TimStone wrote:Maybe someone can find the source of this issue. The databases are DBF, the display is by default in xbrowse, the build is with Harbor and MSVC 2019.
Tim
wich release have of xbrowse ? because here the Nages sample test run ok
Per haps a good Idea use part of your dbf to see the real problem
I say you also from your rel. of fwh to our there are over 6 modifications of xbrowse ( I saw on what new file )
Re: xBrowse anomoly
Posted: Thu Apr 23, 2020 5:27 pm
by TimStone
Silvio,
I am on the most recent version of FWH. ( 12.02 ). I use the most recent version of Microsoft Community ( 2019 updated last week ).
I have seen all of the examples. The problem with them is they use specific data that does not always reflect what is stored in an actual, real world, database. So of course they work with perfect records. The question then becomes, what exactly does the xBrowse read to determine the default picture clause ? First record in the database ? First record in an indexed database ? Last record ? Something else ?
Is the problem with xBrowse ? Since using a PICTURE clase when building the xBrowse command eliminates the problem, and it only occurs with the DEFAULT values automatically assigned by the xBrowse ( when no PICTURE is specified ) it would seem reasonable to say the error is caused by code in the xBrowse.prg itself.
Tim
Re: xBrowse anomoly
Posted: Tue Apr 28, 2020 7:26 pm
by TimStone
As noted, this problem occurs in various implementations of an xBrowse.
I have asked, but received no replly, HOW ARE THE DEFAULT PICTURES DETERMINED.
One can test with perfect data but customers may not always enter perfectly configured records.
Clearly, the problem only occurs when xBrowse sets a default picture. Adding a Picture to the command line eliminates the problem. However, the only picture I can use for text that is simple is "@!" which forces everything to capitals and I don't like to do that.
So, if you could PLEASE explain this request that has been pending since the end of 2019 I would appreciate so I can try and track down the problem. My clients are not happy ...
Re: xBrowse anomoly
Posted: Wed Apr 29, 2020 8:27 am
by nageswaragunupudi
XBrowse provides default picture (oCol:cEditPicture) for columns with numeric values only and never for columns with character values. This is how it works.
When XBrowse is created with this syntax:
Code: Select all
... XBROWSE .. DATASOURCE cAlias/oDatabase/oQry/oRecordSet/oRowSet ;
COLUMNS "cCol1", "cCol2", ... "cColN" ; // or AUTOCOLS
...
By indicating the DATASOURCE in the command, we inform the XBrowse the source of data in advance before configuring the columns. This greatly helps xbrowse.
When COLUMNS clause is used, xbrowse xbrowse knows which column is based on which field. XBrowse first reads the field structure of the datasource and then assigns oCol:cDataType, oCol:nDataLen, oCol:nDataDec on the basis of the corresponding field definition. Then, for numeric fields, (only numeric fields), assigns oCol:cEditPicture on the basis of nDataLen, nDataDec and the settings of FWNumFormat().
There is no question of assigning any oCol:cEditPicture to any character field.
In the case of TDatabase and MariaRowSet, the picture clauses are decided even at the time of creation of the class.
When XBrowse is created without COLUMNS clause:
The columns are created separately either with ADD TO oBrw command or with oBrw:AddCol().
In this case, xbrowse can not map the columns to any field of the database. So, xbrowse on its own can not assign any pictures for any column.
So, it is very unlikely that xbrowse by default assigns a numeric picture clause to a column with character value.
Re: xBrowse anomoly
Posted: Wed Apr 29, 2020 3:32 pm
by James Bott
Tim,
However, the only picture I can use for text that is simple is "@!" which forces everything to capitals and I don't like to do that.
Have you tried "@A"? This only allows characters of upper or lower case, and no symbols.
James
Re: xBrowse anomoly
Posted: Wed Apr 29, 2020 10:22 pm
by TimStone
James,
I wish ... but sometimes they assign symbols ... not appropriate but they insist.
Re: xBrowse anomoly
Posted: Wed Apr 29, 2020 10:26 pm
by TimStone
Nages,
I use the COLUMN to define my browses. You will see that in the original example.
I use data objects ( tDatabase ) so where would I look in there to see how it might be assigning the field type ? ( N instead of C ).
This ALWAYS happens by taking a Character field and treating it like a Numeric even though the field doesn't have numbers. Also, it happens across different data files, and different column positions,