Listbox Headings Win32 Style
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.
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.
- Enrico Maria Giordano
- Posts: 7355
- Joined: Thu Oct 06, 2005 8:17 pm
- Location: Roma - Italia
- Contact:
- James Bott
- Posts: 4654
- Joined: Fri Nov 18, 2005 4:52 pm
- Location: San Diego, California, USA
- Contact:
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
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
- Enrico Maria Giordano
- Posts: 7355
- Joined: Thu Oct 06, 2005 8:17 pm
- Location: Roma - Italia
- Contact:
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 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'm not wrong, OrdKeyCount() respect scopes and filters.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).
EMG
- James Bott
- Posts: 4654
- Joined: Fri Nov 18, 2005 4:52 pm
- Location: San Diego, California, USA
- Contact:
Enrico,
James
Good to know. I assume you mean with (x)Harbour?If I remember correctly, now NTXs and CDXs are very similar and have the same functions (OrdKeyCount() included).
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?If I'm not wrong, OrdKeyCount() respect scopes and filters.
James
- Enrico Maria Giordano
- Posts: 7355
- Joined: Thu Oct 06, 2005 8:17 pm
- Location: Roma - Italia
- Contact:
Yes, both Harbour and xHarbour (they share the same RDDs).James Bott wrote:Good to know. I assume you mean with (x)Harbour?
This is a working sample: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?
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
- James Bott
- Posts: 4654
- Joined: Fri Nov 18, 2005 4:52 pm
- Location: San Diego, California, USA
- Contact:
Enrico,
Regarding your filter example, isn't it just counting the records by reading the entire file?
James
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, both Harbour and xHarbour (they share the same RDDs).
Regarding your filter example, isn't it just counting the records by reading the entire file?
James
- James Bott
- Posts: 4654
- Joined: Fri Nov 18, 2005 4:52 pm
- Location: San Diego, California, USA
- Contact:
Good Morning, and thanks to both of YOU for the replies.
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.
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 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.
I am going to try experimenting with the line styles so maybe this is not an issue.
Regards,
Dale.
This needs to be sorted out.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.
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.
Really needs to be implemented 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.
The main problems are as follows:3 - Correct operation of the vertical scroll bar (been on about this for just as long).
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.
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 only problems with this, that I am aware of, have to do with indexes filters, scopes, and deleted records.
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.
It has been noticed on more than one occasion believe it or not.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.
I am going to try experimenting with the line styles so maybe this is not an issue.
Regards,
Dale.
- James Bott
- Posts: 4654
- Joined: Fri Nov 18, 2005 4:52 pm
- Location: San Diego, California, USA
- Contact:
Dale,
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
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.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.
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
- Enrico Maria Giordano
- Posts: 7355
- Joined: Thu Oct 06, 2005 8:17 pm
- Location: Roma - Italia
- Contact:
- Enrico Maria Giordano
- Posts: 7355
- Joined: Thu Oct 06, 2005 8:17 pm
- Location: Roma - Italia
- Contact:
- Enrico Maria Giordano
- Posts: 7355
- Joined: Thu Oct 06, 2005 8:17 pm
- Location: Roma - Italia
- Contact:
- James Bott
- Posts: 4654
- Joined: Fri Nov 18, 2005 4:52 pm
- Location: San Diego, California, USA
- Contact:
Dale
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
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.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.
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
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.
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.