Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 31 to 34 of 34 total |
Accurate positioning of scrollbar in DBGrid |
Tue, Aug 25 2009 1:21 PM | Permanent Link |
"Malcolm" | Leslie
You should read the thread in this ng titled "Some Feedback Required" dated 2006-09-25. You will see that Tim specifically explained the issues and asked us to vote. This may help you to understand why Tim cannot now change direction. Malcolm |
Tue, Aug 25 2009 1:40 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Roy,
<< Out of interest would it be possible to approach it from the opposite direction. Rather than what changes are required to ElevateDB to make a standard dbgrid show the button at the "correct" position; what changes are required to a dbgrid to get it to show the button at the "correct" position regardless of table/index type. >> The problem is that the standard grid, and most descendants or replacements, rely on the TDataSet.RecNo property to determine the logical row number in relation to the TDataSet.RecordCount property. Also, we can estimate the position of a row based upon the active index, but I'm not sure such a thing would work in practice because the scrollbar positioning would sometimes jump around a bit in a seemingly random fashion when the estimates are off a bit. -- Tim Young Elevate Software www.elevatesoft.com |
Tue, Aug 25 2009 1:51 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Leslie,
<< It is your code. you are the one who can estimate what it takes to change it. >> I don't need to estimate it - I've done it already in DBISAM and I specifically removed it in EDB because it causes the database engine to perform poorly with a large number of rows. It takes a lot more I/O to constantly update the statistics in the indexes. << I am just tyring to introduce ideas/ views you may have not considered yet. >> I've gone through this in a lot of detail already. Remember, it's my full-time job to solve these issues. If there were an easy way to do it, then you'd see logical row numbers implemented in every database engine out there. Most database engines/servers don't even allow you to browse a live table, rather they require you to fetch the rows into a client-side cache. That is why it may appear that certain products offer accurate logical row numbers - the rows are simply in the equivalent of a TList, making numbering easy. << By my understanding adding the ability to work with different type of indexes does not hurt the exisitng code as it is basically adding something like this to some places where indexes are involved: >> This is not correct. Any changes to the code could possibly hurt any number of other portions of the code, unless you're suggesting that I copy and paste the existing index navigation and updating code for each index type. << I my understanding this does not effect the stability of the current code. Though the amount of work and time required to implement and test some of the index related code to work with different kind of indexes can be much more than implementing this. It is a question of design. Eg with PostgeSQL the user can add costum index formats without any change to the engine. >> Does PostgresSQL offer logical row numbers on a live table ? If not, then what you're talking about has no bearing upon the topic at hand, other than to point out that PostgresSQL offers multiple index formats, none of which provide the functionality that we're discussing. -- Tim Young Elevate Software www.elevatesoft.com |
Wed, Aug 26 2009 3:42 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Tim
>The problem is that the standard grid, and most descendants or replacements, >rely on the TDataSet.RecNo property to determine the logical row number in >relation to the TDataSet.RecordCount property. Bummer >Also, we can estimate the position of a row based upon the active index, but >I'm not sure such a thing would work in practice because the scrollbar >positioning would sometimes jump around a bit in a seemingly random fashion >when the estimates are off a bit. That sounds highly suitable for a Microsoft platform and certainly suits my style of programming Roy Lambert |
« Previous Page | Page 4 of 4 | |
Jump to Page: 1 2 3 4 |
This web page was last updated on Tuesday, September 17, 2024 at 04:19 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |