Listbox Headings Win32 Style

dpaterso
Posts: 142
Joined: Tue Jan 24, 2006 9:45 am
Location: South Africa
Contact:

Post by dpaterso »

Ok, Ok, I get it. I like surprises. You're not going to respond to this message thread so that you can surprise us all with the next build? Right?

I can just see it now in 'Whats New?'

It should go something like this:

* Enhancement: TWBROWSE and TLISTBOX now fully XP Theme Aware.

Right?

:) :) :)

Thanks.

Dale.
User avatar
James Bott
Posts: 4654
Joined: Fri Nov 18, 2005 4:52 pm
Location: San Diego, California, USA
Contact:

Post by James Bott »

Dale,

Some of the items you mentioned you can do now. These features have been available for as long as I can remember.

4 - The option to choose whether or not you want lines displayed between each record or field (although this is not critical in my opinion).

To turn off lines:

oLbx:nLineStyle:= 0

#define LINES_NONE 0
#define LINES_BLACK 1
#define LINES_GRAY 2 // inactive caption color
#define LINES_3D 3
#define LINES_DOTED 4 // black, vertical solid, horz dotted

New in ver 2.1
- 5: Only vertical black lines
- 6: Only vertical gray lines
- 7: Only horizontal black lines
- 8: Only horizontal gray lines


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.

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. The browse has to know how many total records are in the browse to display the scrollbar properly. First you have to build all your indexes for the 'FOR ! DELETED()" clause. 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). 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). Perhaps these are the types of problems you are having?

To color the focused line use these:

oLbx:nClrForeFocus := CLR_BLACK
oLbx:nClrBackFocus := rgb(222,227,231)

Use a paint program to find the RGB colors you want.

OK, I hope those answer a number of your questions.

James
User avatar
Enrico Maria Giordano
Posts: 7355
Joined: Thu Oct 06, 2005 8:17 pm
Location: Roma - Italia
Contact:

Post by Enrico Maria Giordano »

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).
If I remember correctly, now NTXs and CDXs are very similar and have the same functions (OrdKeyCount() included).
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'm not wrong, OrdKeyCount() respect scopes and filters.

EMG
User avatar
James Bott
Posts: 4654
Joined: Fri Nov 18, 2005 4:52 pm
Location: San Diego, California, USA
Contact:

Post by James Bott »

Enrico,
If I remember correctly, now NTXs and CDXs are very similar and have the same functions (OrdKeyCount() included).
Good to know. I assume you mean with (x)Harbour?
If I'm not wrong, OrdKeyCount() respect scopes and filters.
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?

James
User avatar
Enrico Maria Giordano
Posts: 7355
Joined: Thu Oct 06, 2005 8:17 pm
Location: Roma - Italia
Contact:

Post by Enrico Maria Giordano »

James Bott wrote:Good to know. I assume you mean with (x)Harbour?
Yes, both Harbour and xHarbour (they share the same RDDs).
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?
This is a working sample:

Code: Select all

REQUEST DBFCDX


FUNCTION MAIN()

    RDDSETDEFAULT( "DBFCDX" )

    USE TEST INDEX TEST

    SET FILTER TO FIELD -> last = "A"

    ? ORDKEYCOUNT()

    CLOSE

    INKEY( 0 )

    RETURN NIL
EMG
User avatar
James Bott
Posts: 4654
Joined: Fri Nov 18, 2005 4:52 pm
Location: San Diego, California, USA
Contact:

Post by James Bott »

Enrico,
Yes, both Harbour and xHarbour (they share the same RDDs).
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.

Regarding your filter example, isn't it just counting the records by reading the entire file?

James
User avatar
James Bott
Posts: 4654
Joined: Fri Nov 18, 2005 4:52 pm
Location: San Diego, California, USA
Contact:

Post by James Bott »

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
dpaterso
Posts: 142
Joined: Tue Jan 24, 2006 9:45 am
Location: South Africa
Contact:

Post by dpaterso »

Good Morning, and thanks to both of YOU for the replies.
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.
This needs to be sorted out.

Detlef Hofner very kindly modified WBROWSE.PRG for me about a year ago so that I could pass a parameter oLbx:nLineHeight := nValue and this did work for a time for the most part but it could not space the heading text correctly as apparantely the heading text is drawn by WBRWLINE.C (the heading text would just move down and not center between the horizontal lines of the heading. Changing the font also caused problems when calculating the correct spacing between the horizontal lines of the browse).

I did try and make sense of the changes that he made and attempted to implement these changes into subsequent releases of WBROWSE.PRG but eventually the files became too different and again, for someone with my limited knowledge of the internal workings of FWH, making these changes to the FWH source became more time consuming than I could afford and I was always nervous that I would be messing with some or the other new function or fix that was part of a newer release of WBROWSE.PRG.

For this reason I really think that these changes need to be incorporated as standard BY THE DEVELOPER.
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.
Really needs to be implemented BY THE DEVELOPER.
3 - Correct operation of the vertical scroll bar (been on about this for just as long).
The main problems are as follows:

