Classic Shell: Forum

The Windows Vista/7/8 command bar is largely useless and never touched after you've chosen your preferred layout. Classic Shell makes it even more redundant since the terrible default layouts are among the biggest mistakes that CS fixes. It would incredibly nice if we could reclaim that large amount of vertical space taken up by the command bar in Windows Explorer. I'm currently using a tiny reghack to do this and I've no doubt the CS team could add this function without much trouble. Please consider adding this feature! Thanks for all you guys do..I literally couldn't use Win7 without CS!!

It requires modifying system files by resource hacking, a registry hack can't hide the command bar AFAIK. Out of Classic Shell's scope since it is more dangerous to modify system files on disk. But you can customize the Command Bar using the free Explorer Toolbar Editor: http://winaero.com/comment.php?comment.news.16 .

_________________
Links to some general topics:

● Compare Start Menus

● Read the Search box usage guide.

I am a Windows enthusiast and did Classic Shell's testing and usability/UX feedback.

1) I absolutely agree the command bar is redundant, takes us back from toolbars to text buttons, does so with a small set of commands (which only uncle MS chooses for us) leaving us with the need to continue using menus / context-menus / other toolbars, and for this half-baked stupidity forces us to loose precious horizontal space. Go figure MS..!

2) I did this:
How to Auto-Hide or Disable Command Bar in Windows Vista and 7 Explorer? from askvg.com
it worked great on Win7 64bit
The "hack" seems a very minor one (adding a line of text in a .dll file) and easy to roll back.
Now, thanks to this and to CS, I have one single menu+tool bar and it's very convenient, logical, customizeable and economic.

Thanks CS!

With all due respect I find the answer "it requires hacking so we don't want to do it" a bit unsatisfying, since ClassicShell already watches events and gets involved in the intimate details of what's happening inside Explorer. But I do understand that it's complicated to try to alter the behavior of a system utility from the inside out.

I have a question for the above poster (ittays)... Does that askvg.com hack end up breaking system protection (i.e., does the system fail an SFC /VERIFYONLY check) after it's done?

Thanks.

-Noel

The registry changes made by classic shell only affect classic shell, something like this would persist after classic shell was uninstalled. which is one of the reasons classic shell doesn't go into it. Though I agree there should be A utility that combines all the different registry hacks into an easy to use interface, that can be ran with a settings file to restore all those hacks on a new system. I don't believe classic shell should be that utility. (not that I have any say in the decision anyways )

The answer is I don't know, and I don't even know what SFC, VERIFYONLY are...

However the hack seems to involve merely hiding the toolbar only by tweaking its size, not affecting it in any other sense.

So my guess is it should have no effect on anything related to protection.

Changes to the registry can be reversed when uninstalling and this is probably what CS does too; but that is not the issue.

CS writing some of it's own parameters to the registry while probably true, should not be confused with what a program like CS needs to do in order to affect the behavior of another application, in this case a major Windows component like Explorer. It is most probable that changing the behavior of Explorer in the ways that CS does, must involve not only changing some of Explorer's registry setting, but also some much more intimate / intrusive mechanism(s) - as NoelC has correctly assumed. In order to affect an application's behavior through the registry, that application i.e. Explorer needs to be pre-programmed to be able to respond to what is written/modified in the registry. If Explorer was pre-programmed to optionally do the things that CS offers, it would probably default to doing them itself, or at least offer them to users as setup options - which it does not and this is why a more sophisticated solution like CS is called for.

So I agree with NoelC that CS probably needs to significantly touch on Explorer's internal logic, not only on it's parameters exposed in the registry.

However
So maybe the problem the developers see is in modifying system files, as opposed to what CS probably does currently: programatically bypass / add to / replace parts of Explorer's code without ever touching its code or files (probably done by intercepting and responding at run-time to system "messages" intended for Explorer).

Of course keeping Explorer files untouched is safer than changing them, because Microsoft can later decide to change those file and this can complicate things. But I still wonder, Ivo & Co., in what way is what CS is doing right now to Explorer's internal logic (alas "from the outisde") less dangerous all-in-all than changing a single UI parameter inside a DLL ? It would seem both are somewhat dangerous, but isn't the former more prone to disaster than the latter ?

uninstalled through conventional means sure... but programs arnt always uninstalled that way. and currently if a user goes to the classic shell directory and just deletes everything, the system runs fine as if classic shell were never installed, however if it were to modify other system properties.. that would not be the case..

I vote for that
I used the dll hack from 7 to 10 b10240 (after disabling metro in explorer).
Now it stopped to work on b10586: probably due lack of uxtheme support.
A very experimental option, with some injection, will be cool: could be "dangerous" in the case you haven't classic toolbar with needed buttons (menu bar goes on when you "hide/disable" command bar)