> * We also believed that this code was done as an edge case to stress the product.

False. This is one of real-world tools I've wrote.

Original problem - one of my clients were working with PeachTree accounting database using 128Mb USB memory flash. But due to human mistake - then it's come time to deliver this data to head office - she automatically decided to copy data from computer to flash (as she was trained to do so with ZIP drives).
Unfortunately - data on her computer were outdated and she lost a bunch of information she were working on during entire month.

Undelete tools does work in this scenario - as a lot of data were overridden. Even if undelete tools will repair some information - this will not be valid PeachTree database data.

I've decided to code a tiny C# program to recognize valid PeachTree (BTrieve ?) database records and dump them to some file in readable form to be able reenter or import them.

To be able access raw data freely - without any major coding overhead (this was a one-time use utility anyway) - I've decided to read all raw data from USB Flash to 128Mb byte array mentioned in my bug report.

If you do not believe me - I still have source for this small utility ;-)
You can take a look on it at http://24.odessa.ua/PF/PeachTree.cs

I was able to recover most of lost data (all data records - but without money amount paid/received - run out of time while trying to reverse engineer file format )-:

Something that was not good - IDE constantly hang then I was hacking/debugging my code.

This is original story of this bug report.
You decide best if this was stress-test scenario or real-world usage.

Regardless on origin of report - I've clearly proposed to set some reasonable limit on number of items shown in array visualizer.

P.S> While it was possible to use memory mapped files and unsafe pointer arithmetic, or read file data as you need it or use any other trick - I was lazy to do so. Please do not blame me for this ;-))

Visual Studio has never delt with large arrarys well. I fist noticed the problem 5 years ago. I just don't use it to look at large arrays.

I had also often the problem. If you have an array of 2000 object or more, it takes quite a while until the debug window reacts. Did you change something from VS.NET 2003? The problem wasn't there...

The problem has not only to do with simple arrays. If you debug an ArrayList or List<T> you ge the same behaviour.

As a workaround for this bug - I'm willing Microsoft to use the same technology they already used in C++ debug watch windows for pointers.
This is possible to type "myIntPtr,5" in C++ debug watch and see this pointer as an 5-element array, or this is possible to type "(myIntPtr + 4),7" to see 7 elements starting from index 4.

Simply do not show anything for huge arrays. "Huge" is registry configurable option.
But allow to see sub-ranges of arrays like a arr[4..10] will show at most 7 elements starting from 4th position.

Sorry for taking so long to reply to this. We have activated this bug, but its a little low on our priority list for the Beta2 release. As we head to RTM, we will have a more concrete idea of what we want to do with this.

Thanks. I understand you. Not a big deal for Beta2.
But I hope that it will be fixed in RTM.

Users always do unpredicable things with software. You must not hang in any scenario.
"Anything that can go wrong will go wrong. If there is a possibility of several things going wrong, the one that will cause the most damage will be the one to go wrong. "

PingBack from http://mydebtconsolidator.info/story.php?id=14877