|
Sir,
In our software, we want to show peak information to user,
No of Columns for General Info = 7 (Constant)
No of Columns for Injection Info = 22 (Constant)
No of Fixed Column(s) for Peak Info = 1(Constant) //It is for Peak Area Sum.
Total No of Columns for N Peaks: N x (13 + 2 x N)
Hence total Number of Columns in Datagrid in case of N Peaks
= 1(Separator) + 7 + 1(Separator) + 22 + 1(Separator) + 1 + N(13+2N)
= 2xNxN + 13xN + 33
Hence Number of Columns in the Datagrid increase as a 2nd Degree Equation.
This means
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
|
|
|
|
|
Well that is interesting. I can't think of any way to create 25,000 columns in a fast way(like can be done with SQLBulkCopy for rows). Good luck though!
I get all the news I need from the weather report - Paul Simon (from "The Only Living Boy in New York")
|
|
|
|
|
There's no way to create that many columns that fast. You're ARE going to have to find a different way to present your data. Just scrolling that many columns is going to be painfully slow.
On a 19" monitor, with all of these columns widths set at, say, a half inch wide, you're DataGrid would be almost A QUARTER OF A MILE (0.4km) WIDE!! A bit excessive, wouldn't you say?
This sounds more like a job for some kind of graph, not a DataGrid.
|
|
|
|
|
Dave Kreskowiak wrote: This sounds more like a job for some kind of graph, not a DataGrid.
Depends what the data needs to be visualized for. A graph would be the way to go if the general distribution is needed. If the user needs to be able to check the value of a parameter some sort of browsing tool would be a better alternative.
--
If you view money as inherently evil, I view it as my duty to assist in making you more virtuous.
|
|
|
|
|
I was thinking some kind of a grid were you could zoom in and see more detail, and possibly get a table showing the values if you zoomed in far enough, or maybe even hover the mouse over a point on the graph and have a floating table show you the values.
|
|
|
|
|
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 
Take care,
Tom
-----------------------------------------------
Check out my blog at http://tjoe.wordpress.com
|
|
|
|
|
What the heck is this anyway. The fact that you are trying to view this data it is such an un-normalized fashion completely fascinates me.
Shouldn't you be grouping these things?
General info should be a table
Injection data should be a table
the peaks thing sounds like a function or a set of functions
You should create this databse using meaningful relations. If you need to view dynamics mabye you should apply some differential analysis or maybe use graphs with animation.
Good luck
|
|
|
|
|
Mass Spec?
Anyway - you would need something like a tree to group the data.
You would then only have a constant set of Entries and N Pak-Entries with the Peakinfo underneath.
Though I speak with the tongues of men and of angels, and have not money, I am become as a sounding brass, or a tinkling cymbal.
George Orwell, "Keep the Aspidistra Flying", Opening words
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
I think you really need to review your design.
It's not possible for a human to view that much information all at once, even less to do some sort of analysis on it.
We will need to find better ways to present the results to the users.
|
|
|
|
|
Why don't you try using 25,000 DataGrids with one column each?
Phil
The opinions expressed in this post are not necessarily those of the author, especially if you find them impolite, inaccurate or inflammatory.
|
|
|
|
|
|
aloktambi wrote: 25000 columns
 Don't think that is really possible.
"Any sort of work in VB6 is bound to provide several WTF moments." - Christian Graus
|
|
|
|
|
Pfft DataGrids cause a localized lowering of the ambient air pressure; I avoid them at all cost. 
|
|
|
|
|
You need to design a custom control, which meets the criteria of you're data you are trying to present. A grid with 25000 columns isn't the way to go, you need a customized grid and when the user scrolls left/right load the columns on demand, it's easy with .net and even easier with WPF. A good software design engineer (cough, cough) such as my self would be able to create such a control (obviously your company would be billed).
WPF - Imagineers Wanted
Follow your nose using DoubleAnimationUsingPath
|
|
|
|
|
The only thing that can possibly handle that amount of columns is Excel 2007 where the column limit has been increased. I think this is your best bet too, in terms of rendering to screen compared to DataGrid.
-- modified at 18:41 Saturday 13th October, 2007
xacc.ide
The rule of three: "The first time you notice something that might repeat, don't generalize it. The second time the situation occurs, develop in a similar fashion -- possibly even copy/paste -- but don't generalize yet. On the third time, look to generalize the approach."
|
|
|
|
|
May I suggest the following?
1. Have a small fixed number of columns on your screen, say 10.
2. Add two honrizontal arrows on the screen that when clicked would show users the next/previous 10 columns.
|
|
|
|
|
And to get to the middle of the grid, you want the user to click the right arrow button, what, 1,250 times??
|
|
|
|
|
Perhaps a fast forward/backward button would help?
|
|
|
|
|
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".
|
|
|
|
|
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).
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
