Max number of columns in a datagrid?

Richard Gaskin ambassador at
Sun Nov 25 18:04:30 EST 2018

Geoff Canyon wrote:

 > On Fri, Nov 23, 2018 at 4:38 PM Richard Gaskin wrote:
 >> Geoff Canyon wrote:
 >> > It's not relevant to the current discussion, but waaaay back when,
 >> > I worked with a guy who had created some monster spreadsheets in
 >> > Excel with something like 9,000 columns. It was working, but it was
 >> > incredibly slow -- this was running on 68k Macs. Not expecting
 >> > success, I suggested he give FileMaker a shot. He did, and
 >> > amazingly, not only did it happily handle database definitions with
 >> > 9,000 fields, it was not just faster than Excel, it was actually
 >> > speedy. It had zero problems, and he built out the entirety of his
 >> > solution that way.
 >> Did he create a layout in FileMaker with 9,000 fields?
 >> If he had I suspect it would expose the root of the issue as being
 >> not so much about internal handling of the data, but about rendering
 >> it all.
 >> One more reason to remember that spreadsheets are not databases.
 >> Very different tools with very different feature focuses and
 >> tradeoffs.
 > I don't remember what-all he did with it, but FileMaker proved to be
 > remarkably resilient pretty much no matter what he threw at it.

Interesting, but alas missed what I was trying to convey which is 
relevant for us LC folks:

Plenty of tools can put data in memory.  Easy to do; most will do it well.

The challenge is in also *rendering* all of it on screen.

As we consider our options for work in LiveCode, it can be helpful to 
think about the implications of rendering, both in technical terms and 
for the user experience.

Technically, rendering is computationally expensive.  Indeed, it's 
infinitely more expensive than not rendering. :)  So any time we have 
more data than can be rendered efficiently, we might ask ourselves if we 
really need to render all of it.

And this leads us to the user experience:  we render data where doing so 
has value to the user. Everything that doesn't benefit the user has no 
place on the user's screen; it becomes just noise, effectively an 

What meaningful task is a user expected to perform with many thousands 
of columns rendered on screen?  How could it even be cognitively 
possible for a human to perform such tasks with any useful efficiency?

The answer would of course depend on the task in question.  But as a 
general rule, it may be safe to consider that if the user has to scroll 
horizontally more than the width of the room they're sitting in, it 
might be time to explore a simpler design that culls the noise for them 
and lets them see the smaller subset of data they're actually looking 
for more easily.

Furthering awareness of both of these aspects, technical and UX, we come 
back to the original issue cited in this thread, with LC sometimes not 
correctly rendering uncommonly large numbers of columns.

This limitation may have been eliminated, or close to eliminated, with 
the field object.  And now that fields have column-independent 
alignment, it's rare that there's ever a need to replace that one object 
with a thousand-object DataGrid for simple list views.

The DataGrid is bound to a limitation within LC for group contents: the 
formattedWidth and formattedHeight of a group cannot exceed 32765 px. 
Attempting to go beyond that flips the signed bit internally and objects 
will be rendered incorrectly.

I suppose it might be nice to see that extended, but in practice do we 
really need it?  How big should a group meaningfully be?

32,765 px is about 30 feet in size.  That's a lot to ask a user to 
scroll through, not to mention being a lot to ask LC to buffer so it can 
handle the scroll efficiently.

When we're faced with such monstrous scrolling requirements imposed on 
our users, a technical limitation in the engine may not be a bad thing 
at all.  It may turn out to be the prompting we need to re-think our 
designs to deliver a more useful and fluid user experience.

  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  Ambassador at      

More information about the use-livecode mailing list