|
I'm finding it difficult to find any information about using DataGrids in quite the way I've been doing so. Most people, it seems, have "advanced" requirements that are met by TableStyles. My own problems seem to be more complex. I am using a combo box in the grid that has to display different contents depending on the row. I also need to alter the visible width of the parent row columns when their combo boxes edit GUIDs - they insist on displaying as wide as the invisible GUID, not the smaller visible text. Most people never have to bother binding a grid to a whole DataSet with relations.
It's entirely possible that I'm doing this the wrong way. It's also possible that I've reached the limit of what the basic DataGrid can give me. To go beyond this I may need to write my own Grid control to give me what I need.
Alternatively, I might be able to use some other controls to display the parent rows slightly better than the default Grid display.
John N
|
|
|
|
|
I've seen some other in-place merge-sort algorithms around, and the auxiliary storage requirements are usually the same size as the source list, which, in my opinion, defeats about half the purpose of doing the sort in-place anyway. So I developed this method here:
string[] unsorted = { "one", "two", "three", "four", "five", "six", "seven", "eight", "nine" };
int sz = 1;
while (sz < unsorted.Length)
{
for (int n = 0; n < unsorted.Length / sz; n += 2)
{
int list1 = n*sz;
int i1 = list1;
int i2 = (n+1)*sz;
while (i1 < i2 && i2 < (n+2)*sz && i2 < unsorted.Length)
{
if (unsorted[i1].CompareTo(unsorted[i2]) < 0)
{
i1++;
}
else
{
string temp = unsorted[i2];
for (int i = i2; i > i1; i--)
{
unsorted[i] = unsorted[i-1];
}
unsorted[list1] = temp;
i1++;
i2++;
}
list1++;
}
}
sz *= 2;
}
The trade-off, of course, is a bit of performance. By refusing to copy the array externally, we also lose the ability to perform every single item insertion in constant time. This may be a quick way to go when memory is very tight.
John N
|
|
|
|
|
I've just discovered a very interesting method of deploying my webservice-based rich client. I've found that I can copy them both into the same directory on the server and everything is fine, which cuts down the deployment versioning problems significantly.
Okay, so when I said "interesting", it didn't strictly mean interesting, and it's probably either old news or obvious to others. Still, it's a discovery to me.
John N
|
|
|
|
|
"Too good" is usually an oxymoron. Nevertheless, today's computers may be too good for the average human. This is not an elitist rant, just some observations.
As humans, we tend to anthropomorphise everything, especially our tools, and very especially our computers. We talk about what it "wants", "needs" and "says". We talk, occasionally, about it getting "confused". The average user might not quite get this. The below average user is completely lost, and may talk about the computer "just realising" that something is true, or "remembering". They want their computers to learn, which is all well and good, but they want it *now*. They want their computers to make logical inferences with their schedules. They want programs to adapt to their way of thinking. They want it to recognise their face so they don't need to remember a password, and they want to have all of their documents available everywhere at all times. All of these are noble goals, they're just not true at the moment.
So why would I express the difficulty as the computer being too good for a user who wants a fantastic learning machine? Because our modern machines are very good indeed, and the below-average user can't understand why they aren't Magnificent Personal Robot Slaves.
John N
|
|
|
|
|
"Downloading 12 megabytes over my 50 kilobit-per-second dialup line is too slow. Can you do anything about that?"
No, I'm sorry. That's as fast as it goes.
John N
|
|
|
|
|
The one thing that can exponentially expand the schedule and/or budget of a software project is incremental requirements. That is, getting your requirements just a little bit at a time.
Some clients will be of the (deluded) opinion that they are doing you a favour by passing on requirements bit by bit. This opinion comes from the idea that it's easier to handle them if there are only a few at any given time to concentrate on. The huge problem is that this forces design into faulty guesswork and means errors will be discovered at a much later stage than would otherwise be possible.
For this reason, and a few others, I recommend briefing your clients before getting any requirements from them. Let them know about how a software project works. They should know enough that their costs are minimised if they tell you everything they can in the most explicit and specific manner possible. Let them know that they can assume nothing. Tell them, in the nicest possible way, that if it's not in the requirements document then it's not getting built or that it will cost more in time and money.
The other thing your client needs to know is that it's not really simple to "just change it". Software can be a tricky thing to change, especially when the users are thinking in terms of a magical "concept system" into which they can plug a new concept with minimal effort. Let them know that, once it's being coded, a new concept needs to be inserted upstream and invalidates much of the work that was proceeding.
Despite your best efforts, your clients will leave things out of their requirements, assume others and want to add still more at a later date. This is why planning for change is important, but that's a topic for another day.
John N
|
|
|
|
|