TxBrowse() - Vertical scrollbar with filtered data

[Davide]

Hello all,

I've noticed that in the vertical scrollbar the arrows are working ok, while by directly moving the square, sometimes filtered data reappears in the browse (sometimes even deleted records)

oBrw:KeyCount() returns a number including also the filtered records.
Maybe I should specify a scope for the browse instead of using SET FILTER TO externally ? - If so, how ?

TIA
Davide
FWH 27-3 - xH 0.99.60

Code: Select all

// Database already opened, SET DELETED ON, filtered data with SET FILTER

   oBrw := TXBrowse():New( oWnd )

   oBrw:nMarqueeStyle       := MARQSTYLE_HIGHLROW
   oBrw:nColDividerStyle    := LINESTYLE_BLACK
   oBrw:nRowDividerStyle    := LINESTYLE_BLACK

   oBrw:SetRDD()

   For i:=1 to 3
     oBrw:aCols[ i ]:blDClickData := {|r,c,f,o| MyFunc(.f.) }
   Next i

   oBrw:lVScroll:=.f.    // workaround

   oBrw:CreateFromCode()
   oWnd:oClient := oBrw

[R.F.]

I dont use xBrowse, but in the other browses, all of them have a DATA called bLogicLen which is used to draw the thumb position in the vertical scroll bar.

the data is normally asigned to a codebloc containing {|| lastrec()} so in order to get the correct placement of the thumb you must asign this data to a value that reflects the real size of the databas, for example to the OrdKeyCount() function

[Davide]

Dear Rene,

thank you for your reply.

I dont use xBrowse, but in the other browses, all of them have a DATA called bLogicLen which is used to draw the thumb position in the vertical scroll bar.

Yes, it's called bKeyNo in xBrowse.
Anyway, the thumb is drawn correctly, and the browse normally works correctly.
It's only if I MOVE the thumb myself that I start seeing strange things in the browse.
As KeyCount() returns a number including also the filtered and deleted records I though that perhaps I should have assigned a "filter data" codeblock to the browse itself somehow.
Any idea ?
Thanks,
Davide.

[James Bott]

Davide,

If you are using an index you should build the index with the FOR ! DELETED() clause. I build all my indexes like that. This way deleted recrods will not be included in ordKeyCount().

Filters are another matter. When an index is built using the above clause it, of course, has to read the entire database. If you set a filter at runtime, there is no way to know how many records are going to be in the filter without reading the entire database. So, there is no way to get a proper count for use by the thumbbar.

The only other soultion is to use indexes (with the FOR ! DELETED() clause) and to set a scope. This way ordKeyCount() knows the number of records in the scope without rereading the entire database.

James

[Davide]

James,

thank you for your reply.

The only other soultion is to use indexes (with the FOR ! DELETED() clause) and to set a scope. This way ordKeyCount() knows the number of records in the scope without rereading the entire database.

That DBF contains only a few records and does not have any index.
I'm not sure I've correctly understood the "scope" part of your reply.
How could I apply such scope to my DBF/xBrowse ?

TIA,
Davide

[James Bott]

Davide,

>That DBF contains only a few records and does not have any index.

If that is the case it is possible and feasible to count all the records in the filter and change bKeyCount to return the total.

>I'm not sure I've correctly understood the "scope" part of your reply.
How could I apply such scope to my DBF/xBrowse ?

You use an index to create the scope of the view of records. For example you could index on CUSTNO and then set the scope to only view one CUSTNO.

Code: Select all

index on custno to custno for ! deleted()

   ordScope(0, cCustno) // set the bottom scope
   ordScope(1, cCustno) // set the top scope

james

[Davide]

James,

If that is the case it is possible and feasible to count all the records in the filter and change bKeyCount to return the total.

this cured the problem.
Thank you,
Davide