When adding a new record I have to do some fancy footwork to ensure that the vertical scroll bar stays in synch with the database. The only way that I can do this is by including the following code immediately after adding my new record:

oLbx:GoBottom( )
oLbx:GoTop( )
DBSeek( Key Of Newly Added Record )
oLbx:VSetPos( OrdKeyNo( ) )
oLbx:Refresh( )

Just try to add a record without this code and see what happens. The new record is added and displayed and the vertical scroll bar appears to be in synch but immediately press the Up Arrow key after adding the new record and the scroll bar indicator (I forget what the little block is called) jumps right to the top of the scrollbar and from then on is out of synch with the database until you press End, Ctrl Page Down or Up, Home, etc. etc. which seems to resynch it.

My workaround code (above) results in much jumping around of the scroll bar after adding a new record and this just looks silly and results in every new user that uses something of mine saying 'what happened there when I clicked OK'!

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.

Another even simpler problem to replicate is to open a browse, press End or Control End (puts you at the last record) and then press Down Arrow. Now move up with the Up Arrow key or Mouse and you will find that now your scrollbar is one record behind the database and remains so until you press End, Control End, etc. etc. The same applies when using the opposites of Home, Control Home, etc. etc.
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.

Sorry - I know that I appear to be coming down really hard on this but the ability to be able to browse databases correclty really is not a 'nice to have' but rather a necessity.
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.
It has been noticed on more than one occasion believe it or not.

I am going to try experimenting with the line styles so maybe this is not an issue.

Regards,

Dale.
User avatar
James Bott
Posts: 4654
Joined: Fri Nov 18, 2005 4:52 pm
Location: San Diego, California, USA
Contact:

Post by James Bott »

Dale,
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.
Well, if were easy, then we wouldn't have jobs. We programmers have to make decsions that cannot be blindly turned over to code. If you are browsing a million record file then put a filter on it, do you want the browse to make the decision to bring everthing to a halt while it drags a million records across the network to count the total number of records in the filter? Without the total, then the scrollbar can't figure out where to put the thumbbar. There is no other way, except maybe magic.

If you exclude deleted records from your indexes and avoid filters, then the scrollbars should work properly.

I will take a look at the behavior problem you descibed when adding a record. I have not noticed it before.

James
User avatar
Enrico Maria Giordano
Posts: 7355
Joined: Thu Oct 06, 2005 8:17 pm
Location: Roma - Italia
Contact:

Post by Enrico Maria Giordano »

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.
Yes, it was the unvaluable work made by Przemek.

EMG
User avatar
Enrico Maria Giordano
Posts: 7355
Joined: Thu Oct 06, 2005 8:17 pm
Location: Roma - Italia
Contact:

Post by Enrico Maria Giordano »

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
Can you send me your 500,000 record DBF to make some test here?

EMG
User avatar
Enrico Maria Giordano
Posts: 7355
Joined: Thu Oct 06, 2005 8:17 pm
Location: Roma - Italia
Contact:

Post by Enrico Maria Giordano »

EnricoMaria wrote:Can you send me your 500,000 record DBF to make some test here?
Thank you for the utility, James. I make some experiment and you are right, OrdKeyCount() is slow with filters. But we always knew that filters couldn't be used with browses. :-)

EMG
User avatar
James Bott
Posts: 4654
Joined: Fri Nov 18, 2005 4:52 pm
Location: San Diego, California, USA
Contact:

Post by James Bott »

Dale
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.
This is not as simple as it seems. Presumably your browse will be indexed and thus any new record will very likely not belong right where the highlight bar is. So the entire browse has to be redisplayed with the newly added record in it somewhere. When you move the database record pointer behiind the browse, the browse just repaints the screen starting at the current record, thus the newly added record is at the top.

The alternative would be to calculate which record to put at the top so the new record would appear right were the highlight bar already is, but then the entire set of records is going to change anyhow and I would think this would be just as disconcerting to the user.

James
dpaterso
Posts: 142
Joined: Tue Jan 24, 2006 9:45 am
Location: South Africa
Contact:

Post by dpaterso »

That is why you are the master!!!

You are right. If the database being viewed with the browse is indexed the records would change anyway BUT is it not possible to have the records to change but the highlight bar to stay in its current position until the user moves it? It becomes disconcerting when the record highlight bar is half way down the screen lets say, you add a new record, and because of my long winded code to keep the scroll bar in synch the listbox gets repainted (what appears to be multiple times) and the record highlight bar (scroll bar jumps) to the first line of the browse (although the scroll bar is in synch).

Just as a matter of interest I do not seem to have problems with deleted records funny enough. By that I mean that in most of my browses I actually check for the delete key i.e. if pressed the current record is deleted() and redisplayed in red and if already deleted() it is recalled and redisplayed in black again. This works perfectly and is not the reason that everything else gets blown apart.

I did try your line types and they work perfectly (sorry for not checking before posting).

Look - I suppose that there are some things that I have to live with - I think that maybe just the Win32 Headers, XP Themed i.e. square blue border around browse (like Gets), and setting of line height would suffice.

Regards,

Dale.
Post Reply