Adding Columns in DataGrid at run time

[Dave Kreskowiak]

Even at moving 1,000 columns at a time, that's still 12.5 clicks to see the middle of the table. No matter how you bandaid this, it's still a horrible "solution".

A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
     2006, 2007

[Xiangyang Liu]

Dave Kreskowiak wrote:

No matter how you bandaid this, it's still a horrible "solution".

As I recall, the original problem is that the initial poster can't create that many columns in a grid. My "solution" avoids the difficulty of creating that many columns, it is not intended to answer the question of how the hell the users are going to use the application. :) I agree with you that it is a bad design in the first place (that the app needs to create so many columns in a grid).

My .NET Business Application Framework My Home Page

[daniilzol]

Dave Kreskowiak wrote:

Even at moving 1,000 columns at a time, that's still 12.5 clicks to see the middle of the table. No matter how you bandaid this, it's still a horrible "solution".

Not that I advocate continuing on a design path doomed to fail, but you could always have "Jump To" button which would work just fine, maybe even acceptable to a given client assuming it was the same client that came up with 25,000 columns requirement.

[realJSOP]

I think you need to re-design your application. Twenty five THOUSAND columns? I'm almost afraid to ask how many rows you anticipate having...

"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001

[W Balboos GHB]

My current employer hired a contractor who, himself, contracted out some software to India. It was textbook quality work - in other words, lacking insight. It was, after some debates (read: swallow pride) relegated to the scrap-heap - unused. This would seem to be an even more extreme (and certainly more amusing) example of meeting design specs as would a thoughtless drone. Management often seems to have a special skill at managing to muck things up. First there was a make-or-buy -> make was cheaper (until they learned that maintainence, custom modifications, upgrades, etc. cost money, too.). Next, they decided if we have to 'make' our software, let's get it done cheap in some distant land. Turns out that it's not so cheap, after all: once you factor in the extra time in getting the specs understood, and fix after fix on items that should have (would have!) been common sense if it were done home-grown. Can't wait to see what's next!

"The difference between genius and stupidity is that genius has its limits." - Albert Einstein

[TJoe]

You are assuming there are only 25000 columns, if there are more peaks then there are more columns: From the author of the thread: "For 10 peaks Column Count will be 363 For 25 peaks Column Count will be 1608 For 50 peaks Column Count will be 5683 For 100 peaks Column Count will be 21333 For 150 peaks Column Count will be 46983 For 200 peaks Column Count will be 82633 " So it may be closer to a mile :laugh:

Take care, Tom ----------------------------------------------- Check out my blog at http://tjoe.wordpress.com

[Jesse Chunn]

This is not a management problem. This is a programmer problem. This data is obviously not displayable in the way this programmer is trying to display it. Excel can't even begin to handle that. Anyone that would even consider having a datagrid with 25000 columns, or even 2500 columns, or even 250 columns, is clearly not ready to be doing UI design. The requirement is NOT to have 25000 columns in a datagrid. The requirement is to give the user access to 25000 peices of heirarchically(sp?) related information. That is more like a treeview or a nested datagrid, or some other type of "drill-down" UI. Having said all that, if you were to actually try to implement this as a datagrid in a way that was fast enough to use, you would have to virtualize the datagrid so that it loads as the user scrolls, and unloads the portion that has scrolled off-screen.

Standard answer: It can be done in two weeks, provided nothing unexpected happens.

[W Balboos GHB]

Actually, we are in agreement on this point. Rereading who I expressed my (two) points, I see how you would have replied as you did. My fault. The programmer was referred to as a . . . "drone". The management was being chastised for being concerned with cheap work instead of good work. They really don't understand (why else why would they be managers?) that the body of knowledge gained by experience implimented in a program (or other creative outlet) is a substantial "Value Added".

"The difference between genius and stupidity is that genius has its limits." - Albert Einstein

[Alan Balkany]

The obvious solution is to use a virtual table, i.e. only generate the rows and columns that are currently visible on screen. When the user scrolls this huge table, simply get the values of the visible cells and the visible row/column headers, and display them.

[Mikkel Toudal Kristiansen]

I can't help thinking about a quote from Uncle Bob (Robert C. Martin at ObjectMentor): When a customer comes up to you with his cell phone and says: "I need a bigger antenna!" You should think "He needs better reception on his cell phone" and not "He wants the mother of all cell phone antennas, 'cause it is 15 inches long" You should always ask yourself, "Why do they want that?", try putting yourself in your customer's shoes.