Was showing the column header in all Explorer views a rogue feature?


User :( asks whether the Explorer feature that shows the column headers in all views was a rogue feature or a planned one.

If it was a rogue feature, it was a horribly badly hidden one.

One of the important characteristics of the rogue feature is that you not be able to tell that the feature is there unless you go looking for it. If the feature is right there on the screen as soon as you open an Explorer window, odds are that somebody is going to notice and say something about it. (For example, the designer who is responsible for Explorer is probably going to notice that every screenshot of Explorer doesn't match the spec.)

That's why rogue features typically take the form of a hotkey or holding a modifier key in conjunction with another operation.

Writing up this characterization of rogue features reminds me that I myself am responsible for a rogue feature of Windows 95. If you go to an MS-DOS box, select Edit, then Mark, then select a section of the window for copying, if you hold the Ctrl key while dragging the mouse, the shape of the selection changes from a box to, um, I'm not sure the shape has a name. But it includes all the text between the start point and the end point, as if the contents of the window had come from an edit control. Something like this:

xxxxxxxxXXXXXXXX
XXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXX
XXXxxxxxxxxxxxxx

Since this was a rogue feature, it was never tested, and I suspect that it didn't work on Hebrew or Arabic systems.

I must've chickened out, or maybe my rogue feature was found out, because the code for streamed selections was ifdef'd out before Windows 95 shipped. So at least I can still honestly say that I never shipped a rogue feature.

Comments (63)
  1. Mike says:

    And I cry out in anguish that your selection mode wasn't made the default….

  2. C says:

    I wish your rogue feature had been promoted to the default. The square selection in cmd.exe is one of my most hated "features" of it. It'd be much better to be able to select off the end of lines, a la your feature there.

  3. Dan Bugglin says:

    I was disappointed when Windows 7 removed the "Always show listview header" from Explorer, I liked that.

    That rogue console feature would actually be quite useful since most console apps display text just like any text box app, so selection really should be like text boxes.  Rectangle selection is really only useful for edge cases.

  4. Skyborne says:

    I would call it char-wise or (for the CSS wranglers) inline style selection.

    I was going to ask if there's alternate UI for sorting if the headers weren't visible, but it's All There in the Context Menu.  Including the (new to Vista?) "More…" option which lets me view the 35mm focal length or Telex of my folders, iso images,"ntuser.dat.LOG2" files, etc.

  5. asdbsd says:

    Microsoft,

    Y U NO SHIP THIS FEATURE

  6. dalek says:

    #ifdef _ROGUE_FEATURES ?

  7. Leo Davidson says:

    Whoever #ifdef'd out that cmd.exe selection mode needs to be hunted down and made to pay. Assets frozen, communications subpoenaed, kitten photos seized… that kind of thing.

    [Thinking back on it, it was almost certainly me who #ifdef'd it out. I think it was because a tester discovered it and found bugs. It's hard to justify fixing bugs in rogue features. -Raymond]
  8. Kelden says:

    That's what I was always looking for and now it's gone in Windows 7. Please bring it back. :)

  9. Joe Dietz says:

    This is one of those things that you learn a few painful years into a programming career.  You just want to make a great product and you know the blessed spec has missed some really important feature that customers are going to be missing (though they may not know why they are unhappy enough to get things into the blessed spec…!).  But you know how to do it, just a few hundred lines of codes (or maybe just a few in this case?), so you code it up, test it some and get busy with something else, check it in a few weeks later and forget about it.  Then one week before shipping somebody logs a critical crash somewhere in your fix (of course this is because some other bit of code changed since you last tested it, and since it wasn't blessed your testing isn't part of the standard regression suite….)  Doh't.  Mgmt of course wants to know why.  You explain that you just need to change two lines and we can ship.  They still want to know why, but finally agree to let you fix it since taking it out entirely might break something else.  You ship, customers may or may not find your feature as useful as you thought (since of course it wasn't documented since it wasn't tested since it is not being blessed.) and all anybody really remembers is what a screw up you are.  Eventually you learn to either just clock in and do your work, or politic for your features ahead of time.

  10. Andreas Rejbrand says:

    Well, the only thing I really doesn't like in Windows 7 is that the wonderful, omnipotent and omnipresent list-view header control (from Windows Vista) isn't there anymore. I really would love to hear of a way of making it come back, but I suppose no registry hack in the world can accomplish that (or?).

  11. sukru says:

    I agree on the rouge feature being better than the current selection mechanism. It would make cmd.exe console a much more useful one.

  12. dave says:

    Are 'rouge features' the ones that are more highly polished on delivery?

    en.wikipedia.org/…/Jeweller%27s_rouge

  13. Andreas Rejbrand says:

    Ian Prest: Thank you very much! It works!

  14. db2 says:

    Ohhhhhh god, bring back the sane selection mode in console windows. Rectangular selection is atrocious.

  15. Tom says:

    Wow, some people actually liked that always-visible header in Vista?  I thought it was unnecessary clutter, a waste of space, but worst of all a very irritating stop in the tab order when using a file open/save dialog.  It was one of the reasons I stopped using Explorer for file/folder work and switched to a third-party app.  Whoever fixed this for Windows 7 should get a raise…  unless it was the person responsible for implementing it in the first place.

  16. Pierre B. says:

    Escalation procedure to add a much-needed feature to a program:

    1. Just write the code, hoping no one notices.

    2. Argue for it with passion and data points in design meeting.

    3. If all else fails, blog about it so there's a public out-cry asking for it.

  17. John says:

    If a rogue feature doesn't ship, is it really a rogue feature?

  18. mh says:

    Another vote for the cmd.exe rogue feature back – the number of times I've been caught out by the current selection mode!  All too often I end up just missing a single character or two at the end of the line.  Bring it back!

  19. Antonio Rodríguez says:

    Streamed selections should have been promoted from rogue to documented, with a button on the toolbar to toggle it. Rectangular selections make sense when the console window contains several text windows (I.E., the multiple document mode of QuickBasic/Edit 5.0). But for many (most?) people, the main use of the console window is to run a command line interpreter. There, I find myself having to copy a 80 character-wide rectangular selection, and then pasting in an auxiliary text document, stripping the beginning of the first line and the ending of the last one, and copying it again. A lot of work.

    About the always-visible column header: it's good it's there. It allows you to show and easily change the sorting order now that menus are hidden by default. Without it, most people wouldn't know how to sort the items when not in details view. The problem was, of course, the changed tab order. That's what hampered Vista: it's a great OS, but came out half-baked, because they had to cut the development, and had about the quality of a typical Microsoft RC (which, by the way, isn't low by any standards, but isn't high enough for the average user). The idea was great, but it suffered a lot from those little details that didn't have enough time to get fixed.

  20. Evan says:

    I agree with the people who wish that would rather have the 'streaming' selection… but on my list of complaints about that terminal window, the selection mode is probably about #47. (#1 is probably "why can I resize it just by dragging the border")

  21. Malcolmm says:

    Ah, box selection! I remember being so happy when I discovered BOX COPY and BOX PASTE in TPU on VMS systems [wonders if anyone else even knows what he means].

    So, perversely, I wish I could find a Windows editor that uses fixed font (or can be set to use a fixed font) and do BOX COPY/BOX PASTE…

    Although, stream selection in CMD.EXE would also be cool at times.

  22. Yuhong Bao says:

    "I suspect that it didn't work on Hebrew or Arabic systems. "

    BTW, why was Arabic console support never added to NT?

  23. Gabe says:

    Evan: Windows does not have a terminal emulator anymore (HyperTerm no longer ships with Windows). Windows has a console window which, as Raymond describes, is more like a frame buffer. It makes no attempt to emulate a terminal beyond a few rudimentary control codes (BEL, TAB, CR, LF).

  24. Alex Grigoriev says:

    @Malcomm:

    Any Visual Studio, Alt+Click-drag.

  25. AC says:

    Box selection by holding down Alt works in other editors, too. Like e.g. Notepad++.

    Sometimes this comes in quite handy, but there's a reason it's not the default. Having CMD do line selection would be a great usability improvement.

    [Not sure why you're asking CMD to do anything here. CMD has nothing to do with selection. It's just a console app, like /bin/sh. -Raymond]
  26. AC says:

    Of course you're right, I've obviously meant the console window or whatever is responsible for that.

    The point still stands though, your "rogue feature" would have been very handy.

  27. Joshua says:

    My application contains a rogue feature placed by me that I've carefully protected (by assigning all bugs in that area to myself) despite multiple bugs in it. Basically, if you know the hidden back-end key of a patient record, you can bring up that record in a search. This makes it possible to pass identifiers to and from support teams with no fear at all of anybody intercepting them, because nobody else can use them. For the complexities of debugging when dealing with sensitive data, we really do need it.

  28. Adam Rosenfield says:

    @Antonio Rodríguez: Yes, I agree, doing that is a lot of work.  If you use Cygwin, Cygwin provides a /dev/clipboard pseudofile that you can write to to copy data to the clipboard or that you can read from to paste data from the clipboard.

    It's very handy: if I want to copy the output of a command to the clipboard, I just run "command > /dev/clipboard"; if I want to save the clipboard data to a file, I just do "cat /dev/clipboard > filename".  I also use head(1) and tail(1) to pick out the lines of output I want, if I don't want the entire command output.

    If you don't use Cygwin, it's very easy to write a command line program that does a similar thing.  You just need to read in data on stdin, call OpenClipboard(NULL), EmptyClipboard(), GlobalAlloc(GMEM_MOVEABLE), GlobalLock(), SetClipboardData(CF_TEXT), and CloseClipboard().  Put that program in your $PATH, and off you go.

    (And consider this another vote for the "streamlined selection would be far, far more useful than the current rectangular selection in Windows consoles.)

  29. Evan says:

    @Raymond: "Windows uses the screen buffer model where the console window is a viewport into the screen buffer. Unix seems to have two screen buffer models, one for streamlike apps and one for fullscreen apps (like emacs)."

    And yet what I said still holds true for both modes, at least in Linux: you can resize a terminal running emacs and Emacs will adjust itself (reflowing text unless truncate-lines is on). There's a SIGWINCH that can notify console programs of the WINdow size CHange. (Wikipedia says "some Unixes" support this symbol; I'm not sure what happens on ones that don't.)

    And it's not like Windows console programs don't already have to deal with the resizing issue: the user can presumably change the buffer size while a console program is running, by going the long way 'round.

    @Gabe: "Windows does not have a terminal emulator anymore (HyperTerm no longer ships with Windows). Windows has a console window which, as Raymond describes, is more like a frame buffer. It makes no attempt to emulate a terminal beyond a few rudimentary control codes (BEL, TAB, CR, LF)."

    As far as the user's concerned this should be six of one, half a dozen of another. Maybe Windows should get a true terminal emulator? I don't know, and I don't particularly care. All I care about is the fact that I hate using the command prompt in Windows because I find it a PITA, and a big part of that is this resizing issue.

    When MS announced PowerShell I was really hopefully that they would improve the situation, but all they did was stick PS in the same crappy console window. So I'm stuck using 3rd party programs to get a usable shell.

  30. Tyler says:

    @Malcolmm Acutaly a Console application can be told when the window has been resized, but you have to tell it that you WANT that information, otherwise it's ignored.

  31. Evan says:

    @Malcolmm: "What happens as soon as you run a non-CONHOSTEX app? Does it then disallow resizing, leaving you back at step 1?"

    I'm not sure, but (1) that solution alone would be leaps and bounds better than what we have now, and (2) what happens if you resize the buffer on such a program now? Because whatever the answer to that is, it could continue to do that.

    Because you're still ignoring the fact that what I want is already possible, just with a bad UI.

  32. Malcolmm says:

    @Tyler: That's kind of similar to the Unix/xterm model. You resize the xterm … it sends SIGWINCH to its child processes (I'm not sure whether that's just to direct children only and they're responsible for passing it on, or to the entire process tree … I guess the latter). The child processes are responsible for redrawing themselves, should they wish to do so, by implementing a handler for the SIGWINCH signal.

    But consider a hypothetical Win32 application which doesn't listen for the window resize info and is reading from that screen buffer. You can see why current behaviour just discards the entire buffer on resize. Anything else opens up ambiguity and ambiguity breaks compatibility.

    We've kinda digressed a bit from the original topic, but I find those articles which digress a bit are the most interesting :)

  33. Ian Prest says:

    @Dan, @Keldan, @Andreas:  There's no registry hack, unfortunately, but you can do it in code in a BHO.  The trick is to call SetCurrentFolderFlags(FWF_NOHEADERINALLVIEWS, 0) on the folder interface.  

    Oddly enough, there *is* a FolderFlags registry key, but I've found Explorer actively sets the FWF_NOHEADERINALLVIEWS flag if you turn it off in the registry; I suspect some overeager junior developer was told to turn this feature off, and went and added code to set the flag when the folder is displayed (instead of just doing it in the default FolderFlags registry key).

    Anyway, I've made a simple BHO available here: github.com/…/Explorer7Fixes

  34. Joshua says:

    @Malcolm: The buffer gets a bottom-right select first so if the application failed to handle it would be OK if it were line oriented. It's still gonna be fried if it uses cursor movement and nothing I know can change that.

  35. Cheong says:

    I really missed the console streamed selection feature.

    Now I almost always have to ssh back to Cygwin at localhost when I think I'll need to copy the output back. I'd be much more convienent if I can just get that function in console window.

    Have someone created feature request on Connect? If so please post here as I'm going to vote it. (Afterall, the code all we need is written, just commented out. And with Core edition of Windows server shipping, there's good chance administrator will appreciate it, why not?)

  36. Cheong says:

    Ok, I figured out how to create the suggestion. (Somehow the "create feedback" button on the entry page just take me to a blank page that when viewed the source, only contain the viewstate control…)

    connect.microsoft.com/…/console-selection-mode

    Please vote.

  37. Justin G. says:

    The Console selection modal sounds like a good coding challenge. Not too easy, but by no means impossible with the console API(at least where WIN32_WINNT >= 0x0500). Although it would just be an executable that isn't hooked into the menus….

    I'm going to have a stab at it later.

  38. Evan says:

    @Evan: '(#1 is probably "why can I resize it just by dragging the border")'

    Correction: "why *can't* I resize it…"

    [Works for me. Try increasing your screen buffer size first. -Raymond]
  39. Yuhong Bao says:

    I wonder how the "rogue features" compare to the features worked on during Google's 20% time.

  40. Evan says:

    @Raymond: "Works for me. Try increasing your screen buffer size first. -Raymond"

    That's not the point… I want resizing the window to resize the buffer. When do I want to resize the window? It's when I run a command whose lines wrap that would be easier to read without the wrapping. So now to fix *that* problem, why do I have to go into the properties screen for this fairly common case? In most other programs, I'd just make the window bigger. Take this very website: I can resize this to as wide as my screens (2710 pixels) or as narrow as about 970 pixels and it will just reflow the text to the normal 75% of the width or so and not display a scroll bar.

    And that's the way *every other* terminal emulator I've used works: Xterm on *nix (or the more modern ones like Gnome Console, Konsole, Urxvt), the terminal program on OS X, the Cygwin-provided X-based terminal emulators on Windows, the SSH client from the actual SSH company (now Tectia) on Windows, or the Console2 program on Windows. The Windows terminal emulator is, as far as I know, unique among its peers in this respect, and at least *I* find it *incredibly* annoying.

    (The main exceptions to the "reflow the text" thing are programs like Word, where the display is constrained because of the relation what you'd get in the real world if you printed it. And in Wordpad (in Win7) you can even tell it to "wrap to window". (I don't see a corresponding option in Word: closest I see is one that will zoom the page in and out to keep the width of the page exactly visible as you resize the window. Also, some websites don't allow the browser as much freedom to change the layout.)

    [Windows uses the screen buffer model where the console window is a viewport into the screen buffer. Unix seems to have two screen buffer models, one for streamlike apps and one for fullscreen apps (like emacs). -Raymond]
  41. Dean Harding says:

    @Evan is right: you can already resize the console buffer (just go into Properties, on the Layout tab and change the "Screen Buffer Size") so there's no technical reason why conhost.exe couldn't resize the "screen buffer size" when you resize the window itself.

    Probably the reason it hasn't been implemented is because currently, resizing the console buffer is a rare event: you usually only do it once and then not change it (because it's so hard to do). If it was linked to resizing the window, then suddenly it would happen much more often and you'd notice all the programs which break a lot more…

    [If resizing the window larger automatically increased the screen buffer size, does that mean that resizing the window smaller automatically decreases the screen buffer size? "Yes" sucks. So does "no". -Raymond]
  42. Malcolmm says:

    [Not sure why you're asking CMD to do anything here. CMD has nothing to do with selection. It's just a console app, like /bin/sh. -Raymond]

    But the reason people want it is because /bin/sh inside an xterm (or its modern equivalent, anyway) can do it. As can any Windows app. So people naturally wonder why a console window in Windows can't have this, even as an option selected by holding a hotkey while dragging.

    I know someone at work who, because of the pain of line joining, sets his Command Prompt to be 255 characters wide … which is not an ideal workaround :(

    Just to be clear, so you don't take this the wrong way, this isn't making a Unix vs. Windows dig … just pointing out that /bin/sh in a modern windowed Unix environment doesn't behave like CMD.EXE.

    Yes, I appreciate that Windows console I/O is a different kettle of fish to the Unix device driver model where the app just spews out text to a pseudoterminal device – but that doesn't stop people making the usability comparison and asking 'Why can't Windows let me do that?'. Of course naturally this feature starts off at -100 (or is it -1000 points?) but the fact it can't even be optionally consistent with the rest of the Windows UI should be a driver to change it for the next version.

    At least it as not as daft as VMS, where you could only edit *the current line*. If you'd gone over a line boundary, you had to delete the text until you got back to the line you wanted to edit. That really sucked :)

    [Neither /bin/sh nor CMD.EXE know anything about the host UI. If you want to complain about the host UI, then saying "/bin/sh can do it, why not CMD?" is meaningless because /bin/sh isn't doing it either! You want to ask xterm/conhost for the feature, not /bin/sh and CMD.EXE. (And there's more to xterm than spewing characters to a pty. If that's all there was, then xterm wouldn't be able to resize the screen buffer either.) -Raymond]
  43. Malcolmm says:

    Sorry Raymond, yes you're correct in that CMD.EXE isn't implementing the UI. So that moves the place where the change is necessary to conhost as you point out. I am also aware that xterm implements the line joining and not /bin/sh.

    Notwithstanding those points, it would be a useful feature to add. Even being able to right-click on the window and pick 'Select (join lines)' from the popup window would be a useful feature.

    As far as I know, though, conhost would either have to do a bit of guesswork as to where a line end was (since it can't read the buffered text from the pty like xterm would) or it would have to internally keep track of CRLFs so that it had that state information.

    So yes, I appreciate it's not an easy feature to add and hey, no one wants to break existing stuff [which was always the official reason for why multi-line editing couldn't be added to VMS – no one wanted to touch the ancient TTDRIVER code]. It's the -1000 points again.

    xterm iirc implements window resize by sending an IOCTL (or was it even escape codes?) back to the pty driver to indicate its size had changed. This isn't something easily done on Windows and not something that could ever be easily implemented. Preserving the buffer on resize is also hard because it's a fixed-line length buffer.

    And if it was implemented so that it kept the buffer length but cleared the buffer … cue a horde of complaints by people who accidentally resize the window and lose the history. Even if it only did this when you shrunk it, people would howl :)

    So … no … I don't think dynamic resize is a great idea, just to make that clear!

    [Another difficulty is that Win32 lets applications *read* from the screen buffer. As I understand it, xterm doesn't let apps read from the buffer, only write to it. -Raymond]
  44. Malcolmm says:

    @Evan: Unix and xterm is a different model.

    The terminal driver gets the SIGWINCH and then it's up to the *application* to resize itself according to what a terminal inquire tells it is now the terminal size. The application thinks it's talking to a physical terminal that magically grew or shrunk its CRT.

    Windows applications don't know that's possible and you'd break a long chain of backwards compatibility.

    Even the idea of a new hypothetical 'conhostEX' that could allow this breaks when you decide to run an old app in it. In Unix the termminal/curses model is all there's ever been (well OK before that there were teletypes…). To do something similar in Windows throws out assumptions that date back to 16-bit apps (if you're on XP 32 bit … fire up DEBUG and watch what happens to your scroll bar and history … or even COMMAND.COM) and 32 bit console apps (which assume the buffer size will never change). What happens as soon as you run a non-CONHOSTEX app? Does it then disallow resizing, leaving you back at step 1?

  45. Jules says:

    @Dean, @Evan: Sure, it could be done.  The problem is that it shouldn't: resizing the buffer causes a rather large proportion of full-screen console apps to fail to redraw correctly, so it's not something that you should be able to do accidentally.  I don't know about you guys, but I sometimes resize windows accidentally when I'm trying to select text that's close to the edge of them.

  46. Fabian Schmied says:

    @Dean: Exactly. There's probably no technical reason to prevent convenient resizing of the buffer, but a usability problem: If you change the buffer size now, the buffer seems to be clipped to the new size. If you allowed people to do this with the usual "drag the frame" action, this would become a frequent operation, and people would lose data all the time.

    I think this is the reason why the feature is so obscure (and many clicks away).

    Also don't forget that resizing the console window is possible right now – it just doesn't change the screen buffer size, but the window size. Which is limited to the buffer size. This is very useful as is now, but mainly in the vertical dimension, because the buffer usually contains more lines than the window. It's also consistent with the way other windows work, where resizing causes you to only change the viewport rather than the existing information.

    So, the "drag-and-resize" operation is reserved for an existing feature that is consistent with other windows and causes no loss of information. So it should not be reused for changing the screen buffer size.

    But despite this, I agree that the "change screen buffer size" operation could and should be made more convenient to use for power users. You could implement it as a drag-and-resize-and-hold-the-Ctrl-key action or something similar, but this has the problem that a) it's obscure and hard to discover, b) it reserves a gesture to an operation specific to console windows which might be useful for another operation (on general windows) in the future.

    Here's a different idea: Change the constraint that the console window width must not exceed that of the screen buffer width. Ie., allow people to drag the window as wide as they want, but don't adjust the screen buffer with that dragging. (For a visual cue, maybe paint the delta in a different background color.) Then, add a context (and system) menu entry: "Extend/clip buffer to match window width" or something similar. (For better usability, the words "Extend" or "Clip" should probably be chosen dynamically depending on the relationship between window and buffer width.)

    Since this (drag + menu entry) is a two-step action, it's probably safe enough to avoid unexpected data loss. At the same time, it's fast enough to be more useful than the current path through the options dialog.

  47. Fowl says:

    Yes well the Windows console sucks, I too was hoping they were going to at least start fresh with PowerShell, but alas, no

    I'd like some more details on the omni-presence (except for bugs) headers. I really miss those. And for my grandma still on Vista, it'll be great to figure out how to fix it when they disappear without wiping huge swaths of registry entries out.

    Also, since it was so badly hidden (it was hidden?), how did it make it into the product?

    ps. Ian, Thank you so much!

  48. Fred says:

    I am so glad that explorer is much better (but not perfect, but apparently Finder has trouble too, so it must somehow be a hard problem) at staying in details view like I told it, so it's not such a big deal that the headers are gone.

  49. asdbsd says:

    @Cheong: I would have voted if it said "please incorporate said mode", not "please make it default". Different people have different ideas about what should be default. That's not the point here, the point is to have the selection mode at all.

  50. Andreas Rejbrand says:

    @Fred: I have a lot of folders with many (hundreds or even thousands) of photos and video clips. To browse these folders, I do need large icons (so that the content of the file is displayed in place of an ordinary icon), and, also, I do wish to perform sorting/filtering/grouping etc. So I am very glad that I am finally able to make the header omnipresent again (thanks to Ian Prest above).

  51. DWalker says:

    Raymond is giving "implementation details" as a justification why you can't resize the command window.  

    In my former life, when I was developing code for outside customers, a customer asked for some feature.  We started to explain why implementing the feature would be hard (it was a technical reason related to some internal data structures).  After giving it some thought, we realized that the feature would be great, and we admitted to ourselves that our reluctance was merely due to an implementation detail.  

    It turned out not to be as hard to implement the feature as we thought it would be, and the customer was very pleased.

    From then on, we vowed not to invoke "implementation details" as an excuse not to implement something that was a good idea.

  52. GregM says:

    asdbsd, you can vote for it and still comment that you think it should be optional.  Several people have already done this.

  53. James Bray says:

    Try a console replacement, such as:

    sourceforge.net/…/console

    Havn't given it a big test yet but its free/opensource & provides tabs in addition to "proper" selection (hold the CTRL key to activate).

    James

  54. Cheong says:

    @asdbsd: Agreed could make it an option… perheps could treat it like input method (i.e.: make the option available to let people select the default but offer shortcut to change.), but that could increase the development cost (rather than just remove the #ifdef and test the code, you now need change to UI… possibly even a new UI is needed.)

    Also make it default can make the behaviour align to other editors(like what Alex said, Alt+select in Visual Studio and MS Word), and make it easier for new admins to get it intuitively. That said, I think I'll content even if they just offer an option to change the selection mode in menu.

  55. Myria says:

    If only Windows 7 provided a way to replace conhost.exe…

    Then again, I'm just glad that console windows aren't owned by CSRSS anymore in Windows 7 – no more security constraints blocking you from drag and dropping files to a command prompt.

  56. Troll says:

    I won't but I feel whoever removed the column headers from all views in Windows 7 should be boiled in hot oil and tortured to death. It's one of the reasons I won't upgrade to this crappy product which removes features. Microsoft should be sued their asses off for removing features in Windows and advertising it as an "upgrade". I just wish I could give a really really hard slap to the person who decided to remove it.

    [I know you're unhappy, but could you lay off the death threats? I don't like notifying Microsoft security when somebody posts a death threat. We have your IP address, you know. -Raymond]
  57. Gabe says:

    Raymond: The Troll was merely suggesting that "Somebody should boil that person in hot oil and torture them to death", which is to imply that they're safe as long as nobody implores the Troll to actually be "that someone". In other words, as long as the Troll doesn't read your post from the 18th, you'll all be fine!

  58. Malcolmm says:

    Today, I actually used the box select for my benefit (selecting a list of items from fixed-format output from a command on a Netapp filer). So it does have its uses :)

    So I'd be happy with 'flowing select' (to coin a phrase) as an option. You change defaults, you confuse people and they say 'What a heap of crap Windows 8 was'.

    Although I must say I was happy when Allow Fast Paste as default disappeared. That used to cause us so many problems with people clicking on console windows and making them hang …

  59. 640k says:

    Adding useless cruft to GUI: Good

    Removing useful feaures: Even better!

    Continuing to Windows 8, you can clearly see where this is going.

    [If resizing the window larger automatically increased the screen buffer size, does that mean that resizing the window smaller automatically decreases the screen buffer size? "Yes" sucks. So does "no". -Raymond]

    On console resizing, these NO reason why a window resizing couldn't do a buffer resize in the same way the properties dialog already does. If properties dialog resizing would be bad, then why does it exist? You just make up excuses as usual. One solution would be to resize the buffer on WM_EXITSIZEMOVE instead of WM_SIZE. You could have thought of that but act if as there's no way to solve this usability PROBLEM.

    [Okay, so you say that it should shrink the buffer. Result: The content on the right hand edge gets chopped off. What if I wanted to just shrink the window and keep a large buffer? Are you saying that console windows shouldn't have scroll bars? (Because that's what shrinking the buffer on resize means.) -Raymond]
  60. Troll says:

    I am not giving death threats. I stated what I *felt like doing* to these idiots who mess up Windows.

    [Good luck explaining that to the judge. -Raymond]
  61. Yes and No says:

    Raymond: Are you saying that console windows shouldn't have scroll bars? (Because that's what shrinking the buffer on resize means.

    We only speak about the horizontal scrollbar here. Yes, when the window could be resized instantly with the mouse, this scrollbar can be eliminated, because it wlll not be visible 99.9999% of all cases.

    But resizing by mouse and resizing with the current property dialog can work side by side, the same way as today, as 640k says. I have never used the console this way, but if someone wants to make the buffer 5000 characters wide, by using the dialog, the horizontal scrollbar would still be useful.

    [I happen to have a console with a horizontal scrollbar right now. I would be upset if resizing the width also resized my console buffer so that it removed the scrollbar. -Raymond]
  62. Gabe says:

    You know, Notepad has a mode with a horizontal scrollbar and a mode without. It's not inconceivable that the console window could have a similar option.

    [The difference is that when you change the setting in Notepad, you don't lose data. (And good luck trying to come up with the text for the checkbox…) -Raymond]
  63. Kelden says:

    If you already have a scrollbar, resizing shouldn't remove the scrollbar (buffer).

    If you don't have one, resize without having one.

    [That might work for you, but sometimes I temporarily resize a window smaller (e.g., so the "% complete" is the only thing showing) and I don't want to lose the rest of the buffer. Maybe I'm just weird and nobody else resizes windows like I do. -Raymond]

Comments are closed.

Skip to main content