I have the problem described in Microsoft Knowledge Base article
Q253211. I have 400,000 rows (i.e. way more than 65,535) and when I
scroll vertically, then release the scrollbar thumb, it snaps back up
to near the top.
I'm on VB6 SP6 already. Does anyone know of a fix?
Thanks.
MM
|
|
0
|
|
|
|
Reply
|
MM
|
6/10/2010 4:33:23 PM |
|
MM <kylix_is@yahoo.co.uk> wrote in
news:on42165pf7n4nrk1p59regccmcuuot7fhg@4ax.com:
> I have the problem described in Microsoft Knowledge Base
> article Q253211. I have 400,000 rows (i.e. way more than
> 65,535) and when I scroll vertically, then release the
> scrollbar thumb, it snaps back up to near the top.
>
> I'm on VB6 SP6 already. Does anyone know of a fix?
It doesn't say but does this only happen when the control is
databound ?
Drop back 10 and punt ?
Change to a virtual Listview ?
Or HyperlistNG (to do the virtual listview the easy way)-
http://planetsourcecode.com/vb/scripts/ShowCode.asp?txtCodeId=
66732&lngWId=1 , but the OCX for this is huge @ around 600K.
|
|
0
|
|
|
|
Reply
|
DanS
|
6/10/2010 4:51:12 PM
|
|
On Thu, 10 Jun 2010 17:33:23 +0100, MM <kylix_is@yahoo.co.uk> wrote:
� I have the problem described in Microsoft Knowledge Base article
� Q253211. I have 400,000 rows (i.e. way more than 65,535) and when I
� scroll vertically, then release the scrollbar thumb, it snaps back up
� to near the top.
�
� I'm on VB6 SP6 already. Does anyone know of a fix?
Have you tried paging? You can't display that many rows at a time so why load them?
How To Display Recordset 'Pages' in an MSFlexGrid Control Without Loading Entire Recordset into the
Grid
http://support.microsoft.com/kb/254117
Paul
~~~~
Microsoft MVP (Visual Basic)
|
|
0
|
|
|
|
Reply
|
Paul
|
6/10/2010 5:19:31 PM
|
|
On Thu, 10 Jun 2010 12:19:31 -0500, Paul Clement
<UseAdddressAtEndofMessage@swspectrum.com> wrote:
>On Thu, 10 Jun 2010 17:33:23 +0100, MM <kylix_is@yahoo.co.uk> wrote:
>
>� I have the problem described in Microsoft Knowledge Base article
>� Q253211. I have 400,000 rows (i.e. way more than 65,535) and when I
>� scroll vertically, then release the scrollbar thumb, it snaps back up
>� to near the top.
>�
>� I'm on VB6 SP6 already. Does anyone know of a fix?
>
>Have you tried paging? You can't display that many rows at a time so why load them?
>
>How To Display Recordset 'Pages' in an MSFlexGrid Control Without Loading Entire Recordset into the
>Grid
>http://support.microsoft.com/kb/254117
That's a possibility. I'll have a look.
MM
|
|
0
|
|
|
|
Reply
|
MM
|
6/10/2010 6:09:10 PM
|
|
MM formulated on Thursday :
> I have the problem described in Microsoft Knowledge Base article
> Q253211. I have 400,000 rows (i.e. way more than 65,535) and when I
> scroll vertically, then release the scrollbar thumb, it snaps back up
> to near the top.
>
> I'm on VB6 SP6 already. Does anyone know of a fix?
I don't think that one supports a "virtual" mode, does it? I use the
ComponentOne grid (VSFlexGrid) in virtual mode whenever I get more than
a few thousand cells going. It's *lightening* fast, and has no
practical limits, when used that way.
Did you snag all those C1 controls when they were offered free?
|
|
0
|
|
|
|
Reply
|
Karl
|
6/10/2010 6:39:12 PM
|
|
MM <kylix_is@yahoo.co.uk> wrote:
>I have the problem described in Microsoft Knowledge Base article
>Q253211. I have 400,000 rows (i.e. way more than 65,535) and when I
>scroll vertically, then release the scrollbar thumb, it snaps back up
>to near the top.
You might consider why you have so many rows. How is the user going to
navigate through all that? I'd suggest using some search criteria to whittle
the result set down to a reasonable size.
If you're simply linking the grid to a table this is the lazy way out. You
should be running a SQL and linking the result set programmatically.
I am working with a music database of 10,000 songs. This is way too many for
the user to work with, so I whittle it down based on genre, year, and other
search factors that make the resultset more palatable.
|
|
0
|
|
|
|
Reply
|
sfdavidkaye2
|
6/10/2010 7:50:59 PM
|
|
On Thu, 10 Jun 2010 11:39:12 -0700, Karl E. Peterson <karl@exmvps.org>
wrote:
>MM formulated on Thursday :
>> I have the problem described in Microsoft Knowledge Base article
>> Q253211. I have 400,000 rows (i.e. way more than 65,535) and when I
>> scroll vertically, then release the scrollbar thumb, it snaps back up
>> to near the top.
>>
>> I'm on VB6 SP6 already. Does anyone know of a fix?
>
>I don't think that one supports a "virtual" mode, does it? I use the
>ComponentOne grid (VSFlexGrid) in virtual mode whenever I get more than
>a few thousand cells going. It's *lightening* fast, and has no
>practical limits, when used that way.
>
>Did you snag all those C1 controls when they were offered free?
I think I may have them somewhere! I, too, am currently using
VsFlexGrid 7 in trial mode. It also has GetMergedRange which is useful
for determining the text of just the merged cells.
As I begin to use MsFlexGrid and MshFlexGrid for large recordsets it
increasingly becomes clear just how broken these controls are.
MsFlexGrid has a limit of 350,000 cells. And MshFlexGrid has this new
problem with 65,535 records after the previous problem with not
displaying more than 2048 rows was fixed in SP3.
In other words, neither MsFlexGrid nor MshFlexGrid is fit for this
purpose (of displaying large recordsets, not that I'd call 100,000
records large).
MM
|
|
0
|
|
|
|
Reply
|
MM
|
6/11/2010 7:24:49 AM
|
|
On Thu, 10 Jun 2010 19:50:59 GMT, sfdavidkaye2@yahoo.com (David Kaye)
wrote:
>MM <kylix_is@yahoo.co.uk> wrote:
>
>>I have the problem described in Microsoft Knowledge Base article
>>Q253211. I have 400,000 rows (i.e. way more than 65,535) and when I
>>scroll vertically, then release the scrollbar thumb, it snaps back up
>>to near the top.
>
>You might consider why you have so many rows. How is the user going to
>navigate through all that? I'd suggest using some search criteria to whittle
>the result set down to a reasonable size.
Fair enough, but the fact is that the grid is buggy if it won't
display more than 65,535 records. That isn't a lot at all and
MergeCells permits a much better overview anyway.
>If you're simply linking the grid to a table this is the lazy way out. You
>should be running a SQL and linking the result set programmatically.
That is exactly what I'm doing: Set flx.RecordSet = rs (or set
flx.DataSource = rs in the vsFlexGrid version). The query can limit
records to particular criteria, but sometimes it's useful to see all
the records in one lump. I also have column search in the resultant
grid.
MM
|
|
0
|
|
|
|
Reply
|
MM
|
6/11/2010 7:30:20 AM
|
|
MM laid this down on his screen :
> On Thu, 10 Jun 2010 11:39:12 -0700, Karl E. Peterson <karl@exmvps.org>
> wrote:
>
>> MM formulated on Thursday :
>>> I have the problem described in Microsoft Knowledge Base article
>>> Q253211. I have 400,000 rows (i.e. way more than 65,535) and when I
>>> scroll vertically, then release the scrollbar thumb, it snaps back up
>>> to near the top.
>>>
>>> I'm on VB6 SP6 already. Does anyone know of a fix?
>>
>> I don't think that one supports a "virtual" mode, does it? I use the
>> ComponentOne grid (VSFlexGrid) in virtual mode whenever I get more than
>> a few thousand cells going. It's *lightening* fast, and has no
>> practical limits, when used that way.
>>
>> Did you snag all those C1 controls when they were offered free?
>
> I think I may have them somewhere! I, too, am currently using
> VsFlexGrid 7 in trial mode. It also has GetMergedRange which is useful
> for determining the text of just the merged cells.
>
> As I begin to use MsFlexGrid and MshFlexGrid for large recordsets it
> increasingly becomes clear just how broken these controls are.
> MsFlexGrid has a limit of 350,000 cells. And MshFlexGrid has this new
> problem with 65,535 records after the previous problem with not
> displaying more than 2048 rows was fixed in SP3.
>
> In other words, neither MsFlexGrid nor MshFlexGrid is fit for this
> purpose (of displaying large recordsets, not that I'd call 100,000
> records large).
You need a virtual grid. I'm using "ComponentOne VSFlexGrid 8.0
(Light)" - the name it goes by in the Components dialog. When run in
this mode, it asks for each cell contents on an as-needed basis.
Lightening fast, by comparison.
Despite the numbers you quote for official limits, I've found that even
50000 cells is *crippling* on most.
|
|
0
|
|
|
|
Reply
|
Karl
|
6/11/2010 5:25:51 PM
|
|
MM <kylix_is@yahoo.co.uk> wrote:
>Fair enough, but the fact is that the grid is buggy if it won't
>display more than 65,535 records.
Why does that make it buggy? It's a practical limitation. No human can
possibly process 64k of records, let along the amount you're trying to do.
|
|
0
|
|
|
|
Reply
|
sfdavidkaye2
|
6/14/2010 7:01:18 AM
|
|
On Mon, 14 Jun 2010 07:01:18 GMT, sfdavidkaye2@yahoo.com (David Kaye)
wrote:
>MM <kylix_is@yahoo.co.uk> wrote:
>
>>Fair enough, but the fact is that the grid is buggy if it won't
>>display more than 65,535 records.
>
>Why does that make it buggy?
Because Microsoft have confirmed it. See Q253211.
> It's a practical limitation.
No, it's not. It's a bug.
> No human can
>possibly process 64k of records, let along the amount you're trying to do.
That's a matter of opinion. You cannot prevent people from seeing past
65535 because YOU don't think they ought to!
MM
|
|
0
|
|
|
|
Reply
|
MM
|
6/14/2010 8:37:21 AM
|
|
On Thu, 10 Jun 2010 11:39:12 -0700, Karl E. Peterson <karl@exmvps.org>
wrote:
>MM formulated on Thursday :
>> I have the problem described in Microsoft Knowledge Base article
>> Q253211. I have 400,000 rows (i.e. way more than 65,535) and when I
>> scroll vertically, then release the scrollbar thumb, it snaps back up
>> to near the top.
>>
>> I'm on VB6 SP6 already. Does anyone know of a fix?
>
>I don't think that one supports a "virtual" mode, does it? I use the
>ComponentOne grid (VSFlexGrid) in virtual mode whenever I get more than
>a few thousand cells going. It's *lightening* fast, and has no
>practical limits, when used that way.
>
>Did you snag all those C1 controls when they were offered free?
I've checked my backups and I have something called
c1enterprise_303.zip. Is this still valid today?
MM
|
|
0
|
|
|
|
Reply
|
MM
|
6/17/2010 2:55:33 PM
|
|
MM formulated the question :
> On Thu, 10 Jun 2010 11:39:12 -0700, Karl E. Peterson <karl@exmvps.org>
> wrote:
>
>> MM formulated on Thursday :
>>> I have the problem described in Microsoft Knowledge Base article
>>> Q253211. I have 400,000 rows (i.e. way more than 65,535) and when I
>>> scroll vertically, then release the scrollbar thumb, it snaps back up
>>> to near the top.
>>>
>>> I'm on VB6 SP6 already. Does anyone know of a fix?
>>
>> I don't think that one supports a "virtual" mode, does it? I use the
>> ComponentOne grid (VSFlexGrid) in virtual mode whenever I get more than
>> a few thousand cells going. It's *lightening* fast, and has no
>> practical limits, when used that way.
>>
>> Did you snag all those C1 controls when they were offered free?
>
> I've checked my backups and I have something called
> c1enterprise_303.zip. Is this still valid today?
I think so, yeah. I've installed some of them as recently as a few
months ago on a new system.
--
..NET: It's About Trust! http://vfred.mvps.org
Customer Hatred Knows No Bounds at MSFT
ClassicVB Users Regroup! comp.lang.basic.visual.misc
Free usenet access at http://www.eternal-september.org
|
|
0
|
|
|
|
Reply
|
Karl
|
6/17/2010 5:51:37 PM
|
|
On Thu, 17 Jun 2010 10:51:37 -0700, Karl E. Peterson <karl@exmvps.org>
wrote:
>MM formulated the question :
>> On Thu, 10 Jun 2010 11:39:12 -0700, Karl E. Peterson <karl@exmvps.org>
>> wrote:
>>
>>> MM formulated on Thursday :
>>>> I have the problem described in Microsoft Knowledge Base article
>>>> Q253211. I have 400,000 rows (i.e. way more than 65,535) and when I
>>>> scroll vertically, then release the scrollbar thumb, it snaps back up
>>>> to near the top.
>>>>
>>>> I'm on VB6 SP6 already. Does anyone know of a fix?
>>>
>>> I don't think that one supports a "virtual" mode, does it? I use the
>>> ComponentOne grid (VSFlexGrid) in virtual mode whenever I get more than
>>> a few thousand cells going. It's *lightening* fast, and has no
>>> practical limits, when used that way.
>>>
>>> Did you snag all those C1 controls when they were offered free?
>>
>> I've checked my backups and I have something called
>> c1enterprise_303.zip. Is this still valid today?
>
>I think so, yeah. I've installed some of them as recently as a few
>months ago on a new system.
So are these controls free forever? I can confirm that I installed the
vsFlexGrid 8.0, using the registration number I received years ago and
it all worked, no probs. In the intervening years I have changed my
'username' and my email address several times, yet the control still
got licensed okay!
MM
|
|
0
|
|
|
|
Reply
|
MM
|
6/17/2010 7:34:18 PM
|
|
MM expressed precisely :
> On Thu, 17 Jun 2010 10:51:37 -0700, Karl E. Peterson <karl@exmvps.org>
> wrote:
>
>> MM formulated the question :
>>> On Thu, 10 Jun 2010 11:39:12 -0700, Karl E. Peterson <karl@exmvps.org>
>>> wrote:
>>>
>>>> MM formulated on Thursday :
>>>>> I have the problem described in Microsoft Knowledge Base article
>>>>> Q253211. I have 400,000 rows (i.e. way more than 65,535) and when I
>>>>> scroll vertically, then release the scrollbar thumb, it snaps back up
>>>>> to near the top.
>>>>>
>>>>> I'm on VB6 SP6 already. Does anyone know of a fix?
>>>>
>>>> I don't think that one supports a "virtual" mode, does it? I use the
>>>> ComponentOne grid (VSFlexGrid) in virtual mode whenever I get more than
>>>> a few thousand cells going. It's *lightening* fast, and has no
>>>> practical limits, when used that way.
>>>>
>>>> Did you snag all those C1 controls when they were offered free?
>>>
>>> I've checked my backups and I have something called
>>> c1enterprise_303.zip. Is this still valid today?
>>
>> I think so, yeah. I've installed some of them as recently as a few
>> months ago on a new system.
>
> So are these controls free forever?
Afaik, sure, why not?
> I can confirm that I installed the
> vsFlexGrid 8.0, using the registration number I received years ago and
> it all worked, no probs. In the intervening years I have changed my
> 'username' and my email address several times, yet the control still
> got licensed okay!
There ya go. :-)
--
..NET: It's About Trust! http://vfred.mvps.org
Customer Hatred Knows No Bounds at MSFT
ClassicVB Users Regroup! comp.lang.basic.visual.misc
Free usenet access at http://www.eternal-september.org
|
|
0
|
|
|
|
Reply
|
Karl
|
6/17/2010 7:49:32 PM
|
|
MM <kylix_is@yahoo.co.uk> wrote:
>That's a matter of opinion. You cannot prevent people from seeing past
>65535 because YOU don't think they ought to!
I suggest you get some training in interface design, and marketing wouldn't
hurt, either. There's the geek way and then there's the way the rest of the
world sees software. The good software is the kind ordinary people can relate
to. A grid with >65535 rows is simply not good software design.
My software has been in use at Charles Schwab, Wells Fargo Bank, Bank of
America, and in human organ transplant centers worldwide. The reason I've had
some success with my software is because I write not for geeks but for
ordinary users.
|
|
0
|
|
|
|
Reply
|
sfdavidkaye2
|
6/18/2010 2:26:18 AM
|
|
On Fri, 18 Jun 2010 02:26:18 GMT, sfdavidkaye2@yahoo.com (David Kaye)
wrote:
> The good software is the kind ordinary people can relate
>to.
The good software is the kind that doesn't have a bug that prevents
rows past 65,535 from being viewed.
MM
|
|
0
|
|
|
|
Reply
|
MM
|
6/18/2010 5:15:35 AM
|
|
On 6/17/2010 10:15 PM, MM wrote:
> On Fri, 18 Jun 2010 02:26:18 GMT, sfdavidkaye2@yahoo.com (David Kaye)
> wrote:
>
>> The good software is the kind ordinary people can relate
>> to.
>
> The good software is the kind that doesn't have a bug that prevents
> rows past 65,535 from being viewed.
>
> MM
<joke>
Are the viewers human, I mean, do they by any chance have compound eyes?
From Wikipedia, "A compound eye may consist of thousands of individual
photoreceptor units." And from tr1.harunyahya.com, "A fly has compound
eyes on both sides of its head, each of which is divided into 4,000
sections..."
</joke>
|
|
0
|
|
|
|
Reply
|
Mike
|
6/18/2010 5:22:17 AM
|
|
On 18/06/2010 06:15, MM wrote:
> On Fri, 18 Jun 2010 02:26:18 GMT, sfdavidkaye2@yahoo.com (David Kaye)
> wrote:
>
>> The good software is the kind ordinary people can relate
>> to.
>
> The good software is the kind that doesn't have a bug that prevents
> rows past 65,535 from being viewed.
No, that's just (at least one) bug less software.
Doesn't necessarily make it good.
--
Dee Earley (dee.earley@icode.co.uk)
i-Catcher Development Team
iCode Systems
(Replies direct to my email address will be ignored.
Please reply to the group.)
|
|
0
|
|
|
|
Reply
|
Dee
|
6/18/2010 8:03:46 AM
|
|
On Fri, 18 Jun 2010 09:03:46 +0100, Dee Earley
<dee.earley@icode.co.uk> wrote:
>On 18/06/2010 06:15, MM wrote:
>> On Fri, 18 Jun 2010 02:26:18 GMT, sfdavidkaye2@yahoo.com (David Kaye)
>> wrote:
>>
>>> The good software is the kind ordinary people can relate
>>> to.
>>
>> The good software is the kind that doesn't have a bug that prevents
>> rows past 65,535 from being viewed.
>
>No, that's just (at least one) bug less software.
>Doesn't necessarily make it good.
But don't you strive for bug-free software, first and foremost?
Whether users want to see past 65,535 is surely *their* business, not
the business of some net nanny who celebrates a bug as the reason why
they shouldn't?
MM
|
|
0
|
|
|
|
Reply
|
MM
|
6/18/2010 10:19:06 AM
|
|
On Thu, 17 Jun 2010 22:22:17 -0700, Mike S <mscir@yahoo.com> wrote:
>On 6/17/2010 10:15 PM, MM wrote:
>> On Fri, 18 Jun 2010 02:26:18 GMT, sfdavidkaye2@yahoo.com (David Kaye)
>> wrote:
>>
>>> The good software is the kind ordinary people can relate
>>> to.
>>
>> The good software is the kind that doesn't have a bug that prevents
>> rows past 65,535 from being viewed.
>>
>> MM
>
><joke>
>Are the viewers human, I mean, do they by any chance have compound eyes?
> From Wikipedia, "A compound eye may consist of thousands of individual
>photoreceptor units." And from tr1.harunyahya.com, "A fly has compound
>eyes on both sides of its head, each of which is divided into 4,000
>sections..."
></joke>
Sorry, I didn't get it. Can you explain?
MM
|
|
0
|
|
|
|
Reply
|
MM
|
6/18/2010 10:19:32 AM
|
|
On 18/06/2010 11:19, MM wrote:
> On Fri, 18 Jun 2010 09:03:46 +0100, Dee Earley
> <dee.earley@icode.co.uk> wrote:
>
>> On 18/06/2010 06:15, MM wrote:
>>> On Fri, 18 Jun 2010 02:26:18 GMT, sfdavidkaye2@yahoo.com (David Kaye)
>>> wrote:
>>>
>>>> The good software is the kind ordinary people can relate
>>>> to.
>>>
>>> The good software is the kind that doesn't have a bug that prevents
>>> rows past 65,535 from being viewed.
>>
>> No, that's just (at least one) bug less software.
>> Doesn't necessarily make it good.
>
> But don't you strive for bug-free software, first and foremost?
> Whether users want to see past 65,535 is surely *their* business, not
> the business of some net nanny who celebrates a bug as the reason why
> they shouldn't?
No, I strive for good software which is far more than just bug free,
usable and well designed also come into it.
I'd hope a "Hello world" app would be bug free, but it is far from good.."
Long lists are impractical, fact.
If they weren't, why do you think paging was developed?
I frequently have to work on a (currently) 92K item grid and that is a
right PITA without the filter/search.
Pretty much all you can do without filtering is go "ohh, lots of items!".
Yes, there appears to be a bug in that grid that means it can't handle
more than 65Ki entries, but that most likely means it is VERY
infrequently used in that situation.
Just because my computer has 2GB of RAM, doesn't mean I should
immediately cache 2GB of all the documents available in case the user
happens to look at some of them..
--
Dee Earley (dee.earley@icode.co.uk)
i-Catcher Development Team
iCode Systems
(Replies direct to my email address will be ignored.
Please reply to the group.)
|
|
0
|
|
|
|
Reply
|
Dee
|
6/18/2010 11:12:18 AM
|
|
"Dee Earley" <dee.earley@icode.co.uk> wrote in message
news:OkctGdtDLHA.2052@TK2MSFTNGP06.phx.gbl...
> Just because my computer has 2GB of RAM, doesn't
> mean I should immediately cache 2GB of all the documents
> available in case the user happens to look at some of them..
Well you'd best tell that to your bussom buddies at Micro$oft because Vista
swallows up most of the first GB of RAM just to stay on its feet!
Mike
|
|
0
|
|
|
|
Reply
|
Mike
|
6/18/2010 12:29:01 PM
|
|
On 18/06/2010 13:29, Mike Williams wrote:
> "Dee Earley"<dee.earley@icode.co.uk> wrote in message
> news:OkctGdtDLHA.2052@TK2MSFTNGP06.phx.gbl...
>
>> Just because my computer has 2GB of RAM, doesn't
>> mean I should immediately cache 2GB of all the documents
>> available in case the user happens to look at some of them..
>
> Well you'd best tell that to your bussom buddies at Micro$oft because Vista
> swallows up most of the first GB of RAM just to stay on its feet!
I didn't say Vista was good.. :p
--
Dee Earley (dee.earley@icode.co.uk)
i-Catcher Development Team
iCode Systems
(Replies direct to my email address will be ignored.
Please reply to the group.)
|
|
0
|
|
|
|
Reply
|
Dee
|
6/18/2010 12:34:44 PM
|
|
On Fri, 18 Jun 2010 12:12:18 +0100, Dee Earley
<dee.earley@icode.co.uk> wrote:
>Yes, there appears to be a bug in that grid that means it can't handle
>more than 65Ki entries, but that most likely means it is VERY
>infrequently used in that situation.
No "appears" about it! It's a bug. Microsoft acknowledged it as such.
MM
|
|
0
|
|
|
|
Reply
|
MM
|
6/18/2010 2:51:25 PM
|
|
MM wrote:
> On Fri, 18 Jun 2010 12:12:18 +0100, Dee Earley
> <dee.earley@icode.co.uk> wrote:
>
>> Yes, there appears to be a bug in that grid that means it can't handle
>> more than 65Ki entries, but that most likely means it is VERY
>> infrequently used in that situation.
>
> No "appears" about it! It's a bug. Microsoft acknowledged it as such.
Well, more like a "feature".
The index was coded as Integer rather than w/ a Long -- perfectly
reasonable design criterion as over 64K entries in a grid is pretty much
useless anyway (as others have noted).
Whether it's a "bug" in your opinion or not doesn't really change that
it is a limitation and it ain't agonna' go away nor that the design to
use more than 64K entries in a grid in a UI is not an effective
presentation method.
--
|
|
0
|
|
|
|
Reply
|
dpb
|
6/18/2010 3:05:47 PM
|
|
"MM" <kylix_is@yahoo.co.uk> schrieb im Newsbeitrag
news:tr1n169rn6vaujuh7fonjbfkn1ep951s97@4ax.com...
> On Fri, 18 Jun 2010 12:12:18 +0100, Dee Earley
> <dee.earley@icode.co.uk> wrote:
>
>>Yes, there appears to be a bug in that grid that means it can't handle
>>more than 65Ki entries, but that most likely means it is VERY
>>infrequently used in that situation.
>
> No "appears" about it! It's a bug. Microsoft acknowledged it as such.
>
> MM
It's a bug, true. And the MSFlexgrid has it too, not only the Datagrid
and the MSHFlexgrid. With the older Flexgrid I got an error when I
tried to add 50,000 additional rows to a 2 column grid with already
150,000 rows ("can't allocate memory for flexgrid").
But you *can* scroll down just fine by clicking on the scrollbar.
I tried it with a 1,000,000 rows MSHFlexgrid. <g>
Dragging is what doesn't work.
It seems that somewere deep inside the grid, the scrollbar does
use a long, but then it's casted to an unsigned int, ignoring the
higher bits. This unsigned int is then used to position grid rows
and scrollbar.
In effect it's like a Modulo 65536 of the value you dragged it down.
BTW, it's not the only control with problems related to the
use of integers instead of longs.
Try a Listbox:
- you can easily add some 100,000 items to a listbox.
- if you select an item by clicking on it, try to get the
associated ListIndex value.
for item 32768 you get ListIndex = 32767 (Listindex starts with 0)
for item 32769 you get ListIndex = -32768, and so on ...
for item 65536 it's Listindex -1,
for item 65537 it's Listindex 0,
for item 65538 it's Listindex 1 and so on ...
Using the ListIndex, you can only access items up to Listindex 32767
because VB happily displays the higher unsigned int values as
negative values but refuses to accept these negative values.
I suspect Windows provides internally a long and the higher bits
were simply ignored.
Helmut.
|
|
0
|
|
|
|
Reply
|
Helmut
|
6/18/2010 8:45:15 PM
|
|
MM <kylix_is@yahoo.co.uk> wrote:
>The good software is the kind that doesn't have a bug that prevents
>rows past 65,535 from being viewed.
The first version of the grid had a built-in limit of what, 2048 rows?
Something like that.
I'm in awe that you and whoever else can't see that populating a grid with
65000 records is lunacy. Nobody can read all that. With more than a few
dozen rows people eyes begin to glaze over.
It's just laziness. Instead of writing code to sub-select out of the
recordset you're just taking the easy way out. A good coder considers the
user, not the ease of writing the code.
I have a database listing upwards of 100,000 songs. There is no way in hell
that my software is ever going to show all the songs at once. I wouldn't
dream of subjecting a user to such a body-slam of data. The recordsets are
subselected by criteria such as artist, year, genre, etc.
|
|
0
|
|
|
|
Reply
|
sfdavidkaye2
|
6/19/2010 8:38:31 AM
|
|
On Sat, 19 Jun 2010 08:38:31 GMT, sfdavidkaye2@yahoo.com (David Kaye)
wrote:
>MM <kylix_is@yahoo.co.uk> wrote:
>
>>The good software is the kind that doesn't have a bug that prevents
>>rows past 65,535 from being viewed.
>
>The first version of the grid had a built-in limit of what, 2048 rows?
>Something like that.
>
>I'm in awe that you and whoever else can't see that populating a grid with
>65000 records is lunacy. Nobody can read all that. With more than a few
>dozen rows people eyes begin to glaze over.
Did you miss my comment re MergeCells, then?
MM
|
|
0
|
|
|
|
Reply
|
MM
|
6/19/2010 8:12:47 PM
|
|
David Kaye explained :
> I'm in awe that you and whoever else can't see that populating a grid with
> 65000 records is lunacy. Nobody can read all that. With more than a few
> dozen rows people eyes begin to glaze over.
Nonetheless, one of the *MAJOR* selling points in Office 2007 is the
expansion of Excel spreadsheets to 2^14 columns and 2^20 rows! ;-)
(The old limits were 2^8 and 2^16, respectively.)
--
..NET: It's About Trust! http://vfred.mvps.org
Customer Hatred Knows No Bounds at MSFT
ClassicVB Users Regroup! comp.lang.basic.visual.misc
Free usenet access at http://www.eternal-september.org
|
|
0
|
|
|
|
Reply
|
Karl
|
6/21/2010 8:16:43 PM
|
|
On Mon, 21 Jun 2010 13:16:43 -0700, Karl E. Peterson <karl@exmvps.org>
wrote:
>David Kaye explained :
>> I'm in awe that you and whoever else can't see that populating a grid with
>> 65000 records is lunacy. Nobody can read all that. With more than a few
>> dozen rows people eyes begin to glaze over.
>
>Nonetheless, one of the *MAJOR* selling points in Office 2007 is the
>expansion of Excel spreadsheets to 2^14 columns and 2^20 rows! ;-)
>
>(The old limits were 2^8 and 2^16, respectively.)
Such an expansion represents an increase in the total items the
application can store and subsquently viewable in the raw worksheet,
not unlike an MSAccess table in an MSAccess project.
However, every Office developer's guide within the first few chapters
immediately advises various methods to assemble "views" to make the
data more manageable if not more "user-friendly".
In 35+ years of programming I've never seen a single client
application that didn't prosper with improved "views" and a reduction
in the data presented.
-ralph
|
|
0
|
|
|
|
Reply
|
ralph
|
6/21/2010 9:22:30 PM
|
|
It happens that ralph formulated :
> On Mon, 21 Jun 2010 13:16:43 -0700, Karl E. Peterson <karl@exmvps.org>
> wrote:
>
>> David Kaye explained :
>>> I'm in awe that you and whoever else can't see that populating a grid with
>>> 65000 records is lunacy. Nobody can read all that. With more than a few
>>> dozen rows people eyes begin to glaze over.
>>
>> Nonetheless, one of the *MAJOR* selling points in Office 2007 is the
>> expansion of Excel spreadsheets to 2^14 columns and 2^20 rows! ;-)
>>
>> (The old limits were 2^8 and 2^16, respectively.)
>
> Such an expansion represents an increase in the total items the
> application can store and subsquently viewable in the raw worksheet,
> not unlike an MSAccess table in an MSAccess project.
>
> However, every Office developer's guide within the first few chapters
> immediately advises various methods to assemble "views" to make the
> data more manageable if not more "user-friendly".
>
> In 35+ years of programming I've never seen a single client
> application that didn't prosper with improved "views" and a reduction
> in the data presented.
Well, sure, but there's never been a model with enough dataspace, and
sometimes you just gotta go looking at the raw stuff. :-)
--
..NET: It's About Trust! http://vfred.mvps.org
Customer Hatred Knows No Bounds at MSFT
ClassicVB Users Regroup! comp.lang.basic.visual.misc
Free usenet access at http://www.eternal-september.org
|
|
0
|
|
|
|
Reply
|
Karl
|
6/21/2010 10:03:25 PM
|
|
On Mon, 21 Jun 2010 15:03:25 -0700, Karl E. Peterson <karl@exmvps.org>
wrote:
>
>Well, sure, but there's never been a model with enough dataspace, and
>sometimes you just gotta go looking at the raw stuff. :-)
Ha. And if not we would go looking for some way to do so.
Which reminds me of a particular boring episode in my past - a sure
sign of old age ...
Way back when, when I was young, a C Unix Systems programmer, and thus
assured I knew everything, I was contracted to provide a Venix
workstation access to a proprietary mainframe database (some kind of
Craig/204 look-a-like).
I was having trouble with the data so I went to the DBAs and asked to
see the raw records. Insisting there was no way I could make sense of
the data without it. They had a pained look, but said they would take
care of it.
The next morning I walked in my office to find three boxes full of
fan-fold print out. I spent a few days pretending to peruse it in
detail.
-ralph
|
|
0
|
|
|
|
Reply
|
ralph
|
6/22/2010 2:36:49 AM
|
|
On Sat, 19 Jun 2010 08:38:31 GMT, sfdavidkaye2@yahoo.com (David Kaye)
wrote:
>I'm in awe that you and whoever else can't see that populating a grid with
>65000 records is lunacy. Nobody can read all that. With more than a few
>dozen rows people eyes begin to glaze over.
"640K ought to be enough for anybody." - Bill Gates, 1981.
MM
|
|
0
|
|
|
|
Reply
|
MM
|
6/22/2010 5:49:38 AM
|
|
On 18/06/2010 15:51, MM wrote:
> On Fri, 18 Jun 2010 12:12:18 +0100, Dee Earley
> <dee.earley@icode.co.uk> wrote:
>
>> Yes, there appears to be a bug in that grid that means it can't handle
>> more than 65Ki entries, but that most likely means it is VERY
>> infrequently used in that situation.
>
> No "appears" about it! It's a bug. Microsoft acknowledged it as such.
I said appears as I'm going on 3rd hand information.
I don't use the control, I haven't researched it, I haven't hit the problem.
--
Dee Earley (dee.earley@icode.co.uk)
i-Catcher Development Team
iCode Systems
(Replies direct to my email address will be ignored.
Please reply to the group.)
|
|
0
|
|
|
|
Reply
|
Dee
|
6/22/2010 8:18:40 AM
|
|
ralph submitted this idea :
> On Mon, 21 Jun 2010 15:03:25 -0700, Karl E. Peterson <karl@exmvps.org>
> wrote:
>
>>
>> Well, sure, but there's never been a model with enough dataspace, and
>> sometimes you just gotta go looking at the raw stuff. :-)
>
> Ha. And if not we would go looking for some way to do so.
>
> Which reminds me of a particular boring episode in my past - a sure
> sign of old age ...
>
> Way back when, when I was young, a C Unix Systems programmer, and thus
> assured I knew everything,
But of course. <g>
> I was contracted to provide a Venix
> workstation access to a proprietary mainframe database (some kind of
> Craig/204 look-a-like).
>
> I was having trouble with the data so I went to the DBAs and asked to
> see the raw records. Insisting there was no way I could make sense of
> the data without it. They had a pained look, but said they would take
> care of it.
>
> The next morning I walked in my office to find three boxes full of
> fan-fold print out. I spent a few days pretending to peruse it in
> detail.
LOL! Well, I bet you didn't ask them *again* for such a silly need,
hmmm? <bg>
--
..NET: It's About Trust! http://vfred.mvps.org
Customer Hatred Knows No Bounds at MSFT
ClassicVB Users Regroup! comp.lang.basic.visual.misc
Free usenet access at http://www.eternal-september.org
|
|
0
|
|
|
|
Reply
|
Karl
|
6/22/2010 5:57:24 PM
|
|
MM wrote:
....
> "640K ought to be enough for anybody." - Bill Gates, 1981.
The CDC 7600 had ... a 65 Kword primary memory using core and
variable-size (up to 512 Kword) secondary memory (depending on site).
.... in 1969, it carried a price tag around $5 million (more as options
and features were added). ...
Before the switchover to the CDC 6600 followed by the 7600, used Philco
S2000 with only 32K memory and 27 (!!!count 'em) 7-track tapes...
We designed and built currently operating power reactors w/ it and
predecessors (including the slide rule and desktop Monroe calculators
before HP's magic little box). It ain't how much memory, it's what you
do with what there is.
I venture 80% of memory and CPU cycles now are wasted entirely on
interface and fluff instead of doing actual useful work.
Same thing can be said for data. Out of the megabytes you may have,
only a tiny fraction can be of any visual use at any one time.
(And, sorry, guess I didn't hit the "K" button afterall....ok, there it
is...done! :) )
--
|
|
0
|
|
|
|
Reply
|
dpb
|
6/22/2010 6:22:50 PM
|
|
"David Kaye" <sfdavidkaye2@yahoo.com> wrote in message
news:hv4k3u$q0d$3@news.eternal-september.org...
: MM <kylix_is@yahoo.co.uk> wrote:
:
: Why does that make it buggy? It's a practical limitation. No human can
: possibly process 64k of records, let along the amount you're trying to do.
Actually, Mr. perfect-command-of-the-English-language, it's "let alone", not
"let along".
I guess you aren't as perfect as you want everyone to believe. Remember
that the next time you feel the need to correct someone else, eh?
--
Customer Hatred Knows No Bounds at MSFT
Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup! comp.lang.basic.visual.misc
Bawwk! Paulie want a dingleball, bawwk!
|
|
0
|
|
|
|
Reply
|
Kevin
|
6/28/2010 1:16:46 PM
|
|
"David Kaye" <sfdavidkaye2@yahoo.com> wrote in message
news:hvhvm7$4dk$1@news.eternal-september.org...
: MM <kylix_is@yahoo.co.uk> wrote:
:
: It's just laziness. Instead of writing code to sub-select out of the
: recordset you're just taking the easy way out. A good coder considers the
: user, not the ease of writing the code.
Actually, a good coders knows how to write his own code, versus asking
others on usenet to find it (or write it) for him. That's also a sign of
laziness. But you already know this. <g>
: I have a database listing upwards of 100,000 songs.
Do you want a cookie, or the lot of us to bow down and kiss your unwashed
feet? I think you'll get neither. No one is impressed with a code leech.
--
Customer Hatred Knows No Bounds at MSFT
Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup! comp.lang.basic.visual.misc
Bawwk! Paulie want a dingleball, bawwk!
|
|
0
|
|
|
|
Reply
|
Kevin
|
6/28/2010 1:20:35 PM
|
|
|
38 Replies
360 Views
(page loaded in 0.577 seconds)
Similiar Articles:9/6/2012 2:30:59 AM
|