Code view is cut from Whidbey HTML Editor. .... Unfortunately, current VS IDE architecture does not have ability to arbitrarily position view window over the underlying text buffer. IDE has concept of hidden text that is used in code outlining and we did try to hide characters but in case of mixed indent (i.e. part spaces part tabs) things quickly get of control and then implementation becomes too complex. We tried to physically remove indentation effectively producing separate text buffer (Alpha release of Whidbey contained this implementation), but VS debugger as well as IDE were not able to associate two physically separate text buffers with the same document so breakpoints and bookmarks didn't work. We would have to duplicate everything in two documents in order to make it work, but debugger would be hitting breakpoints in only one of the documents. In addition separate code view didn't make much sense for render block and inline expressions.
So decision was made to remove the view ... I have mixed feeling about this since I have spent considerate amount of my time on the feature. Oh well... [via Microsoft WebBlogs]
On the heels on ObjectSpaces being shifted out to Longhorn comes this news which personally I find immensely heartening.
Way back when programming was a 'predictable' excercise - programs were specified and designed before development commenced. In part this was due to the OS being of relatively little function and consequently well known; a given input would give rise to a predictable output. Increasingly these days I find myself unable to predict what will happen with some piece of OS (MS) software given some input. This makes specification and design close to impossible because in the design one will have to guess, postulate and hope as to what the output might be - and if you are wrong the whole design goes wrong. Increasingly these days, programming is an R&D excercise as to not whether X is a better UI than Y but just how do you bet the OS/API/OM to do Z. This also goes to the root of why MS continually reinventing the wheel is so frustrating - you get to learn the wrinkles, the model so that you can predict what will happen and bang, it goes out the window and you have to start again.
At a trivial level, XP SP2 illustrates the case. Here we have the new interface INewWindowManager. Now, is the web browser control going to QI for this interface or will it use IServiceProvider.QueryService? The documentation does not say, it just says "Implement INewWindowManager when your application hosts a WebBrowser control and you want to include pop-up management functionality." The SDK headers tantalisingly declare an SID implying that QueryService may be used. You guessed it I went for QueryService and yep, the WebOC does a direct QI.
Small bit of R&D just to get the interface called, now consider the NewWindow3 event. Despite the previous bit of documentation, this event will get called if the INewWindowManager->EvaluateNewWindow allows the window to be created (and by default, if you don't implement INewWindowManager, the window will be allowed). Therefore, can one 'get away' with implementing an event handler on NewWindow3 (assuming one is already habdling NewWindow2) and ignore INewWIndowManager? I suspect so, but I don't know.
So, to return to where we came in, its is heartening that those MS guys waste a bunch of their time on stuff that doesn't work and has to be pulled. It would appear that the developer here did not have enough knowledge of the way the debugger and editor worked. If he had done, he would never have started down the development route.
Now the point is, someone in MS must have the knowledge, but it is not being imparted efficiently.