James Bott wrote:The problem cannot be fixed for conditional indexes if you are using NTXs, because there is no way to get the total number of records in the index (you can get this with CDXs).
James Bott wrote:The problem cannot be fixed when using filters (unless perhaps you made a full pass through the data to do a count before displaying the browse).
If I remember correctly, now NTXs and CDXs are very similar and have the same functions (OrdKeyCount() included).
If I'm not wrong, OrdKeyCount() respect scopes and filters.
James Bott wrote:Good to know. I assume you mean with (x)Harbour?
James Bott wrote:Scopes, yes, but with filters I don't know how it could. Do you mean conditional indexes? I did state that those would work. But with SET FILTER there is no way to get a record count without reading the entire file. Am I wrong?
REQUEST DBFCDX
FUNCTION MAIN()
RDDSETDEFAULT( "DBFCDX" )
USE TEST INDEX TEST
SET FILTER TO FIELD -> last = "A"
? ORDKEYCOUNT()
CLOSE
INKEY( 0 )
RETURN NIL
Yes, both Harbour and xHarbour (they share the same RDDs).
1 - The ability to set the height of the rows and headings and the text of the headings to be spaced correctly in proportion to the chosen Line Height and chosen Font for the browse.
2 - The headings to appear the same as any other XP application that has a data browse (like MS Outlook for example) i.e. underlined when mouse is moved over them just like FiveWin Win32 Headers.
3 - Correct operation of the vertical scroll bar (been on about this for just as long).
The only problems with this, that I am aware of, have to do with indexes filters, scopes, and deleted records.
5 - Correct alignment of the vertical lines between fields in relation to their headings (the vertical lines have always been slightly offset to the right since FiveWin 2.2 and does not look very nice).
Actually, this is a optical illusion. If you do a screen capture and enlarge it you will see that the line is right between the columns. The problem is that there is a black shadow drawn on the left and bottom sides of the previous column header (to make it 3d). The vertical black line on the previous header makes it seem that the vertical line between the columns is in the wrong place. However, I never even noticed this until you mentioned it, so I doubt many of your users have.
The only problems with this, that I am aware of, have to do with indexes filters, scopes, and deleted records.
If we have to be constantly aware these conditions and have to constantly make allowances for them when displaying a basic browse of our data then we have problems.
The fact of the matter is that when I display my data using a browse it should display it any way I want it and in order that I want it and the scrollbar should be in synch with the database at any given time.
James Bott wrote:I understand. What I meant was that this must be something new under the Harbour/xHarbour NTX RDD. It was not available under the Clipper NTX RDD.
James Bott wrote:Enrico,
I just did a small test. With a 500,000 record file it took the same amount of time for ordkeycount() and COUNT TO X. So, it seems both are reading the entire file to get the total.
James
EnricoMaria wrote:Can you send me your 500,000 record DBF to make some test here?
Using my workaround (above) a newly added record is always displayed as the first record at the top of the browse (after all the movement has taken place although this ensures that the scroll bar is back in synch with the database). Your new record should be displayed at the current position of the scroll bar highlight bar i.e. sort of inserted at the current position of the scroll bar highlight.
Return to FiveWin for Harbour/xHarbour
Users browsing this forum: Antonio Linares, Google [Bot] and 62 guests